Subject: Re: [pkix] Certificate enrollment at Beijing IETF?

From: Massimiliano Pala <[email-masked]>
Date: Wed, 03 Nov 2010 12:21:25 -0400

Hi Peter, all,

Being an "active" developer and having being around in the PKI world for
a while I share your vision.

I think that the success of SCEP is due to its simplicity in its development:
all the data structures used are easily understood by developers and the
implementation is therefore straightforward.

Anyhow, I do admit that SCEP can not cover all the possible scenarios that
CMP & CMC tried to address.

My proposal, if the WG Chair(s) would consider working on the matter, would
be to:

(1) Analyze what of the CMP & CMC standards we could reasonably save.

(2) Provide a simple (updated version of SCEP) and an advanced (taylored
     vesion of CMP/CMC) enrollment protocols in two new working items. The
     simple protocol (DER message based, no requirements on the transport
     protocol used so that we can have different - also binary and not only
     HTTP - transport protocols used) could be an I-D on standard track and
     the advanced one can be experimental. These two WI will update the
     current RFCs.

(3) If the experimental does not get deployment/implementations in a reasonable
     amount of time, we declare that dead with the idea to periodically raise
     the issue to get a feeling if it is time to start working on that item
     again (Internet Advanced PKI Enrollment Protocol or IAPEP). This draft
     could be more targeted towards special environments like cell-phones,
     home appliances, and other devices with specific requirements/constraints
     (e.g., not smart-phones, those can handle the simple ISPEP - see point #4)

(4) We move (quite quicly) forward the simple enrollment protocol (Internet
     Simple PKIX Enrollment Protocol or ISPEP). I guess I will be more than happy
     to work on it and deploy it reasonably fast in OpenCA -> many many deployed
     CAs out there.

I think we will finally be able to see some real deployment that does not
involve HTTP forms to get certificates also for client software (eg., browsers)
and not only in (many) non-user centric environments.

In any case, if we go with a ISPEP (SCEPv2) approach, there are two aspects
we should add (still keep it simple!):

(a) One thing that is lacking from current enrollment environment is the
     possibility for a client application to query the CA for the required
     data to be submitted when requesting a certificate (that can be data
     to be put in the DN and/or other data that will not be present in the
     final certificate) so that the application can get the data from the
     user when this is possible without going through the enrollment process
     just to see the request rejected for the lack of some data.

(b) I would "standardize" (and let me know if this is already done) a new
     extension in the PKCS#10 request profile capable of carrying the data
     requested by the CA (point a). This could be done as signed extensions
     in the outer CMS bag or directly in the PKCS#10 request (preferred as
     from the CA point of view, that's the data I am going to keep)

Sorry for the long email, but I think many CA vendors and PKIX-developers
are *really* interested in this matter.. AFAIK.

Just my 2 cents,

Best,
Max

On 11/03/2010 12:00 AM, Peter Gutmann wrote:
> Here's a counter-proposal, based on actual reality rather than PKIX fantasy:
>
> CMP is effectively dead, and has been since the 2001-2002 time frame [0].
> Recommendation: Move the RFC to historic status, which it has been for the
> last eight years or so.
>
> CMC doesn't seem much better off than CMP, it's effectively just a
> Microsoft-internal cert-provisioning protocol (I'm assuming that if there was
> widespread real-world use of CMC outside of Windows then someone would have
> leapt in by now to say so [0]).  Recommendation: Hand change control back to
> MS so they don't have to go through the overhead of laundering things via the
> IETF, and make the existing RFC historical (I'm assuming this makes things
> easier for MS, but I don't know what their policy is on in-house vs. nominally
> outsourced protocol standardisation).
>
> SCEP is the only one of the three that's actively deployed and used in a
> homogeneous environment, and that's being actively developed by more than the
> one vendor who pushed it.  Everyone seems to have focused on use by the iPhone
> simply because it was the first thing that I mentioned when it was claimed
> that it was used for routers only, but that was only because it was the most
> recent use of SCEP that I'd encountered.  Firstly, don't forget the other side
> of the connection, which was Windows Server, not exactly a minor platform.
> Beyond that it crops up all over the place, it's the standard for provisioning
> gaming machines with certs, it's in a bunch of SCADA security profiles for
> particular industries (actually in general it's used in a scary amount of
> SCADA stuff that needs certs), I keep seeing it pop up all over the place.
> For the three protocols I've had a total of zero requests for CMC, about one
> every year or two for CMP (and that's before they realise what they're getting
> into, apart from one large cellphone vendor I don't know of any that continued
> with CMP, and even the cellphone vendor stopped trying to use it the last I
> heard), and SCEP just keeps popping up again and again.  Recommendation:
> Freeze and publish the current version as SCEPv1 and then do a quick clean-up
> to move it out of the mid-90s (RSA only, PKCS #7, MD5 as default hash) with
> lots of stuff kludged on via HTTP extensions, and publish it as
> standards-track SCEPv2.

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]                   [email-masked]
                                                  [email-masked]

Dartmouth Computer Science Dept               Home Phone: +1 (603) 369-9332
PKI/Trust Laboratory                          Work Phone: +1 (603) 646-8734
--o------------------------------------------------------------------------
People who think they know everything are a great annoyance to those of us
who do.
							   -- Isaac Asimov

---

From: Stephen Kent <[email-masked]>
Date: Wed, 3 Nov 2010 13:08:56 -0400

At 5:00 PM +1300 11/3/10, Peter Gutmann wrote:
>Stephen Kent <[email-masked]> writes:
>
>>An agreement was reached (including the PKIX co-chairs, the Security ADs, and
>>the IETF chair) well over a year ago. The agreement called for the 
>>SCEP I-D to
>>be cleaned up and published as Informaitonal and Historic. It would contain
>>text that noted the limitations of that protocol compared to the PKIX
>>standards (CMC & CMP), and would recommend that new implementations 
>>of clients
>>and CAs employ these standards in the future.
>
>So the "solution" is to deprecate the widely-deployed, actively-used protocol
>that "they" developed in favour of the two no-hope launch-failures that "we"
>developed?

A big company (e.g., Cisco, Juniper, MS, Google, ...) may promote and 
publish any protocols that it develops.  Such companies, because of 
their market presence, often can persuade others to adopt their 
protocols, whether good or bad, IETF-endorsed or not. In general, the 
IETF does not rubber-stamp a company-developed, de facto standard 
just because it is popular. We (at least some of us) also do not like 
to publish, even as informational, a document that describes a 
protocol that was developed outside the IETF in direct competition to 
standards that were developed within the IETF. The rationale is that 
it encourages vendors to circumvent the process, and acquire the 
imprimatur of the IETf for their protocols when published as RFCs 
(since the "Informational" label is often ignored).

Since Max is a new editor for the SCEP document, I am not suggesting 
that he is responsible for the current situation. Nonetheless, I 
belive that the agreement reached a couple of years ago should 
prevail.

If PKIX elects to pursue a lighter-weight cert request protocol, or a 
variant of one of our extant standards, we can do so. We would start 
with the development of a requirements document, then allow folks to 
propose solutions relative to those requirements. Then pick a winner 
(if we have multiple solution candidates).  That what we did for SCVP 
(which, after all, is just one letter away from SCEP :-)).

