> 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.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
