Draft: draft-ietf-tls-subcerts

Commentary: Merging these changes to use as a basis for the on - list response to the full AD review . 
 This looks good .
Paragraph (version A):
Server operators often deploy (D)TLS termination services in
locations such as remote data centers or Content Delivery Networks
(CDNs) where it may be difficult to detect key compromises.  Short-
lived certificates may be used to limit the exposure of keys in these
cases.
Paragraph (version B):
Server operators often deploy (D)TLS termination services in
locations such as remote data centers or Content Delivery Networks
(CDNs) where it may be difficult to detect compromises of private key
material corresponding to TLS certificates.  Short-lived certificates
may be used to limit the exposure of keys in these cases.
Paragraph (version A):
However, short-lived certificates need to be renewed more frequently
than long-lived certificates.  If an external CA is unable to issue a
certificate in time to replace a deployed certificate, the server
would no longer be able to present a valid certificate to clients.
With short-lived certificates, there is a smaller window of time to
renew a certificates and therefore a higher risk that an outage at a
CA will negatively affect the uptime of the service.
Paragraph (version B):
However, short-lived certificates need to be renewed more frequently
than long-lived certificates.  If an external CA is unable to issue a
certificate in time to replace a deployed certificate, the server
would no longer be able to present a valid certificate to clients.
With short-lived certificates, there is a smaller window of time to
renew a certificates and therefore a higher risk that an outage at a
CA will negatively affect the uptime of the TLS-fronted service.
Paragraph (version A):
The server operator can only use (D)TLS signature schemes for
which the CA will issue credentials.
Paragraph (version B):
The CA might only issue credentials containing certain types of
public key, which can limit the set of (D)TLS signature schemes
usable by the server operator.
Paragraph (version A):
The authenticating initiator uses information from the peer's
certificate to verify the delegated credential and that the peer
is asserting an expected identity.
Paragraph (version B):
The initiator uses information from the peer's certificate to
verify the delegated credential and that the peer is asserting an
expected identity, determining an authentication result for the
peer..
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 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):
Proxy certificates rely on the certificate path building process
to establish a binding between the proxy certificate and the end-
entity 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 A):
Each delegated credential is bound to a specific signature
algorithm for use in the (D)TLS handshake (RFC8446 section 4.2.3).
This prevents them from being used with other, perhaps unintended
signature algorithms.  The signature algorithm bound to the
delegated credential can be chosen independantly of the set of
signature algorithms supported by the end-entity certificate.
Paragraph (version B):
Each delegated credential is bound to a specific signature
algorithm for use in the (D)TLS handshake (RFC8446 section 4.2.3).
This prevents them from being used with other, perhaps unintended,
signature algorithms.  The signature algorithm bound to the
delegated credential can be chosen independently of the set of
signature algorithms supported by the end-entity certificate.
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).  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
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 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
ID.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, and the remote key signing case is effectively a signing
oracle for TLS connections using that certificate.
Paragraph (version A):
Time in seconds relative to the beginning of the delegation
certificate's notBefore value after which the delegated credential
is no longer valid.  Endpoints will reject delegated credentials
that expire more than 7 days from the current time (as described
in client-and-server-behavior).
Paragraph (version B):
Time, in seconds relative to the delegation certificate's
notBefore value, after which the delegated credential is no longer
valid.  Endpoints will reject delegated credentials that expire
more than 7 days from the current time (as described in client-
and-server-behavior).
Paragraph (version A):
The code changes required in order to create and verify delegated
credentials, and the implementation complexity this entails, are
localized to the (D)TLS stack.  This has the advantage of avoiding
changes to security-critical and often delicate PKI code.
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 (D)TLS stack.  This has the advantage of avoiding
changes to the often-delicate security-critical PKI code.
Paragraph (version A):
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 client receives a delegated credential without having
indicated support in its ClientHello, then the client MUST abort the
handshake with an "unexpected_message" alert.
Paragraph (version A):
The expected_cert_verify_algorithm field MUST be of a type advertised
by the client in the SignatureSchemeList and is considered invalid
otherwise.  Clients that receive invalid delegated credentials MUST
terminate the connection with an "illegal_parameter" alert.
Paragraph (version B):
The algorithm field MUST be of a type advertised by the client in the
"signature_algorithms" extension of the ClientHello message and the
expected_cert_verify_algorithm field MUST be of a type advertised by
the client in the SignatureSchemeList and is considered invalid
otherwise.  Clients that receive invalid delegated credentials MUST
terminate the connection with an "illegal_parameter" alert.
Paragraph (version A):
A server that supports this specification SHALL send a
"delegated_credential" extension in the CertificateRequest message
when requesting client authentication.  The body of the extension
consists of a SignatureSchemeList.  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):
A server that supports this specification SHALL send a
"delegated_credential" extension in the CertificateRequest message
when requesting client authentication.  The body of the extension
consists of a SignatureSchemeList.  If the server receives a
delegated credential without having indicated support in its
CertificateRequest, then the server MUST abort with an
"unexpected_message" alert.
Paragraph (version A):
The algorithm field MUST be of a type advertised by the server in the
"signature_algorithms" extension of the CertificateRequest message
and the expected_cert_verify_algorithm field MUST be of a type
advertised by the server in the SignatureSchemeList and considered
invalid otherwise.  Servers that receive invalid delegated
credentials MUST terminate the connection with an "illegal_parameter"
alert.
Paragraph (version A):
Verify that the current time is within the validity interval of
the credential.  This is done by asserting that the current time
does not exceed the expiry time.
Paragraph (version A):
Verify that the delegated credential's remaining validity period
is no more than the maximum validity period.  This is done by
asserting that the expiry time does not exceed the current time
plus the maximum validity period (7 days).
Paragraph (version B):
The algorithm field MUST be of a type advertised by the server in the
"signature_algorithms" extension of the CertificateRequest message
and the expected_cert_verify_algorithm field MUST be of a type
advertised by the server in the SignatureSchemeList and is considered
invalid otherwise.  Servers that receive invalid delegated
credentials MUST terminate the connection with an "illegal_parameter"
alert.
Paragraph (version B):
Verify that the delegated credential's remaining validity period
is no more than the maximum validity period.  This is done by
asserting that the expiry time does not exceed the current time
plus the maximum validity period (7 days by default).
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 is 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 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.