Steve

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 3 Nov 2010 10:50:26 -0700

At 1:08 PM -0400 11/3/10, Stephen Kent wrote:
>>>the IETF chair) well over a year ago. The agreement called for the SCEP I-D to
>>>standards (CMC & CMP), and would recommend that new implementations of clients
>A big company (e.g., Cisco, Juniper, MS, Google, ...) may promote and publish any protocols that it develops.  Such companies, because of their market presence, often can persuade others to adopt their protocols, whether good or bad, IETF-endorsed or not. In general, the IETF does not rubber-stamp a company-developed, de facto standard just because it is popular. We (at least some of us) also do not like to publish, even as informational, a document that describes a protocol that was developed outside the IETF in direct competition to standards that were developed within the IETF. The rationale is that it encourages vendors to circumvent the process, and acquire the imprimatur of the IETf for their protocols when published as RFCs (since the "Informational" label is often ignored).
>
>Since Max is a new editor for the SCEP document, I am not suggesting that he is responsible for the current situation. Nonetheless, I belive that the agreement reached a couple of years ago should prevail.
>
>If PKIX elects to pursue a lighter-weight cert request protocol, or a variant of one of our extant standards, we can do so. We would start with the development of a requirements document, then allow folks to propose solutions relative to those requirements. Then pick a winner (if we have multiple solution candidates).  That what we did for SCVP (which, after all, is just one letter away from SCEP :-)).

