Draft: draft-ietf-tls-subcerts

Commentary: Editorial changes from AD review . 
 Modulo adding the hyphen in between the I and the D ( my bad ) to make sure we get a normative reference to DTLS 1.3 . This is good to go .
Paragraph (version A):
The organizational separation between the operator of a (D)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 (D)TLS,
without breaking compatibility with peers that do not support this
specification.
Paragraph (version B):
The organizational separation between the operator of a (D)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 to to
overcome some of these limitations by enabling operators to delegate
their own credentials for use in (D)TLS without breaking
compatibility with peers that do not support this specification.
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 that 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.  Proxy
certificates can be useful in controlled environments, but remain
a risk in scenarios where the additional flexibility they provide
are not necessary.  For this reason, delegated credentials have
very restricted semantics that should not conflict with X.509
semantics.
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., a PKCS#11 interface or a remote signing
mechanism, KEYLESS being one example).  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 (D)TLS 1.3 RFC8446
ID.ietf-tls-dtls13.
Paragraph (version A):
These two mechanisms can be complementary.  A server could use
delegated credentials for clients that support them, while using a
server-side mechanism to support legacy clients.  Both mechanisms
require a trusted relationship between the Front-End and Back-End -
the delegated credential can be used in place of a certificate
private key, and the remote key signing case is effectively a signing
oracle for TLS connections using that certificate.
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., a PKCS#11 interface or a remote signing
mechanism, KEYLESS being one example).  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 (D)TLS 1.3 RFC8446 I-
D.ietf-tls-dtls13.
Paragraph (version B):
These two mechanisms can be complementary.  A server could use
delegated credentials for clients that support them, while using a
server-side mechanism to support legacy clients.  Both mechanisms
require a trusted relationship between the Front-End and Back-End -
the delegated credential can be used in place of a certificate
private key.
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 34.  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 (D)TLS 1.3 RFC8446 ID.ietf-tls-dtls13.
Additionally, the "DTLS-Only" column is assigned the value "N".
Paragraph (version B):
This document registers the "delegated_credential" extension in the
"TLS ExtensionType Values" registry.  The "delegated_credential"
extension has been assigned a code point of 34.  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 (D)TLS 1.3 RFC8446 I-D.ietf-tls-dtls13.
Additionally, the "DTLS-Only" column is assigned the value "N".
Paragraph (version A):
Delegated credentials limit the exposure of the private key used in a
(D)TLS connection by limiting its validity period.  An attacker who
compromises the private key of a delegated credential can act as a
man-in-the-middle until the delegated 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 are meant to be used between parties that have some trust
relationship with each other.  The secrecy of the delegated
credential's private key is thus important and 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 private key used in a
(D)TLS connection by limiting its validity period.  An attacker who
compromises the private key of a delegated credential can impersonate
the compromised party in new TLS connections until the delegated
credential expires.
Paragraph (version B):
However, they cannot create new delegated credentials.  Thus,
delegated credentials should not be used to send a delegation to an
untrusted party, but are meant to be used between parties that have
some trust relationship with each other.  The secrecy of the
delegated credential's private key is thus important and access
control mechanisms SHOULD be used to protect it, including file
system controls, physical security, or hardware security modules.
Paragraph (version A):
If a client decides to cache the certificate chain and re-validate it
when resuming a connection, the client SHOULD also cache the
associated delegated credential and re-validate it.
Paragraph (version B):
If a peer decides to cache the certificate chain and re-validate it
when resuming a connection, they SHOULD also cache the associated
delegated credential and re-validate it.  Failing to do so may result
in resuming connections for which the DC has expired.