Subject: [pkix] Fwd: New Version Notification for draft-pritikin-est-01.txt

From: max pritikin <[email-masked]>
Date: Fri, 13 May 2011 16:55:39 -0600

Thank you everybody that engaged in discussion both on and off this list about enrollment. I've made the following changes to the draft for those of you who are interested:

- Section 3 now provides a requirements discussion. Hopefully additional conversations can use this to clarify what requirements the proposal does or does not meet. 

- Section 8.6 now provides a proof-of-posession method. The security considerations section no longer calls this out as a lack/problem.

Username/password and PIN based authentication of clients is discussed in detail but the transport method used is still the HTTP Basic Authentication. There is a discussion in the security vulnerabilities concerning sending a cleartext password to even an authenticated server over a TLS connection. 

This draft continues to toe the line between a profile of CMC and a fully independent simpler alternative. I've very much appreciated the mailing list discussions and am continuing to improve the draft and my reference implementation(s).  

Thanks for any continued feedback,

- max

Begin forwarded message:

> From: [email-masked]
> Date: May 13, 2011 4:53:14 PM MDT
> To: [email-masked]
> Cc: [email-masked]
> Subject: New Version Notification for draft-pritikin-est-01.txt
> 
> A new version of I-D, draft-pritikin-est-01.txt has been successfully submitted by Max Pritikin and posted to the IETF repository.
> 
> Filename:	 draft-pritikin-est
> Revision:	 01
> Title:		 Enrollment over Secure Transport
> Creation date:	 2011-05-13
> WG ID:		 Individual Submission
> Number of pages: 22
> 
> Abstract:
>   This document specifies certificate Enrollment over Secure Transport
>   (EST).  EST is a certificate enrollment over HTTPS protocol that is
>   trivially accessible by modern clients.  The CMC &quot;Simple PKI
>   Messages&quot; and simple certificate responses are leveraged and EST is
>   designed to be easily implemented by clients and servers running
>   other common enrollment mechanisms such as SCEP.  Renewal and rekey
>   mechanisms are described consistent with CMP.
> 
> 
> 
> 
> The IETF Secretariat

---

From: Anders Rundgren <[email-masked]>
Date: Sat, 14 May 2011 16:36:53 +0200

On 2011-05-14 00:55, max pritikin wrote:
> 
> Thank you everybody that engaged in discussion both on
> and off this list about enrollment. I've made the following
> changes to the draft for those of you who are interested:
> 
> - Section 3 now provides a requirements discussion.
> Hopefully additional conversations can use this to clarify
> what requirements the proposal does or does not meet.

Max,

I still don't get what the scope is.  Although iPhone utilizes
SCEP, there is an Apple-specific enrollment XML-based "profile bootstrap"
pass which IMO greatly enhances usability in addition to addressing
authentication in a universal fashion.

Another possible target are CMSes (Card Management Systems).

The overarching question remains: Have Apple, Microsoft, Google
or CMS vendors actually expressed a need for a new/revised
protocol?

Anders

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

---

From: max pritikin <[email-masked]>
Date: Mon, 16 May 2011 09:47:46 -0600

On May 14, 2011, at 8:36 AM, Anders Rundgren wrote:

> I still don't get what the scope is.

Please see the draft-pritikin-est-01 text: Introduction, Overview, and Requirements. They are not long. 

My goal is a 'common enrollment protocol for end points'. Whatever else is positive or lacking wrt PKI technologies I'd like to see this area improved. 

The idea of continued "X-specific enrollment" is exactly what I'd like to see go away. 

- max

>  Although iPhone utilizes

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 16 May 2011 22:21:17 +0200

> The idea of continued "X-specific enrollment" is exactly what I'd like to see go away. 

I'm going here next week:

http://www.w3.org/2011/identity-ws

IMO, a browser-based enrollment scheme should be possible to apply
to [close to] all enrollments where a human performs a part of the
client-side process.  If a networked device hasn't a browser interface
it must today be considered as "marginal".

However, browsers do not speak ASN.1 except as a part of an
inner structure so obviously there is a "impedance mismatch"
between PKIX-related enrollments and browser-based enrollments.

Note: HTTP bindings <> Browser bindings since the latter
is built on some kind of language or format.

Anders