The shorter version of Steve's answer to Peter's question would be "yes".

---

From: "Scott G. Kelly" <[email-masked]>
Date: Wed, 3 Nov 2010 13:16:39 -0700 (PDT)

On Wednesday, November 3, 2010 10:08am, "Stephen Kent" <[email-masked]> said:

<trimmed...> 
> (which, after all, is just one letter away from SCEP :-)).

As an author of a soon-to-be-published enrollment protocol in another industry group, I think what Steve says makes a lot of sense.

Before fleshing out requirements, we started out looking at SCEP, mainly because it is simple and there is open source code available, and it has seen some deployment. One of the potential consumers of our enrollment protocol expressed a strong preference for IETF-standard solutions, so we looked at CMS and CMP. Ultimately, we chose CMS for a number of reasons I won't go into here.

In parallel with this selection process, we tried to articulate some use cases so that we would better understand the protocol and implementation requirements. As it turns out, we would not have been able to make SCEP work without significant enhancement. That is, by fleshing out requirements, we determined that we needed features not supported by SCEP.

Anders has spent a lot of time thinking about mobile enrollment, and I have the impression that others here have significant experience with real-world enrollment scenarios. Articulating a few target use cases and looking at the associated requirements might be a productive step toward understanding what to do next.

--Scott

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 03 Nov 2010 22:06:36 +0100

Scott G. Kelly wrote:
<snip>

Hi Scott!
So you are here as well :-)

> As an author of a soon-to-be-published enrollment protocol in another 
 > industry group, I think what Steve says makes a lot of sense.
> 
> Before fleshing out requirements, we started out looking at SCEP, 
 > mainly because it is simple and there is open source code available,
 > and it has seen some deployment. One of the potential consumers of our
 > enrollment protocol expressed a strong preference for IETF-standard solutions,
 > so we looked at CMS and CMP. Ultimately, we chose CMS for a number of reasons
 > I won't go into here.
> 
> In parallel with this selection process, we tried to articulate some use cases
 > so that we would better understand the protocol and implementation requirements.
 > As it turns out, we would not have been able to make SCEP work without significant
 > enhancement. That is, by fleshing out requirements, we determined that we needed
 > features not supported by SCEP.

Since I'm aware of the spec I may add that it has a rather specific target.

> Anders has spent a lot of time thinking about mobile enrollment,

That's true but thinking has been converted to a full-fledged spec. and
a reference implementation covering the core mechanisms.

It has few if any similarities to SCEP and CMP, it is more like an open
version of what advanced smart card enrollment and management systems do.
The ultimate application for this are mobile payments using virtual credit
cards but it (of course) supports traditional PKI-apps as well.

 > and I have the impression that others here have significant experience with
 > real-world enrollment scenarios. Articulating a few target use cases and looking at
 > the associated requirements might be a productive step toward understanding what to do next.

I think finishing SCEP (and giving it a proper home) is a good thing since
SCEP is quite popular.

Taking a step beyond minor adjustments of existing standards is IMO infeasible.

That your spec. (as well as mine...) were developed elsewhere is not purely accidental :-)

Anders