Subject: [pkix] I-D Action: draft-ietf-pkix-est-02.txt

From: [email-masked]
Date: Tue, 10 Jul 2012 14:54:09 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title           : Enrollment over Secure Transport
	Author(s)       : Max Pritikin
                          Peter E. Yee
                          Dan Harkins
	Filename        : draft-ietf-pkix-est-02.txt
	Pages           : 46
	Date            : 2012-07-10

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 simple Public Key Infrastructure clients that need
   to acquire client certificate(s) and associated Certification
   Authority (CA) certificate(s).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pkix-est

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-pkix-est-02

A diff from previous version is available at:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-pkix-est-02

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Peter Yee" <[email-masked]>
Date: Tue, 10 Jul 2012 15:14:47 -0700

This is a substantially revised draft from the previous one we posted.  A
lot
of reorganization of the text has been done for clarity.  We've also added
a fair amount of new text which we hope makes the intent of the protocol
clearer.  In addition to that, we've also incorporated the CSR attributes
draft from Dan Harkins and Sean Turner, with Dan joining us as an editor
of the document.  We've dropped the crypto algorithms section for now,
although we're considering a secondary draft which will address TLS
cipher suites for use with EST.  Support for server-generated keys is now
available for cases where the client does not want to or cannot generate
its own keys.  New tables provide a handy means to collate pointers to
the various parallel sections of the document.

Your input on the document would be most welcome.  This draft
represents our response to the large amount of input we received from
interested parties.

Max, Dan, and I look forward to presenting our update in Vancouver and
seeing you there.

Thank you.

		-Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, July 10, 2012 2:54 PM
To: [email-masked]
Cc: [email-masked]
Subject: [pkix] I-D Action: draft-ietf-pkix-est-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
 This draft is a work item of the Public-Key Infrastructure (X.509) Working
Group of the IETF.

Abstract:

_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: Sean Turner <[email-masked]>
Date: Fri, 27 Jul 2012 11:15:31 -0700

I reviewed this draft.  I sent my editorial nits to the editors/chairs 
directly, but I've got some comments/questions too that I'd like to talk 
about at the session (or via email).  Not wanting to surprise you:

- In s2.1 - If it's just about getting a TA to verify the EST server's 
cert that's a whole different set of text to just getting a self-signed 
EST server cert.  In the later case don't you just get it from the TLS 
exchange?

- In s2.3/2.3.1 - Why would use HTTP Basic/Digest authentication if 
you're rekeying/renewing?  Is this only going to be the case where 
you're using a cert but it's expired?  If so then we need to move that 
to 3rd para.

- In s2.3.1 - Need to add some text to allow for name changes in 
certificate requests.  See 6402 attribute.  I found it much later in the 
draft, but it'd be worth adding some text earlier.

- In s2.3.2 - Requiring a client cert before it gets ke cert is okay by 
me, but is this one of those times where we want to allow the ke key to 
be used once to do the request?  Maybe it's loaded by a manufacturer and 
that's all it's got?

- HTTP Basic or Digest Authentication - is it just basic or basic or 
does it also allow digest?  There's two in 2617.  I think it's both, but 
the draft waffles sometimes.

- In s3.3 - seems like the text about the HTTP persistent connections 
ought to be in the earlier section which is about HTTP layer design and 
not in the HTTP layer design section.

- In s3.3.1.1 - method 1 discusses a client having TAs for the server 
and method 2 also discusses a client having TAs for the server.  Is the 
difference that method 1 is for when the EST server is fronting for a CA 
and method 2 is about the EST server fronting for an RA?  If that's the 
case, then I'd make that much clearer.

- In s3.3.1.1 - Please explain the rationale for requiring that 
subsequent connections using method 3 initially should result in using 
method 2 in subsequent connections?  If I accept a cert in the initial 
connection that doesn't have the ra EKU set what happens?

- In s4.1 - why MUST the EST server's cert be an EE cert?

- in s4.1 - The methods kind of read like steps: if then else.  I think 
it might be better either make them methods or call them steps.

- in s4.1 - Can you explain the RA authorization policy OID?  Is it just 
one OID or is a new extension?

- in s4.3 - I think it says the client can continue even if the 
authentication fails, but that contradicts the earlier section that says 
the client MUST reject the connection if authentication fails.

- in s4.3.1 - I liked the way section 4.4.2 addressed both positive and 
negative responses.  Consider rewording s4.3.1 to be more like 4.4.2.

- in s4.6 - I know my co-AD will cream you on the NULL cipher suite. 
It's true they are inately "secure" but that's only for authentication 
and not integrity.  There's no privacy/confidentially protection.

- in full CMC - where's the restriction for method 3 come from?

- server key generation - I'm still thinking about this section.

- in s5: If there's a certificate extension to be registered we'll get 
the OID from Russ, as he controls the PKIX Arc.

spt