Draft: draft-ietf-tls-subcerts

Commentary: No substantive changes , just grammatical nits and suggestions for clarifying the exposition . In the " Client Behavior " section ( Section 3.1 ) , I a sentence explaining how to check the time - to - live to the first of the DC - validation steps . This might be helpful , as folks have been confused in the past about how to determine if a DC has expired . 
 LGTM
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".
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" or "DC".
Paragraph (version A):
As detailed in delegated-credentials, the delegated credential is
cryptographically bound to the end-entity certificate with 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):
As detailed in delegated-credentials, the delegated credential is
cryptographically bound to the end-entity certificate with 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 not allowed.
Paragraph (version A):
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):
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 that should
not conflict with X.509 semantics.
Paragraph (version A):
Each delegated credential is bound to a specific signature
algorithm.  This prevents them from being used with other,
unintended, signature algorithms.
Paragraph (version B):
Each delegated credential is bound to a specific signature
algorithm that may be used to sign the TLS handshake (RFC8446
section 4.2.3).  This prevents them from being used with other,
perhaps unintended signature algorithms.
Paragraph (version A):
Many of the use cases for delegated credentials can also be addressed
using purely server-side mechanisms that do not require changes to
client behavior (e.g., LURK I-D.mglt-lurk-tls-requirements).  These
mechanisms, however, incur per-transaction latency, since the front-
end server has to interact with a back-end server that holds a
private key.  The mechanism proposed in this document allows the
delegation to be done off-line, with no per-transaction latency.  The
figure below compares the message flows for these two mechanisms with
TLS 1.3 I-D.ietf-tls-tls13, where DC is delegated credentials.
Paragraph (version B):
Many of the use cases for delegated credentials can also be addressed
using purely server-side mechanisms that do not require changes to
client behavior (e.g., LURK I-D.mglt-lurk-tls-requirements).  These
mechanisms, however, incur per-transaction latency, since the front-
end server has to interact with a back-end server that holds a
private key.  The mechanism proposed in this document allows the
delegation to be done off-line, with no per-transaction latency.  The
figure below compares the message flows for these two mechanisms with
TLS 1.3 I-D.ietf-tls-tls13.
Paragraph (version A):
It is possible to address the short-lived certificate concerns above
by automating certificate issuance, e.g., with ACME I-D.ietf-acme-
acme.  In addition to requiring frequent operationally-critical
interactions with an external party, this makes the server operator
dependent on the CA's willingness to issue certificates with
sufficiently short lifetimes.  It also fails to address the issues
with algorithm support.  Nonetheless, existing automated issuance
APIs like ACME may be useful for provisioning credentials, within an
operator network.
Paragraph (version B):
It is possible to address the short-lived certificate concerns above
by automating certificate issuance, e.g., with ACME I-D.ietf-acme-
acme.  In addition to requiring frequent operationally-critical
interactions with an external party, this makes the server operator
dependent on the CA's willingness to issue certificates with
sufficiently short lifetimes.  It also fails to address the issues
with algorithm support.  Nonetheless, existing automated issuance
APIs like ACME may be useful for provisioning credentials within an
operator network.
Paragraph (version A):
The signature over the credential with the end-entity
certificate's public key, using the scheme.
Paragraph (version B):
The delegation, a signature that binds the credential to the end-
entity certificate's public key as specified below.  The signature
scheme is specified by DelegatedCredential.algorithm.
Paragraph (version A):
The code changes to create and verify delegated credentials would be
localized to the TLS stack, which has the advantage of avoiding
changes to security-critical and often delicate PKI code (though of
course moves that complexity to the TLS stack).
Paragraph (version B):
The code changes required in order to create and verify delegated
credentials, and the implementation complexity this entails, are
localized to the TLS stack.  This has the advantage of avoiding
changes to security-critical and often delicate PKI code.
Paragraph (version A):
Verify that the current time is within the validity interval of
the credential and that the credential's time to live is no more
than 7 days.
Paragraph (version A):
Verify that the end-entity certificate satisfies the conditions
specified in certificate-requirements.
Paragraph (version B):
Verify that the current time is within the validity interval of
the credential and that the credential's time to live is no more
than 7 days.  This is done by asserting that the current time is
no more than the delegation certificate's notBefore value plus
DelegatedCredential.cred.valid_time.
Paragraph (version B):
Verify that the end-entity certificate satisfies the conditions in
certificate-requirements.
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 such as 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.