Draft: draft-ietf-tls-subcerts

Commentary: Need to address and directorate reviews . 
 Correction  editorial are addressed via and . 
 and . 
 Looks good
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 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 B):
The organizational separation between operators of TLS and DTLS
endpoints 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 TLS and DTLS without breaking
compatibility with peers that do not support this specification.
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 TLS-fronted service.
Paragraph (version B):
However, short-lived certificates need to be renewed more frequently
than long-lived certificates.  If an external Certification Authority
(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):
To reduce the dependency on external CAs, this document proposes 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 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 A):
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 B):
This document refers 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):
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 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
is not necessary.  For this reason, delegated credentials have
very restricted semantics that should not conflict with X.509
semantics.
Paragraph (version A):
We define 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 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):
The operational consideration documented in this section should be
taken into consideration when using Delegated Certificates.
Paragraph (version B):
The security consideration documented in this section should be taken
into consideration when using Delegated Certificates.