Draft: draft-ietf-tls-subcerts

Commentary: I think this could use a security consideration discussing what could happen if you use the same delegated credential as both a client and server credential . This should be safe i.e. 
 since the DC is tied to the cert , it would have to be a cert that supports both client and server auth . 
 Ya that is usually the type of certificate that most people issue for datacenter use dual purpose . Just want to say that " hey DC does not change the security model " 
 feel free to push whenever you feel you have enough reviews 
 lgtmLGTM -- thanks for the changes !
Paragraph (version A):
The organizational separation between the operator of a TLS server
and the certification 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
certification 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 B):
The organizational separation between the operator of a TLS endpoint
and the certification 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
certification authority.  This document describes a mechanism by
which operators may delegate their own credentials for use in TLS,
without breaking compatibility with peers that do not support this
specification.
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 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" or "DC".
Paragraph (version B):
To remove these dependencies, this document proposes a limited
delegation mechanism that allows a TLS peer 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" or "DC".
Paragraph (version B):
Add support for client certificates.
Paragraph (version A):
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 TLS server's X.509 end-entity
certificate.
Paragraph (version A):
The client provides an extension in its ClientHello that indicates
support for this mechanism.
Paragraph (version A):
The server provides both the certificate chain terminating in its
certificate as well as the delegated credential.
Paragraph (version A):
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 A):
The client uses the public key in the credential as the server's
working key for the TLS handshake.
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
peer.  The secret key used to sign a credential corresponds to the
public key of the peer's X.509 end-entity certificate.
Paragraph (version B):
The initiating peer provides an extension in its ClientHello or
CertificateRequest that indicates support for this mechanism.
Paragraph (version B):
The peer sending the Certificate message provides both the
certificate chain terminating in its certificate as well as the
delegated credential.
Paragraph (version B):
The authenticating intitiator uses information from the peer's
certificate to verify the delegated credential and that the peer
is asserting an expected identity.
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 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 B):
Delegated credentials allow a peer 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,
peers 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):
The context string "TLS, server delegated credentials".
Paragraph (version B):
The context string "TLS, server delegated credentials" for servers
and "TLS, client delegated credentials" for clients.
Paragraph (version A):
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):
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.  The server MUST ignore the extension unless
TLS 1.3 or a later version is negotiated.
Paragraph (version A):
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):
The algorithm and expected_cert_verify_algorithm fields MUST be of a
type advertised by the client in the "signature_algorithms" extension
and are considered invalid otherwise.  Clients that receive invalid
delegated credentials MUST terminate the connection with an
"illegal_parameter" alert.
Paragraph (version B):
A server which supports this specification SHALL send an empty
"delegated_credential" extension in the CertificateRequest message
when requesting client authentication.  If the server receives a
delegated credential without indicating support in its
CertificateRequest, then the server MUST abort with an
"unexpected_message" alert.
Paragraph (version B):
If the extension is present, the client MAY send a delegated
credential; if the extension is not present, the client MUST NOT send
a delegated credential.  The client MUST ignore the extension unless
TLS 1.3 or a later version is negotiated.
Paragraph (version B):
The client MUST send the delegated credential as an extension in the
CertificateEntry of its end-entity certificate; the server SHOULD
ignore delegated credentials sent as extensions to any other
certificate.
Paragraph (version B):
The algorithm and expected_cert_verify_algorithm fields MUST be of a
type advertised by the server in the "signature_algorithms" extension
and are considered invalid otherwise.  Servers that receive invalid
delegated credentials MUST terminate the connection with an
"illegal_parameter" alert.
Paragraph (version A):
Verify that expected_cert_verify_algorithm matches the scheme
indicated in the server's CertificateVerify message.
Paragraph (version A):
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 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 server's CertificateVerify message.
Paragraph (version B):
Verify that expected_cert_verify_algorithm matches the scheme
indicated in the peer's CertificateVerify message.
Paragraph (version B):
Use the public key in the peer'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 and servers that receive invalid delegated
credentials MUST terminate the connection with an "illegal_parameter"
alert.  If successful, the participant receiving the Certificate
message uses the public key in the credential to verify the signature
in the peer's CertificateVerify message.
Paragraph (version A):
This document registers the "delegated_credentials" extension in the
"TLS ExtensionType Values" registry.  The "delegated_credentials"
extension has been assigned a code point of TBD.  The IANA registry
lists this extension as "Recommended" (i.e., "Y") and indicates that
it may appear in the ClientHello (CH) or CertificateRequest (CR)
messages in TLS 1.3 RFC8446.
Paragraph (version B):
This document registers the "delegated_credentials" extension in the
"TLS ExtensionType Values" registry.  The "delegated_credentials"
extension has been assigned a code point of TBD.  The IANA registry
lists this extension as "Recommended" (i.e., "Y") and indicates that
it may appear in the ClientHello (CH), CertificateRequest (CR), or
Certificate (CT) messages in TLS 1.3 RFC8446.
Paragraph (version A):
Delegated credentials limit the exposure of the TLS private key by
limiting its validity.  An attacker who compromises the private key
of a delegated credential can act as a man in the middle until the
delegate credential expires, however they cannot create new delegated
credentials.  Thus, delegated credentials should not be used to send
a delegation to an untrusted party, but is meant to be used between
parties that have some trust relationship with each other.  The
secrecy of the delegated private key is thus important and several
access control mechanisms SHOULD be used to protect it, including
file system controls, physical security, or hardware security
modules.
Paragraph (version B):
Delegated credentials limit the exposure of the TLS private key by
limiting its validity.  An attacker who compromises the private key
of a delegated credential can act as a man-in-the-middle until the
delegate credential expires, however they cannot create new delegated
credentials.  Thus, delegated credentials should not be used to send
a delegation to an untrusted party, but is meant to be used between
parties that have some trust relationship with each other.  The
secrecy of the delegated private key is thus important and several
access control mechanisms SHOULD be used to protect it, including
file system controls, physical security, or hardware security
modules.
Paragraph (version B):
It is possible to use the same delegated credential for both client
and server authentication if the Certificate allows it.  This is safe
because the context string used for delegated credentials is distinct
in both contexts.