Draft: draft-ietf-tls-subcerts

Commentary: Based on This adds a change log with changes from draft-01 . It drops the proposed " must - use - DC " semantics from the X.509 extension . There does n't seem to be a clean way to do this , and the complexity it adds seems to outweigh any potential benefit . The changes are as follows : Change DelegationUsage extension type to NULL . Drop support for TLS 1.2 . Add the protocol version and credential signature algorithm to the Credential structure . ( ) Specify undefined behavior in a few cases : when the client receives a DC without indicated support ; when the client indicates the extension in an invalid protocol version ; and when DCs are sent as extensions to certificates other than the end - entity certificate . 
 Not sure why  failed ... It 's building fine on my end . 
 Back to you :) 
 looks great to me
Paragraph (version A):
The organizational separation between the operator of a TLS server
and the certificate authority that provides it credentials can cause
problems, for example when it comes to reducing the lifetime of
certificates or supporting new cryptographic algorithms.  This
document describes a mechanism to allow TLS server operators to
create their own credential delegations without breaking
compatibility with clients that do not support this specification.
Paragraph (version B):
The organizational separation between the operator of a TLS server
and the certificate authority can create limitations.  For example,
the lifetime of certificates, how they may be used, and the
algorithms they support are ultimately determined by the certificate
authority.  This document describes a mechanism by which operators
may delegate their own credentials for use in TLS, without breaking
compatibility with clients that do not support this specification.
Paragraph (version A):
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 B):
Change DelegationUsage extension to be NULL.
Paragraph (version B):
Drop support for TLS 1.2.
Paragraph (version B):
Specify undefined behavior in a few cases: when the client
receives a DC without indicated support; when the client indicates
the extension in an invalid protocol version; and when DCs are
sent as extensions to certificates other than the end-entity
certificate.
Paragraph (version B):
A delegated credential is a digitally signed data structure with two
semantic fields: a validity interval and a public key (along with its
associated signature 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
corresponds to the public key of the X.509 end-entity certificate.
Paragraph (version A):
The server provides both the certificate chain terminating in its
certificate as well as the credential.
Paragraph (version A):
The client uses information in the server's certificate to verify
the signature on the credential and verify that the server is
asserting an expected identity.
Paragraph (version A):
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):
It was noted in XPROT that certificates in use by servers that
support outdated protocols such as SSLv2 can be used to forge
signatures for certificates that contain the keyEncipherment KeyUsage
(RFC5280 section 4.2.1.3) In order to prevent this type of cross-
protocol attack, we define a new DelegationUsage extension to X.509
that permits use of delegated credentials.  Clients MUST NOT accept
delegated credentials associated with certificates without this
extension.
Paragraph (version A):
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 B):
The server provides both the certificate chain terminating in its
certificate as well as the delegated credential.
Paragraph (version B):
The client uses information in the server's certificate to verify
the delegated credential and that the server is asserting an
expected identity.
Paragraph (version B):
As detailed in delegated-credentials, the delegated credential is
cryptographically bound to the end-entity certificate and the
protocol in which the credential may be used.  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 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 exposure in case a delegated credential is
compromised, servers may not issue credentials with a validity period
longer than 7 days.  This mechanism is described in detail in client-
and-server-behavior.
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.  For this reason,
delegated credentials have very restricted semantics which should
not conflict with X.509 semantics.
Paragraph (version A):
Proxy certificates rely on the certificate path building process
to establish a binding between the proxy certificate and the
server certificate.  Since the cert path building process is not
cryptographically protected, it is possible that a proxy
certificate could be bound to another certificate with the same
public key, with different X.509 parameters.  Delegated
credentials, which rely on a cryptographic binding between the
entire certificate and the delegated credential, cannot.
Paragraph (version A):
Delegated credentials are bound to specific versions of TLS.  This
prevents them from being used for other protocols if a service
owner allows multiple versions of TLS.
Paragraph (version B):
X.509 semantics are very rich.  This can cause unintended
consequences if a service owner creates a proxy certificate 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 B):
Proxy certificates rely on the certificate path building process
to establish a binding between the proxy certificate and the
server certificate.  Since the certificate path building process
is not cryptographically protected, it is possible that a proxy
certificate could be bound to another certificate with the same
public key, with different X.509 parameters.  Delegated
credentials, which rely on a cryptographic binding between the
entire certificate and the delegated credential, cannot.
Paragraph (version B):
Each delegated credential is bound to a specific version of TLS
and signature algorithm.  This prevents them from being used for
other protocols or with other signature algorithms than service
owner allows.
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 MUST 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 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 A):
The delegated credential contains a signature from the public key in
the end-entity certificate using a signature algorithm advertised by
the client in the "signature_algorithms" extension.  Additionally,
the credential's public key MUST be of a type that enables at least
one of the supported signature algorithms.  A delegated credential
MUST NOT be negotiated by the server if its signature is not
compatible with any of the supported signature algorithms or the
credential's public key is not usable with the supported signature
algorithms of the client, even if the client advertises support for
delegated credentials.
Paragraph (version A):
Verify that the end-entity certificate satisfies the conditions
specified in Section certificate-requirements.
Paragraph (version A):
Use the public key in the server's end-entity certificate to
verify the signature of the credential.
Paragraph (version A):
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):
The signature algorithm of the credential key pair, where the type
SignatureScheme is as defined in the TLS 1.3 standard.
Paragraph (version A):
The version of TLS in which the credential will be used, where the
type ProtocolVersion is as defined in TLS 1.3.
Paragraph (version A):
The delegated credential's public key, which is an encoded
SubjectPublicKeyInfo RFC5280.
Paragraph (version A):
The signature algorithm used to sign the delegated credential,
where SignatureScheme is as defined in the TLS 1.3 standard.
Paragraph (version B):
The signature algorithm of the credential key pair, where the type
SignatureScheme is as defined in the TLS 1.3 standard.  This is
expected to be the same as CertificateVerify.algorithm sent by the
server.
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.  This is expected
to match the protocol version that is negotiated by the client and
server.
Paragraph (version B):
The credential's public key, a DER-encoded SubjectPublicKeyInfo as
defined in RFC5280.
Paragraph (version B):
The signature algorithm used to verify
DelegatedCredential.signature.
Paragraph (version A):
DelegatedCredential.cred.
Paragraph (version B):
DelegatedCredential.algorithm.
Paragraph (version A):
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 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 the risk of cross
protocol attacks involving delegated credentials.
Paragraph (version A):
It has the digitalSignature key usage enabled (see the Keyusage
type in RFC5280), but has the keyEncipherment and dataEncipherment
usages are disabled.
Paragraph (version A):
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 A):
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).
Paragraph (version B):
A client which supports this specification 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; 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 a later version is negotiated.
Paragraph (version B):
The algorithm and expected_cert_verify_algorithm fields MUST be of a
type advertised by the client in the "signature_algorithms"
extension.  A delegated credential MUST NOT be negotiated otherwise,
even if the client advertises support for delegated credentials.
Paragraph (version B):
Verify that expected_cert_verify_algorithm matches the scheme
indicated in the server's CertificateVerify message.
Paragraph (version B):
Verify that expected_version matches the protocol version
indicated in the server's "supported_versions" extension.
Paragraph (version B):
Verify that the end-entity certificate satisfies the conditions
specified in certificate-requirements.
Paragraph (version B):
Use the public key in the server's end-entity certificate to
verify the signature of the credential using the algorithm
indicated by DelegatedCredential.algorithm.
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 server's CertificateVerify message.
Paragraph (version B):
It has the digitalSignature KeyUsage (see the KeyUsage extension
defined in RFC5280).
Paragraph (version A):
Delegated credentials do not provide any additional form of early
revocation.  Since it is short lived, the expiry of the delegated
credential would revoke the credential.  Revocation of the long term
private key that signs the delegated credential also implictly
revokes the delegated credential.
Paragraph (version B):
Delegated credentials do not provide any additional form of early
revocation.  Since it is short lived, the expiry of the delegated
credential would revoke the credential.  Revocation of the long term
private key that signs the delegated credential also implicitly
revokes the delegated credential.