Draft: draft-ietf-tls-subcerts

Commentary: This suggests some minor changes to the draft , the goal being to clarify the text without changing any semantics . Most are minor , but one of the commits changes the way the client verification procedure is presented . 
 thanks a lot for the fixes , I like all of these changes
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 contrast to
OCSP stapling, in which an operator could choose to talk to the CA
frequently to obtain stapled responses, failure to fetch an OCSP
stapled response results only in degraded performance, however
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, 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):
The signature on the credential indicates a delegation from the
certificate which is issued to the TLS server operator.  The key pair
used to sign a credential is presumed to be one whose public key is
contained in an X.509 certificate that associates one or more names
to the credential.
Paragraph (version B):
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 is presumed to be one whose
corresponding public key is contained in an X.509 certificate that
associates one or more names to the credential.
Paragraph (version A):
It was noted in XPROT that certificates in use by servers that
support outdated protocols such as SSLv2 can be used to forge
signatures for certificates that contain the keyEncipherment KeyUsage
(RFC5280 section 4.2.1.3) In order to prevent this type of cross-
protocol attack, we define a new DelegationUsage extension to X.509
which permits use of delegated credentials.  Clients MUST NOT accept
delegated credentials associated with certificates without this
extension.
Paragraph (version B):
It was noted in XPROT that certificates in use by servers that
support outdated protocols such as SSLv2 can be used to forge
signatures for certificates that contain the keyEncipherment KeyUsage
(RFC5280 section 4.2.1.3) In order to prevent this type of cross-
protocol attack, we define a new DelegationUsage extension to X.509
that permits use of delegated credentials.  Clients MUST NOT accept
delegated credentials associated with certificates without this
extension.
Paragraph (version A):
Delegated credentials allow signed messages to be bound to
specific versions of TLS.  This prevents them from being used for
other protocols if a service owner allows multiple versions of
TLS.
Paragraph (version B):
Delegated credentials are bound to specific versions of TLS.  This
prevents them from being used for other protocols if a service
owner allows multiple versions of TLS.
Paragraph (version A):
These two classes of mechanism can be complementary.  A server could
use credentials for clients that support them, while using LURK to
support legacy clients.
Paragraph (version B):
These two mechanisms can be complementary.  A server could use
credentials for clients that support them, while using LURK to
support legacy clients.
Paragraph (version A):
Verify that the current time is within the validity interval of
the credential.
Paragraph (version B):
Verify that the current time is within the validity interval of
the credential and that the credential's time to live is no more
than 7 days.
Paragraph (version A):
Verify that the certificate has the correct extensions that allow
the use of Delegated credentials.
Paragraph (version A):
Clients that receive Delegated credentials that are valid for more
than 7 days MUST terminate the connection with an "illegal_parameter"
alert.
Paragraph (version B):
Verify that the certificate has the DelegationUsage extension,
which permits the use of Delegated credentials.
Paragraph (version B):
If one or more of these criteria are not met, then the Delegated
credential is invalid.  Clients that receive Delegated credentials
that are invalid MUST terminate the connection with an
"illegal_parameter" alert.
Paragraph (version A):
Conforming CAs MUST mark this extension as non-critical.  This would
allow the certificate to be used by service owners for clients that
do not support certificate delegation as well and not need to obtain
two certificates.
Paragraph (version B):
Conforming CAs MUST mark this extension as non-critical.  This allows
the certificate to be used by service owners for clients that do not
support certificate delegation as well and not need to obtain two
certificates.