Draft: draft-ietf-tls-subcerts

Commentary: IESG comments
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 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 B):
Server operators often deploy (D)TLS termination to act as the server
for inbound TLS connections.  These termination services can be 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):
To reduce the dependency on external CAs, this document specifies a
limited delegation mechanism that allows a (D)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.
Furthermore, this mechanism allows the server to use modern signature
algorithms such as Ed25519 RFC8032 even if their CA does not support
them.
Paragraph (version B):
To reduce the dependency on external CAs, this document specifies a
limited delegation mechanism that allows a (D)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 terminate connections for names that the CA has
authorized.  Furthermore, this mechanism allows the server to use
modern signature algorithms such as Ed25519 RFC8032 even if their CA
does not support them.
Paragraph (version A):
Specify undefined behavior in a few cases: when the client
receives a DC without indicated support; when the client indicates
the extension in an invalid protocol version; and when DCs are
sent as extensions to certificates other than the end-entity
certificate.
Paragraph (version B):
Specify undefined behavior in a few cases: when the client
receives a DC without indicated support; when the client indicates
the extension in an non-valid protocol version; and when DCs are
sent as extensions to certificates other than the end-entity
certificate.
Paragraph (version A):
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) based on the default (see solution-overview.
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 the sender's CertificateVerify.algorithm (as described
in validating-a-delegated-credential).  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):
Time, in seconds relative to the delegation certificate's
notBefore value, after which the delegated credential is no longer
valid.  By default, unless set to an alternative value by an
application profile (see Section solution-overview), endpoints
will reject delegated credentials that expire more than 7 days
from the current time (as described in validating-a-delegated-
credential).
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 the sender's CertificateVerify.algorithm (as described
in validating-a-delegated-credential).  Only signature algorithms
allowed for use in CertificateVerify messages are allowed (as
described in RFC8446 Section 11).  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 A):
The algorithm field MUST be of a type advertised by the client in the
"signature_algorithms" extension of the ClientHello message and the
dc_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
dc_cert_verify_algorithm field MUST be of a type advertised by the
client in the SignatureSchemeList and is considered not valid
otherwise.  Clients that receive non-valid delegated credentials MUST
terminate the connection with an "illegal_parameter" 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 dc_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):
The algorithm field MUST be of a type advertised by the server in the
"signature_algorithms" extension of the CertificateRequest message
and the dc_cert_verify_algorithm field MUST be of a type advertised
by the server in the SignatureSchemeList and is considered not valid
otherwise.  Servers that receive non-valid delegated credentials MUST
terminate the connection with an "illegal_parameter" alert.
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.
Paragraph (version B):
If one or more of these checks fail, then the delegated credential is
deemed not valid.  Clients and servers that receive non-valid
delegated credentials MUST terminate the connection with an
"illegal_parameter" alert.
Paragraph (version A):
This documnt defines a new X.509 extension, DelegationUsage, to be
used in the certificate when the certificate permits the usage of
delegated credentials.  What follows is the ASN.1 X.680 for the
DelegationUsage certificate extension.
Paragraph (version B):
This document defines a new X.509 extension, DelegationUsage, to be
used in the certificate when the certificate permits the usage of
delegated credentials.  What follows is the ASN.1 X.680 for the
DelegationUsage certificate extension.
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 impersonate
the compromised party in new TLS connections until the delegated
credential expires.
Paragraph (version A):
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 cannot create
new delegated credentials, but they can impersonate the compromised
party in new TLS connections until the delegated credential expires.
Paragraph (version B):
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):
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 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 (by default) 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 B):
Delegated credentials can be valid for 7 days (by default) 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):
equivalent of a man-in-the-middle certificate, valid for a maximum of
7 days (if the default valid_time is used).
Paragraph (version B):
equivalent of a on-path-attacker, valid for a maximum of 7 days (if
the default valid_time is used).