Re: [pkix] SCEP vs CMC vs CMP

[max pritikin <[e-mail]>]

Paul is correct. SCEP does not limit certificates to IPSec VPN uses;  
it is just an enrollment protocol. Although it is true that SCEP is  
widely used for IPsec VPN the client is also available on Apple  
iPhones, and a number of CA platforms provide server functionalities.  
What is indisputable is that SCEP is a draft, and the other options  
are RFC documents.

There have been a number of years of 'water under the bridge', perhaps  
now is the time to move forward? I suggest we focus on simplicity and  
unification rather than features or history.

I'd like to bring closure to the SCEP draft. It could be finalized as- 
is, or we could cast SCEP as just a secure transport for a profiled  
CMC using "Simple PKI Messages" -- which are exactly the same as the  
inner pkiMessages used by SCEP. I've drafted text providing references  
and showing why this is a valid perspective (see below). Thus we unify  
that portion of the discussion around a profile of CMC.

Moving forward I suggest we expand on RFC5273, or a new draft, to  
provide a clearer specification of CMC over HTTPS. Where the goal is a  
simple profile of CMC over a secure transport that could be easily  
implemented by a wide number of existing libraries. I have called this  
"CMC over Secure Transport" (CEST) and would be happy to share a copy  
although I've hesitated to submit it -- I do not want to be seen as  
adding a new protocol to the existing mix! The intention of the CEST  
idea is to leverage our combined operational experiences over the last  
number of years resulting in an easy to implement CMC profile.

I can not speak to the request for a CMP comparison. CMP is more  
complex than the requirements I have dealt with. It is worth noting  
that in previous conversations on this list we have discussed that CMP  
Section 6.2 on Root CA Key Update should probably be pulled out into  
an independent document, or otherwise referenced in future documents.

I hope you see these ideas as constructive attempts to find a way  
forward that could be easily implemented by a wide number of existing  
libraries. A profile approach provides an easy to implement enrollment  
for minimal products that can be easily expanded to a full  
implementation when needed.

- max

The following is a rough proposal casting SCEP as a profile of CMC  
over a secure transport. This does not change SCEP at all -- it is  
informative text providing a perspective shift. (The following text is  
NOT in the current SCEP draft but if this approach is makes sense to  
folks it is easy enough to add). Thanks for any comments:

Appendix X

This appendix details how SCEP can provide a secure transport for a  
limited profile of Certificate Management over CMS [RFC5272]. Only the  
"simple PKI Request" and "simple PKI Response" messages are supported.  
A functional certificate management protocol is thus described that is  
appropriate for PKI clients interested in obtaining client  
certificate(s) and associated infrastructure certificate(s) without  
necessitating a full implementation of all CMC [RFC5272] features.

This is consistent with the CMC [RFC5272] protocol specification of  
"simple" messages for clients to use "in the event no other services  
are needed". When using these messages CMC [RFC5272] section 3.1 notes  
that "the Simple PKI Request MUST NOT be used if a proof-of-identity  
needs to be included"; which precludes their use if inline  
authentication and/or authorization is required unless a secured  
transport is also specified. SCEP as such a secure transport is  
described in this appendix. CMC [RFC5272] provides additional  
functionality not included in this profile. For simple clients that  
require only secure certificate enrollment this profile is sufficient.

The SCEP protocol operations are as described in the main body of this  
[SCEP] document. The following clarification are made:

- RFC5273, Section 4 is followed by SCEP, although for  
interoperability with CMC clients have to use the POST method (SCEP  
indicates this as optional).

- When performing the SCEP "PKCSReq" transaction the outgoing  
messageData contains a PKCS#10 (ref CMC section 3.2.1.2.1). This is as  
currently described in the main body of this [SCEP] document.

- When performing the SCEP "PKCSRep" transaction the response contains  
a CMC Simple Enrollment Response. This is a "CMS "certs-only" message"  
which is also equivalent to the SCEP described "certificates-only  
PKCS#7 Signed-data". [Needs to be confirmed; this should be true if  
RFC3852 CMS Section 5.2.1 is followed].

- The SCEP client "MUST understand the Full PKI Response" for full CMC  
compliance. This would be an addition to existing SCEP clients. CMC  
indicates that "A Full PKI Response is always a valid response, but  
for interoperability with downlevel clients a compliant server SHOULD  
use the Simple Enrollment Response whenever possible".

- SCEP libraries mark other SCEP functionalities as deprecated when  
CMC compliance is claimed.

This meets the requirements indicated in CMC section 8.2 for "Minimum  
Conformance Requirements" of RFC 2797 (Obsolete; this section was  
removed in the current document).

On Oct 28, 2010, at 8:46 PM, Paul Hoffman wrote:

> At 2:31 PM +1300 10/29/10, Peter Gutmann wrote:
>> Paul Hoffman <[e-mail]> writes:
>>
>>> SCEP is not your answer. It is narrowly limited to IPsec VPN  
>>> boxes, and a
>>> small subset of that market.
>>
>> Uhh, no it isn't, it was originally designed for that 15?-odd years  
>> ago but
>> it's used all over the place.  The last time I used SCEP was to  
>> provision
>> iPhones from a Microsoft Windows server, neither of which are IPsec  
>> VPN boxes.
>
> Gaaaah. Thanks for the update. :-(
>
> OK, so you still have three sores, ooozing different-colored (elided).
> _______________________________________________
> pkix mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pkix