Subject: Re: [pkix] SCEP vs CMC vs CMP

From: max pritikin <[email-masked]>
Date: Mon, 21 Mar 2011 15:38:10 -0700

Stefan did a great job reflecting on this thread. In particular I'd like to call out this statement from below:

> I do therefore believe that it is extremely important that we can modularize
> this issue and try to find what basic protocol features that we reasonably
> can standardize, that actually will help the market, and what things we have
> to keep our fingers away from.

I think the goals we can reasonably meet are:

- SIMPLE to implement module on a common tool stack
	focusing on certificate requests and responses
- reasonable progression from the current solutions & protocols
- clear suite b compatibility options
- clear growth path for future work such as,
	authentication & authorization mechanisms
	ongoing lifecycle management 

Which existing tools we assume to be available influences the design. As Stefan notes various solutions such as Microsoft's WS-MS_STEP can be very well suited for their intended purpose but not be sufficiently generic enough (not to pick on MS, there are many other examples). We must carefully pick the dependencies that can reasonably be met. 

I have a published a draft concerning Enrollment over Secure Transport which I feel meets these goals and provides a reasonable balance point. It builds on existing tools stack of HTTP+TLS (HTTPS) with common certificate object's like PKCS#10/CRMF and raw certificates but does not also _force_ clients/servers to understand SOAP and XML and various WS layers or PKCS#7/CMS messages (these are always options for other modules). It achieves much simplification by NOT being transport independent. 

This is part of my thoughts about how we could move enrollment and thus PKI forward: 
	http://tools.ietf.org/html/draft-pritikin-est-00

It is an intentionally small step. Sometimes progress involves removing extra complexities as much as building new things.

Thanks,

- max

Regarding SCEP: I'd like to see this document published and finalized in a way that accurately reflects its current role so we can move forward. 

On Oct 31, 2010, at 3:11 AM, Stefan Santesson wrote:

> Reflecting on the whole thread.
> 
> I admit that I'm not an expert on mobile certificate enrollment and it's
> needs, but coming from working with Microsoft certificate enrollment for
> quite some years my primary take on this problem space is that it is
> modular.
> 
> There will never be one specification that deals with everything that has to
> do with certificate enrollment that will follow one generic model.
> 
> In the lower layers we have the certificate request and response messages.
> This is the easiest part. On the higher levels we have the certificate
> lifecycle logic that depends on a million factors that we will never be able
> to capture or cover even in a few documents.
> 
> Microsoft certificate enrollment was built upon active directory and the
> group policy logic (GPO) for distribution of enrollment templates. This is
> is a very well suited method for what it was supposed to do and offers
> auto-enrollment but it is clearly not a generic solution.
> 
> My guess is that we have similar issues with mobile enrollment where other
> mobile specific lifecycle issues comes into play. One obvious factor is the
> one that Anders pointed out, who is the originator of the decision to enroll
> (client or server). Microsoft did what apparently others have done, they
> used a client centric enrollment protocol to build a server centric
> enrollment model by adding layers of logic on top of the enrollment
> protocol.
> 
> I do therefore believe that it is extremely important that we can modularize
> this issue and try to find what basic protocol features that we reasonably
> can standardize, that actually will help the market, and what things we have
> to keep our fingers away from.
> 
> --------------------
> 
> On the SCEP standardization issue it worries me that we have a widely
> deployed protocol that has no stable RFC reference. I think we should change
> that as soon as possible. I know we have said that before (in PKIX meetings)
> but it seems to not happen. What can we change to make it happen?
> 
> Then I think the next step is to figure out where we can go from there in
> order to actually do something that make sense in the total picture. I
> totally agree that this is an issue well worth investing efforts in.
> 
> /Stefan
> 
>

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 22 Mar 2011 15:02:49 +1300

max pritikin <[email-masked]> writes:

>Regarding SCEP: I'd like to see this document published and finalized in a
>way that accurately reflects its current role so we can move forward.

<grumble>I'd like to see it incorporate some of the feedback that's been
submitted for it, e.g. consistency problems with hash algorithm use, removing
MD5 and DES (!!!) as the mandatory algorithms, switching from the decade-old
PKCS #7 to the current CMS, and a pile of other stuff that's been requested
over time but ignored by the authors</grumble>.

Peter.

---

From: max pritikin <[email-masked]>
Date: Mon, 21 Mar 2011 22:50:21 -0700

re: SCEP

I wasn't involved in the full history of SCEP but my understanding is that a lot of these things you ask about were addressed ---- in the CMC document. Ideally SCEP would have gone away naturally but that didn't happen. I believe the reasons are 'water under the bridge' ... but what we should address now is an existing SCEP document that is widely implemented and the continued confusion.

I currently have the edit token for SCEP and I have been responsive to all requests for edits or clarifications. If you have clarifications about the text describing the existing and widely implemented version(s) of SCEP please feel free to send them to me. Unfortunately the more updates and changes the more it appears to be an active document.

Personally I'd prefer to finalize it "as is" and address improvements and modern requirements in a new document. 

- max