Hi, Carl.
Thanks for the response.
Pending the publication of an updated draft, if you have a snapshot of
the updated version, I am happy to run my eye over the changes. I would
be particularly interested to have a look at what you propose for the
last sentence of s4.
As regards the CSR stuff below, trivially, there is a previous instance
of Certificate Signing Request(s) on line 7. More importantly, I had a
look at the EST draft and it doesn't seem to define a CSR but talks
immediately about CSR attributes (possibly an oversight there). Looking
at Wikipedia (OK, that is a dangerous pursuit ;-) ), I am told that CSR
and Certification Request are equivalent terms but definitions of the
actual term CSR in standards documents are few and far between, to the
extent that I couldn't see one in the various Google responses. OTOH
Certification Request is defined in the Security Glossary (RFC 4949). I
think it would be worth noting the equivalence of the terms and pointing
to one or both of RFC 4949 and PKCS #10 - RFC 2986.
Regards,
Elwyn
On 22/02/2016 13:12, Carl Wallace wrote:
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
