Re: [TLS] Working group last call for draft-ietf-tls-subcerts-07

[Russ Housley <[e-mail]>]

> This is the Working Group Last Call for "Delegated Credentials for TLS" available at https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/ <https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/>.  Please review the document and respond to the list with any comments by June 2, 2020.  

I just reread draft-ietf-tls-subcerts-07.  I have a few comments.


MAJOR

In section 3, the document says:

   The secret key used to sign ...

Please change "secret" to "private".  Later in the sentence, [RFC5280]
is referenced, and it talks about "private key" in this context.


MINOR

Section 1 says:

   This allows server operators to limit the exposure of keys
   in cases where they do not realize a compromise has occurred.

I suggest an alternative:

   This allows server operators to limit the exposure of keys
   in cases where it might be difficult to determine whether a
   compromise has occurred.


Section 1 also says:

   Because the above problems do not relate to the CA's inherent
   function of validating possession of names, ...

The CA is responsible for confirming that the public key in the
certificate corresponds to a private key that can be used by the
certificate subject.  This is usually done by a proof of possession
mechanism.  So, I think that the start of this sentence should be
reworded to avoid the impression that the CA only validates the
name.


QUESTION

While I have no objection to the DelegationUsage extension,
I wonder is an extended key usage would provide the same
confidence in the certificate.


ASN.1 MODULE

After assigning a place holder vale for "TBD", I compiled the
module, and it works just fine.