Subject: [pkix] Last Call: <draft-ietf-pkix-est-07.txt> (Enrollment over Secure Transport) to Proposed Standard

From: The IESG <[email-masked]>
Date: Mon, 10 Jun 2013 07:45:18 -0700

The IESG has received a request from the Public-Key Infrastructure
(X.509) WG (pkix) to consider the following document:
- 'Enrollment over Secure Transport'
  <draft-ietf-pkix-est-07.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2013-06-24. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document profiles certificate enrollment for clients using
   Certificate Management over CMS (CMC) messages over a secure
   transport.  This profile, called Enrollment over Secure Transport
   (EST), describes a simple yet functional certificate management
   protocol targeting Public Key Infrastructure (PKI) clients that need
   to acquire client certificates and associated Certification Authority
   (CA) certificate(s).  It also supports client-generated public/
   private key pairs as well as key pairs generated by the CA.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-pkix-est/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-pkix-est/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: Russ Housley <[email-masked]>
Date: Mon, 10 Jun 2013 14:45:06 -0400

I have read the document, I a support publication on the standards track.

Russ

---

From: SM <[email-masked]>
Date: Wed, 12 Jun 2013 00:42:01 -0700

Hi Sean,
At 16:13 11-06-2013, Sean Turner wrote:
>This bit I don't agree with.  PKCS#10 is the way most PKI 
>enrollments occur.  RFC 2986, which is where PKCS#10 is documented, 
>is updated by RFC 5967 because the draft that contained the 
>media-type registration was obsoleted.
>
>This draft is a nod to the fact that PKCS#10 is the way it's done 
>and it's one via the web (not email) with TLS as the secure 
>transport (not S/MIME/CMS).  The kicker here is that it's actually 
>been implemented and not just by the authors.
>
>As for the TLS version, well I'm hoping 1.1 will be overtaken by 
>events in short order but that compromise has been worked out and 
>documented in a number of drafts.

Thanks for the feedback.  I am ok with the draft.

In Section 3.6.2:

   "When the EST client Implicit TA database is used to validate the EST
    server certificate, the client MUST check the URI "against the
    server's identity as presented in the server's Certificate message"
    (HTTP Over TLS Section 3.1 "Server Identity" [RFC2818] and
    [RFC6125])"

I would use RFC 6125 only, specifically the URI-ID (see Section 3 of 
RFC 6125 for the discussion).

In Section 4.3.2:

   "When rejecting a request, the server MUST specify either an HTTP 4xx
    error or an HTTP 5xx error."

I would be more specific about the HTTP code or defer to RFC 2616 to 
catch the possible error conditions.  I'll adapt some suggested text 
from RFC 6712:

   A server MUST answer with a suitable 4xx or 5xx HTTP error code
   when a problem occurs.

In Section 6, I suggest dropping the RFC 2119 key words for the IANA paperwork.

in Section 7, there is a typo:

   "It is RECOMMEND that EST servers not support this operation by default."

Regards,
-sm