Draft: draft-ietf-tls-subcerts

Commentary: This clarifies the usage of Credential and Delegated Credential terms . It also clarifies the signing mechanism . 
 I 've incorporated the comments ;) 
 Thanks for these changes ! I made a few comments that should be resolved .
Paragraph (version A):
To reduce the dependency on external CAs, 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.  These credentials 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 reduce the dependency on external CAs, 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.  These credentials only enable the recipient of the delegation to
speak for names that the CA has authorized.
Paragraph (version B):
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 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
peer.  The private key used to sign a credential corresponds to the
public key of the peer's X.509 end-entity certificate RFC5280.
Paragraph (version B):
A delegated credential (DC) 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 delegated
credential indicates a delegation from the certificate that is issued
to the peer.  The private key used to sign a credential corresponds
to the public key of the peer's X.509 end-entity certificate RFC5280.
Paragraph (version A):
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 of delegated credential private key
compromise, delegated credentials have a maximum validity period.  In
the absence of an application profile standard specifying otherwise,
the maximum validity period is set to 7 days.  Peers MUST NOT issue
credentials with a validity period longer than the maximum validity
period.  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 of the compromise of a delegated
credential's private key, delegated credentials have a maximum
validity period.  In the absence of an application profile standard
specifying otherwise, the maximum validity period is set to 7 days.
Peers MUST NOT issue credentials with a validity period longer than
the maximum validity period.  This mechanism is described in detail
in client-and-server-behavior.
Paragraph (version A):
These two mechanisms can be complementary.  A server could use
credentials for clients that support them, while using KEYLESS to
support legacy clients.  The private key for a delegated credential
can be used in place of a certificate private key, so it is important
that the Front-End and Back-End are parties that have a trusted
relationship.
Paragraph (version B):
These two mechanisms can be complementary.  A server could use
delegated credentials for clients that support them, while using
KEYLESS to support legacy clients.  The private key for a delegated
credential can be used in place of a certificate private key, so it
is important that the Front-End and Back-End are parties with a
trusted relationship.
Paragraph (version A):
The signature algorithm of the credential key pair, where the type
SignatureScheme is as defined in RFC8446.  This is expected to be
the same as CertificateVerify.algorithm sent by the server.  Only
signature algorithms allowed for use in CertificateVerify messages
are allowed.  When using RSA, the public key MUST NOT use the
rsaEncryption OID, as a result, the following algorithms are not
allowed for use with delegated credentials: rsa_pss_rsae_sha256,
rsa_pss_rsae_sha384, rsa_pss_rsae_sha512.
Paragraph (version B):
The signature algorithm of the Credential key pair, where the type
SignatureScheme is as defined in RFC8446.  This is expected to be
the same as CertificateVerify.algorithm sent by the server.  Only
signature algorithms allowed for use in CertificateVerify messages
are allowed.  When using RSA, the public key MUST NOT use the
rsaEncryption OID.  As a result, the following algorithms are not
allowed for use with delegated credentials: rsa_pss_rsae_sha256,
rsa_pss_rsae_sha384, rsa_pss_rsae_sha512.
Paragraph (version B):
The Credential structure as previously defined.
Paragraph (version A):
The context string "TLS, server delegated credentials" for servers
and "TLS, client delegated credentials" for clients.
Paragraph (version B):
The context string "TLS, server delegated credentials" for server
authentication and "TLS, client delegated credentials" for client
authentication.
Paragraph (version B):
The signature is computed by using the private key of the peer's end-
entity certificate, with 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 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 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.
Paragraph (version B):
If successful, the participant receiving the Certificate message uses
the public key in DelegatedCredential.cred to verify the signature in
the peer's CertificateVerify message.
Paragraph (version A):
One of the risks of deploying a short-lived credential system based
on absolute time is client clock skew.  If a client's clock is
sufficiently ahead or behind of the server's clock, then clients will
reject credentials that are valid from the server's perspective.
Clock skew also affects the validity of the original certificates.
The lifetime of the delegated credential should be set taking clock
skew into account.  Clock skew may affect a delegated credential at
the beginning and end of its validity periods, which should also be
taken into account.
Paragraph (version B):
One of the risks of deploying a short-lived credential system based
on absolute time is client clock skew.  If a client's clock is
sufficiently ahead or behind of the server's clock, then clients will
reject delegated credentials that are valid from the server's
perspective.  Clock skew also affects the validity of the original
certificates.  The lifetime of the delegated credential should be set
taking clock skew into account.  Clock skew may affect a delegated
credential at the beginning and end of its validity periods, which
should also be taken into account.
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 implicitly
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 revokes the credential.  Revocation of the long term
private key that signs the delegated credential (from the end-entity
certificate) also implicitly revokes the delegated credential.
Paragraph (version A):
Delegated credentials can be valid for 7 days and it is much easier
for a service to create delegated credential than a certificate
signed by a CA.  A service could determine the client time and clock
skew by creating several delegated credentials with different expiry
timestamps and observing whether the client would accept it.  Client
time could be unique and thus privacy sensitive clients, such as
browsers in incognito mode, who do not trust the service might not
want to advertise support for delegated credentials or limit the
number of probes that a server can perform.
Paragraph (version B):
Delegated credentials can be valid for 7 days and it is much easier
for a service to create delegated credentials than a certificate
signed by a CA.  A service could determine the client time and clock
skew by creating several delegated credentials with different expiry
timestamps and observing whether the client would accept it.  Client
time could be unique and thus privacy sensitive clients, such as
browsers in incognito mode, who do not trust the service might not
want to advertise support for delegated credentials or limit the
number of probes that a server can perform.
Paragraph (version A):
credential could then be used by the attacker as the equivalent of a
man-in-the-middle certificate, valid for 7 days.
Paragraph (version B):
delegated credential could then be used by the attacker as the
equivalent of a man-in-the-middle certificate, valid for a maximum of
7 days.