Draft: draft-ietf-tls-subcerts

Commentary: Based on This PR drops support for delegated credentials with TLS 1.2 . Clients are unlikely to be able to support delegated credentials , but not TLS 1.3 . 
 Before you approve , note that I 've changed the language in Sec . 2 : " This document specifies the use of delegated credentials in TLS 1.3 or later ; their use in prior versions of the protocol is explicitly disallowed . " Before it said it only specifies DCs for 1.3 . I do n't see a reason for this restriction , though . 
 Ya I think the new sentence is better 
 this looks good to me
Paragraph (version A):
certificates would result in the service not being available which
creates greater operational risk.
Paragraph (version A):
To remove these dependencies, this document proposes a limited
delegation mechanism that allows a TLS server operator to issue its
own credentials within the scope of a certificate issued by an
external CA.  Because the above problems do not relate to the CAs
inherent function of validating possession of names, it is safe to
make such delegations as long as they only enable the recipient of
the delegation to speak for names that the CA has authorized.  For
clarity, we will refer to the certificate issued by the CA as a
"certificate" and the one issued by the operator as a "delegated
credential".
Paragraph (version A):
The signature on the credential indicates a delegation from the
certificate that is issued to the TLS server operator.  The secret
key used to sign a credential is presumed to be one whose
corresponding public key is contained in an X.509 certificate that
associates one or more names to the credential.
Paragraph (version B):
certificates would result in the service not being available, which
creates greater operational risk.
Paragraph (version B):
To remove these dependencies, this document proposes a limited
delegation mechanism that allows a TLS server operator to issue its
own credentials within the scope of a certificate issued by an
external CA.  Because the above problems do not relate to the CA's
inherent function of validating possession of names, it is safe to
make such delegations as long as they only enable the recipient of
the delegation to speak for names that the CA has authorized.  For
clarity, we will refer to the certificate issued by the CA as a
"certificate", or "delegation certificate", and the one issued by the
operator as a "delegated credential".
Paragraph (version B):
A delegated credential is a digitally signed data structure with two
semantic fields: a validity interval, and a public key (with its
associated algorithm).  The signature on the credential indicates a
delegation from the certificate that is issued to the TLS server
operator.  The secret key used to sign a credential is presumed to be
one whose corresponding public key is contained in an X.509
certificate that associates one or more names to the credential.
Paragraph (version A):
Delegated credentials can be used either in TLS 1.3 or TLS 1.2.
Differences between the use of delegated credentials in the protocols
are explicitly stated.
Paragraph (version B):
This document specifies the use of delegated credentials in TLS 1.3
or later; their use in prior versions of the protocol is explicitly
disallowed.
Paragraph (version A):
Credentials allow the server to terminate TLS connections on behalf
of the certificate owner.  If a credential is stolen, there is no
mechanism for revoking it without revoking the certificate itself.
To limit the exposure of a delegation credential compromise, servers
MUST NOT issue credentials with a validity period longer than 7 days.
Clients MUST NOT accept credentials with longer validity periods.
Paragraph (version B):
Delegated credentials allow the server to terminate TLS connections
on behalf of the certificate owner.  If a credential is stolen, there
is no mechanism for revoking it without revoking the certificate
itself.  To limit the exposure of a delegation credential compromise,
servers MUST NOT issue credentials with a validity period longer than
7 days.  Clients MUST NOT accept credentials with longer validity
periods.
Paragraph (version A):
X.509 semantics are very rich.  This can cause unintended
consequences if a service owner creates a proxy cert where the
properties differ from the leaf certificate.
Paragraph (version A):
Delegated credentials have very restricted semantics which should
not conflict with X.509 semantics.
Paragraph (version B):
X.509 semantics are very rich.  This can cause unintended
consequences if a service owner creates a proxy cert where the
properties differ from the leaf certificate.  For this reason,
delegated credentials have very restricted semantics which should
not conflict with X.509 semantics.
Paragraph (version A):
A client which supports this document SHALL send an empty
"delegated_credential" extension in its ClientHello.  If the client
receives a delegated credential without indicating support, then the
client SHOULD abort with an "unexpected_message" alert.
Paragraph (version A):
If the extension is present, the server MAY send a delegated
credential extension.  If the extension is not present, the server
MUST NOT send a credential.  A credential MUST NOT be provided unless
a Certificate message is also sent.  The server MUST ignore the
extension unless TLS 1.2 or later is negotiated.
Paragraph (version A):
When negotiating TLS 1.3, and using delegated credentials, the server
MUST send the delegated credential as an extension in the
CertificateEntry of its end-entity certificate; the client SHOULD
ignore delegated credentials sent as extensions with any other
certificate.  When negotiating TLS 1.2, the delegated credential MUST
be sent as an extension in the ServerHello.
Paragraph (version B):
A client which supports this document SHALL send an empty
"delegated_credential" extension in its ClientHello.  If the client
receives a delegated credential without indicating support, then the
client MUST abort with an "unexpected_message" alert.
Paragraph (version B):
If the extension is present, the server MAY send a delegated
credential extension; if the extension is not present, the server
MUST NOT send a delegated credential.  A delegated credential MUST
NOT be provided unless a Certificate message is also sent.  The
server MUST ignore the extension unless TLS 1.3 or later is
negotiated.
Paragraph (version B):
The server MUST send the delegated credential as an extension in the
CertificateEntry of its end-entity certificate; the client SHOULD
ignore delegated credentials sent as extensions to any other
certificate.
Paragraph (version A):
Verify that the certificate has the DelegationUsage extension,
which permits the use of delegated credentials.
Paragraph (version A):
Use the public key in the server's end-entity certificate to
verify the signature on the credential.
Paragraph (version B):
Verify that the end-entity certificate satisfies the conditions
specified in Section certificate-requirements.
Paragraph (version B):
Use the public key in the server's end-entity certificate to
verify the signature of the credential.
Paragraph (version B):
If one or more of these checks fail, then the delegated credential is
deemed invalid.  Clients that receive invalid delegated credentials
MUST terminate the connection with an "illegal_parameter" alert.  If
successful, the client uses the public key in the credential to
verify the signature in the serer's CertificateVerify message.
Paragraph (version A):
While X.509 forbids end-entity certificates from being used as
issuers for other certificates, it is perfectly fine to use them to
issue other signed objects as long as the certificate contains the
digitalSignature key usage (RFC5280 section 4.2.1.3).  We define a
new signed object format that would encode only the semantics that
are needed for this application.
Paragraph (version A):
Relative time in seconds from the beginning of the certificate's
notBefore value after which the delegated credential is no longer
valid.
Paragraph (version A):
The signature algorithm used to sign the delegated credential.
Paragraph (version A):
The DelegatedCredential structure is similar to the CertificateVerify
structure in TLS 1.3.  Since the SignatureScheme is defined in TLS
group and signature algorithm to perform validation.
Paragraph (version B):
Relative time in seconds from the beginning of the delegation
certificate's notBefore value after which the delegated credential
is no longer valid.
Paragraph (version B):
The signature algorithm of the credential key pair, where the type
SignatureScheme is as defined in the TLS 1.3 standard.
Paragraph (version B):
The version of TLS in which the credential will be used, where the
type ProtocolVersion is as defined in TLS 1.3.
Paragraph (version B):
The signature algorithm used to sign the delegated credential,
where SignatureScheme is as defined in the TLS 1.3 standard.
Paragraph (version A):
A single 0 byte which serves as the separator.
Paragraph (version A):
Big endian serialized 2 bytes ProtocolVersion of the negotiated
TLS version, defined by TLS.
Paragraph (version A):
DER encoded X.509 certificate used to sign the
DelegatedCredential.
Paragraph (version A):
Big endian serialized 2 byte SignatureScheme scheme.
Paragraph (version A):
The Credential structure.
Paragraph (version A):
It is bound to the certificate that signed it.
Paragraph (version A):
It is bound to the protocol version that is negotiated.  This is
intended to avoid cross-protocol attacks with signing oracles.
Paragraph (version B):
A single 0 byte, which serves as the separator.
Paragraph (version B):
The DER-encoded X.509 end-entity certificate used to sign the
DelegatedCredential.
Paragraph (version B):
DelegatedCredential.cred.
Paragraph (version B):
DelegatedCredential.scheme.
Paragraph (version B):
The signature effectively binds the credential to the parameters of
the handshake in which it is used.  In particular, it ensures that
credentials are only used with the certificate, protocol, and
signature algorithm chosen by the delegator.  Minimizing their
semantics in this way is intended to mitigate thee risk of cross
protocol attacks involving delegated credentials.
Paragraph (version A):
We define a new X.509 extension, DelegationUsage to be used in the
certificate when the certificate permits the usage of delegated
credentials.  When this extension is not present the client MUST not
accept a delegated credential even if it is negotiated by the server.
When it is present, the client MUST follow the validation procedure.
Paragraph (version A):
Conforming CAs MUST mark this extension as non-critical.  This allows
the certificate to be used by service owners for clients that do not
support certificate delegation as well and not need to obtain two
certificates.
Paragraph (version B):
We define a new X.509 extension, DelegationUsage, to be used in the
certificate when the certificate permits the usage of delegated
credentials.
Paragraph (version B):
It has the DelegationUsage extension.
Paragraph (version B):
It has the digitalSignature key usage enabled (see the Keyusage
type in RFC5280), but has the keyEncipherment and dataEncipherment
usages are disabled.
Paragraph (version B):
The extension MAY be marked crititcal.  (See Section 4.2 of RFC5280.)
If the strict boolean is set to true, then the server MUST use
delegated credential in the handshake; if no delegated credential is
offered, then the client MUST abort the handshake with an
"illegal_parameter" alert.
Paragraph (version B):
Marking the delegation certificate's DelegationUsage extension non-
critical allows the certificate to be used for clients that do not
support delegated credentials.  However, it may be desirable to
ensure that the delegation certificate is only used in handshakes in
which a delegated credential negotiated.  It suffices to mark the
extension crticial and set the strict boolean to true: if the client
does not support delegated credentials, then it will abort the
handshake if the certificate has the DelegationUsage extension (as
per Section 4.2 of RFC5280); if the client indicates support, but the
server does not offer a delegated credential, then the client will
abort the handshake (as per certificate-requirements).