Subject: Re: [pkix] Gen-art LC review of draft-wallace-est-alt-challenge-04

From: Carl Wallace <[email-masked]>
Date: Mon, 22 Feb 2016 08:12:00 -0500

I made all of the suggested changes except one as noted below.

On 2/17/16, 1:55 PM, "Elwyn Davies" <[email-masked]> 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>

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 17 Feb 2016 18:55:41 +0000

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-wallace-est-alt-challenge-04.txt
Reviewer: Elwyn Davies
Review Date: 2016/02/17
IETF LC End Date: 2016/03/07
IESG Telechat date: (if known) -

Summary: Almost ready.  There is one very minor issue and a number of 
nits. IDNITS identifies a downref (RFC 5912) but this is already in the 
downref registry (re RFC 5913) so no further action is needed, I believe.

Major issues:
None.

Minor issues:
s4, last sentence:
> EST clients that include the
>     "estIdentityLinking" attribute SHOULD NOT also include the
>     "challengePassword" attribute.
I think this ought to be MUST NOT.  In any case, the behaviour of EST 
servers that receive a request with both challengePassword and 
estIdentityLinking defined should be more carefully specified. 
Similarly, I assume that the EST server should not respond to a 
/csrattrs request by specifying both of these attributes

Nits/editorial comments:
Abstract: s/PKCS #9 challengePassword attribute/challengePassword 
attribute defined in PKCS (Public-Key Cryptography Standards) #9 (RFC 2985)/

s1: s/PKCS/PKCS (Public-Key Cryptography Standards)/

s1: s/One-Time Password/one-time password/ (two places)

s1, para 1: Good to associate the acronym EST with its expansion here as 
well as in abstract: s/Enrollment over Secure Transport/Enrollment over 
Secure Transport (EST)/

s1: Expand SCEP on first (only) use (Simple Certificate Enrolment Protocol)

s1: Need to expand TLS on first use (apparently not a well-known 
acronym!  However HTTP is.)

s1, last para: s/is not intended to/are not intended to/

s3.1: s/upper bound/maximum length/ seems clearer to me.

s3.1, para 1: s/of the values/of the value/

s3.2, section title: Shouldn't this section be titled either:
      Alternative to PKCS #9 Challenge Password Attribute
or
      Revocation Challenge Attribute
?

s3.2, para 1, sentence 2: s/revocation Challenge/revocationChallenge/

s4: A reference for the definition of /csrattrs would be useful. Suggest:
OLD:
in the /csrattrs.
NEW:
in the HTTP control URI path /csrattrs (see Sections 3.2.2 and 4.5 of 
[RFC7030]).

s5: I fear that you ought to provide the full titles of RFC 4226 and RFC 
6238 to expand HOTP and TOTP ( or just omit the acronyms, since they are 
in the reference expansions.)

s6: Probably ought to reference RFC 7107 as the registry defining RFC  
(it isn't referenced otherwise).

s6: Ought to have an RFC editor note to replace the TBDx references in 
s3 and Appendix A.

s7: IMO RFC 2985 and RFC 7030 are normative.  RFC 7107 could also be 
considered normative.

s7.2: AFAICS RFC 7299 is not referenced.

Non-issue:
s7.1: IDNITS complains that RFC 5912 is a downref.  However, RFC 5912 is 
already in the downref registry (re RFC 5913) and so should not need 
further downref approval I believe.

---

From: Elwyn Davies <[email-masked]>
Date: Tue, 23 Feb 2016 18:12:49 +0000

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