I made all of the suggested changes except one as noted below. On 2/17/16, 1:55 PM, "Elwyn Davies" <[email protected]> wrote:
><snip> > >s1, para 2: It would be useful to provide a reference for Certificate >Signing Requests, as well as clarifying that CSR is the relevant acronym >- one possibility might be "Certificate Signing Request (CSR; See, for >example, CertificationRequestInfo in [RFC2986])". I think all that was missing here was placing (CSR) following the first use of Certificate Signing Request. In context, EST is the relevant spec. I added (CSR) after the first use of Certificate Signing Request in the first paragraph and replaced the second use of Certificate Signing Request with CSR in the second paragraph to tie these references together. The first two paragraphs now read: PKCS (Public-Key Cryptography Standards) #9 [RFC2985] defined a challengePassword attribute that has been overloaded by modern protocol usage with the appropriate interpretation being provided by context rather than OID definition. PKCS #9 defines the challengePassword attribute as "a password by which an entity may request certificate revocation". The parsing and embedding of this attribute within Certificate Signing Requests is well supported by common PKI tool sets, but many work-flows leverage this supported field as a one-time password for authentication. For example this is codified in many Simple Certificate Enrollment Protocol (SCEP) implementations as indicated by [I-D.gutmann-scep]. Continuing this trend, Enrollment over Secure Transport (EST) [RFC7030] defines an additional semantic for the challengePassword attribute in Section 3.5, in order to provide a linking of the Certificate Signing Request (CSR) to the secure transport. Where the context of the protocol operation fully defined the proper semantic, and when only one use was required at a time, the overloading of this field did not cause difficulties. Implementation experience with EST has shown this to be a limitation though. There are plausible use cases where it is valuable to use either of the existing methods separately or in concert. For example an EST server might require the client to authenticate itself using the existing client X.509 certificate, the user's username and password and to include a one-time password within the CSR all while maintaining identity linking to bind the CSR to the secure transport. The overloading of a single attribute type should not be the limiting factor for administrators attempting to meet their security requirements. > ><snip> _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
