Subject: [apps-discuss] AppsDir review of draft-ietf-pkix-est-07

From: Tobias Gondrom <[email-masked]>
Date: Tue, 25 Jun 2013 16:28:53 +0800

I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see ​
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-pkix-est-07
Title: Enrollment over Secure Transport
Reviewer: Tobias Gondrom
Review Date: 25.6.2013

Summary: The draft looks fine.
It is heading for STD track and mostly describes Simple PKI over TLS
(and using the protected channel mechanisms for mutual authentication as
well (beyond simple confidentiality)).

comments:

1. section 2.2.2 and 2.2.3
( client verification.)
(Certificate-less TLS (e.g., with a shared credential distributed
out-of-band);
and HTTP-based with a username/password distributed out-of-band.)

make sure to avoid information leakage. E.g. in case of certificate-less
TLS, if cookies are used, make sure that are not transmitted over the
normal unprotected HTTP band.
(section 3.2.3 already specifies that "HTTP Basic and Digest
authentication MUST only be performed over TLS 1.1 [RFC4346] or later
versions." which is good.)

2. section 3.2.4:
when registering  "application/csrattrs" with IANA in section 6
I see you have no Magic number or file extension.
Is there a chance that this request might at some point be made without
direct HTTP and might want some of the two?

3. section 3.2.2:
as you want to offer to use HTTP POST and GET.
I am not so happy about the HTTP GET parts. How do you consider the risk
of information leakage with HTTP GET when you have e.g. labels?
e.g. in case of    "2. 
https://www.example.com/.well-known/est/arbitraryLabel1/cacerts"

Second you may consider to note URI length limitations in GET requests. 

nits:
page 32
s/to use the the secp384r1 elliptic curve/to use the secp384r1 elliptic
curve

Oh and you should clean up idnits:
 ** Downref: Normative reference to an Informational RFC: RFC 2986
  ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246)

Best regards, Tobias

---

From: Barry Leiba <[email-masked]>
Date: Tue, 25 Jun 2013 08:54:10 -0400

Thanks for the appsdir review, Tobias.

>  ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246)

No, they're fine.  2986 is PKCS #10, and is in the downref registry:
http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry

And 4346 is TLS 1.1, needed for the "HTTP Basic and Digest
authentication MUST only be performed over TLS 1.1 [RFC4346] or later
versions." that you mention earlier in the review.

Barry

---

From: Tobias Gondrom <[email-masked]>
Date: Tue, 25 Jun 2013 22:00:06 +0800

Ah I see. Thanks for the clarification.
Best regards, Tobias
Ps.: my standard procedure is to include the idnits.
Maybe in the future shall also include the DownrefRegistry. ;-)