Draft: draft-ietf-tls-subcerts

Commentary: Just some nits . 
 The public key name and type have been changed in , as suggested on the mailing list . 
 beat me to it ! 
 oh looks like the travis build is failing for some reason 
 I have no idea why pushing that worked ... 
 awesomesauce . it 's probably some temporary failure while trying to fetch the new references or something
Paragraph (version A):
The organizational separation between the operator of a TLS server
and the certificate 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 certificate
authority.  This document describes a mechanism by which operators
may delegate their own credentials for use in TLS, without breaking
compatibility with clients that do not support this specification.
Paragraph (version B):
The organizational separation between the operator of a TLS server
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 TLS,
without breaking compatibility with clients that do not support this
specification.
Paragraph (version A):
These dependencies cause problems in practice.  Server operators
often want to create short-lived certificates for servers in low-
trust zones such as CDNs or remote data centers.  This allows server
operators to limit the exposure of keys in cases that they do not
realize a compromise has occurred.  The risk inherent in cross-
organizational transactions makes it operationally infeasible to rely
on an external CA for such short-lived credentials.  In OCSP
stapling, if an operator chooses to talk frequently to the CA to
obtain stapled responses, then failure to fetch an OCSP stapled
response results only in degraded performance.  On the other hand,
failure to fetch a potentially large number of short lived
certificates would result in the service not being available, which
creates greater operational risk.
Paragraph (version B):
These dependencies cause problems in practice.  Server operators
often want to create short-lived certificates for servers in low-
trust zones such as CDNs or remote data centers.  This allows server
operators to limit the exposure of keys in cases that they do not
realize a compromise has occurred.  The risk inherent in cross-
organizational transactions makes it operationally infeasible to rely
on an external CA for such short-lived credentials.  In OCSP stapling
(i.e., using the Certificate Status extension types ocsp RFC6066 or
ocsp_multi RFC6961), if an operator chooses to talk frequently to the
CA to obtain stapled responses, then failure to fetch an OCSP stapled
response results only in degraded performance.  On the other hand,
failure to fetch a potentially large number of short lived
certificates would result in the service not being available, which
creates greater operational risk.
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 TLS
server operator.  The secret key used to sign a credential
corresponds to the public key of the X.509 end-entity certificate.
Paragraph (version B):
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 TLS
server operator.  The secret key used to sign a credential
corresponds to the public key of the TLS server's X.509 end-entity
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., 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 A):
The credential's public key, a DER-encoded SubjectPublicKeyInfo as
defined in RFC5280.
Paragraph (version B):
The credential's public key, a DER-encoded X690
SubjectPublicKeyInfo as defined in RFC5280.