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

From: Paul Hoffman <[email-masked]>
Date: Thu, 28 Oct 2010 18:46:17 -0700

At 2:31 PM +1300 10/29/10, Peter Gutmann wrote:
>Paul Hoffman <[email-masked]> 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).

---

From: max pritikin <[email-masked]>
Date: Fri, 29 Oct 2010 12:59:35 -0500

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:

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

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 29 Oct 2010 22:40:02 +0200

As schemes for certificate enrollment for mobile phones SCEP, CMP, and CMC
all appear horribly deficient.  Although Microsoft's CertEnroll is anything
but good, the *principles* behind its operation are much closer to what large-
scale PKI deployments need.  For small-scale PKIs existing PKCS #12 import
is probably sufficient.  So what's wrong with SCEP, CMP, and CMC?

- They are client-centric. A mobile phone solution should be server-centric
   where it is the issuer that requests a key generation including parameters.

- They often include authentication.  A mobile phone solution should delegate
   authentication to the enrolling browser to maintain full flexibility.

- They do not support E2ES (End To End Security).  That's a MUST these days.

+ a gazillion of other things.

This shouldn't be interpreted as opposition to SCEP standardization, only
as a comment regarding its usability for phones.  Apples SCEP implementation
in iPhone apparently requires a configuration file to be used which renders
it pretty lame compared to a browser-based scheme which only needs a URL!

Anders

max pritikin wrote:
> 
> 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.
> 
> 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 
> 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.
> 
> 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 
> "simple PKI Request" and "simple PKI Response" messages are supported. A 
> functional certificate management protocol is thus described that is 
> "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.
> 
> - 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 "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].
> 
> 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.
>

---

From: max pritikin <[email-masked]>
Date: Fri, 29 Oct 2010 17:50:31 -0500

> it pretty lame compared to a browser-based scheme which only needs a  

This supports my point about expanding on the CMC Transport protocols  
discussion (RFC4273 Section 4).

Although I'd prefer to discuss in terms of CMC you've brought up Apple  
iphone SCEP implementation so lets use that example. This is how the  
iphones work:

1) An HTTPS connection is established from the web browser so that it  
is "server-centric where it is the issuer that requests a key  
generation including parameters". The user is authenticated and the  
server responds with an Apple define "mobileconfig" requesting device  
information stuff.

2) A non-web browser initiated HTTPS connection is established. After  
additional device authentication is posted an additional config  
requesting specific enrollment protocol operations is sent to the  
device.

3) A very simple SCEP enrollment occurs; consisting of the CMC Simple  
PKI messages protected with SCEP's PKCS7 rather than using HTTPS.

The user perspective here is that only an URL is needed. The results  
in a file of specific MIME type being handled which ultimately results  
in the device performing enrollment. Much of this is a wrapper around  
the actual "enrollment protocol"; and obviously HTTPS is used  
extensively. I think many enrollment mechanisms are going to look  
similar going forward. There are obvious optimizations we can make to  
streamline the process.

Thus my suggestion concerning how to move forward: Expand on RFC4273  
Section 4 with a profile of CMC over HTTPS. I suggest a new draft so  
long as it is very clear we're profiling the existing protocols to  
make this type of use case simpler. (I do _not_ want to just add a new  
protocol to the mix!)

But that is just my suggestion. I'm looking forward to hearing  
feedback from you all,

- max

> Anders
>
>
>
> max pritikin wrote:
>> 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.
>> 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.
>> 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.
>> 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.
>> 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
>> 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
>> 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.
>> "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:
>> 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".
>> 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).

---

From: Anders Rundgren <[email-masked]>
Date: Sat, 30 Oct 2010 06:46:55 +0200

max pritikin wrote:
> 1) An HTTPS connection is established from the web browser so that it is 
> "server-centric where it is the issuer that requests a key generation 
> including parameters". The user is authenticated and the server responds 
> with an Apple define "mobileconfig" requesting device information stuff.
> 
> requesting specific enrollment protocol operations is sent to the device.
> 
> The user perspective here is that only an URL is needed. The results in 
> a file of specific MIME type being handled which ultimately results in 
> the device performing enrollment. Much of this is a wrapper around the 
> actual "enrollment protocol"; and obviously HTTPS is used extensively. I 
> think many enrollment mechanisms are going to look similar going 
> forward. There are obvious optimizations we can make to streamline the 
> process.
> 
> long as it is very clear we're profiling the existing protocols to make 
> this type of use case simpler. (I do _not_ want to just add a new 
> protocol to the mix!)
> 
> But that is just my suggestion. I'm looking forward to hearing feedback 
> from you all,

Thank you for describing the Apple solution, I obviously didn't have all details.

However, a problem with this scheme from a standardization perspective is
that it is actually "mobileconfig" that needs a standard definition if
interoperability is to be achieved.

Another issue is that E2ES like featured in GlobalPlatform is a requirement
for getting acceptance as a foundation for mobile payments, and that doesn't
work (at all) with any of the mentioned standards and formats since MACing
and encryption requires 1-2-1 correspondence with the "key container".

As an implementer of mobile phone enrollment protocols I can testify that the
PKI part is completely trivial thing compared to the rest:
In a *server-centric browser-setup* the only thing needed PKI-wise is a raw
(in some way) "authenticated" public key.  Extensions, DNs, etc. only exist
in the server-end during enrollment.

Anyway, getting vendor buy-in on this topic is extremely unrealistic at
this stage, the division has probably never been bigger.

Anders

>>> 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.
>>> 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.
>>> libraries. A profile approach provides an easy to implement 
>>> enrollment for minimal products that can be easily expanded to a full 
>>> 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
>>> 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.
>>> 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 
>>> 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].

---

From: "Sill, Alan" <[email-masked]>
Date: Sat, 30 Oct 2010 02:01:35 -0500

> this stage, the division has probably never been bigger.

I agree that vendor buy-in in this setting may be unrealistic (although always desirable), but would like to point out that in addition to the use cases discussed before in this thread, there are other reasons to make progress on this topic. The use case of application and process self-enrollment both for server and client processes in cloud settings provides one such motivation that is free of this set of cell phone provider based self-restrictions. 

We are interested in such use cases. Can people provide any examples from their current work?

Alan

---

From: Anders Rundgren <[email-masked]>
Date: Sat, 30 Oct 2010 09:33:17 +0200

Sill, Alan wrote:
> I agree that vendor buy-in in this setting may be unrealistic (although always desirable), 
 > but would like to point out that in addition to the use cases discussed before in this thread,
 > there are other reasons to make progress on this topic. The use case of application and process
 > self-enrollment both for server and client processes in cloud settings provides one such
 >  motivation that is free of this set of cell phone provider based self-restrictions.

There are plenty of (entirely) uncoordinated efforts in this space but the majority
are secret since this is the tradition within the mobile phone industry.

As an example I can mention the work performed by TrustedComputingGroup which I'm
an invited expert member of.  They don't publish specs until they are ready.
Personally I think this is wrong but Microsoft, Nokia, IBM, Dell, and other big guns
claim that this is "necessary".

I'm aware of several other efforts but have no right mentioning them here.

> We are interested in such use cases. Can people provide any examples from their current work?

However, since I *do not* represent a mobile phone vendor I can without problems
provide information regarding one such effort which address quite a bunch of issues
that has never ever even been mentioned in PKIX like:
- E2ES
- Remote key life cycle management in shared key containers
- Symmetric key provisioning
- PIN/PUK provisioning,
- Algorithm constraining
- Information Card support
- GUI considerations
- Transaction-based provisioning
- Device attestations

http://webpki.org/auth-token-4-the-cloud.html

Anders

---

From: "Sill, Alan" <[email-masked]>
Date: Sat, 30 Oct 2010 03:06:38 -0500

On Saturday, October 30, 2010 2:33 AM, "Anders Rundgren" [email-masked] wrote|:

Sill, Alan wrote:
> > We are interested in [cloud] use cases. Can people provide any examples from their current work?
>
> [...] since I *do not* represent a mobile phone vendor I can without problems

Thanks very much for this; this is very useful.  We have just gotten doen with a review of several other related use cases and technologies in the context of OGF (http://www.ogf.org/OGF31/) and a related workshop (http://indico.rnp.br/conferenceDisplay.py?confId=85) so |I can respond in kind with these links.  The work related to the original topic of this thread on SCEP, CMC and CMP is, I believe, relevant in this context and potentially useful in this setting.

The nice thing about OGF is that they pursue open standards! ;-)

Alan

---

From: Anders Rundgren <[email-masked]>
Date: Sat, 30 Oct 2010 11:38:40 +0200

Sill, Alan wrote:
> Thanks very much for this; this is very useful. 

Thanx!

  We have just gotten doen with a review of several other related use cases and
 > technologies in the context of OGF (http://www.ogf.org/OGF31/) and a related
 > workshop (http://indico.rnp.br/conferenceDisplay.py?confId=85) so |I can respond
 > in kind with these links.  The work related to the original topic of this thread
 > on SCEP, CMC and CMP is, I believe, relevant in this context and potentially useful
 > in this setting.
> 

I appreciate that but if you take a deep peak into the stuff I provided links
to I believe such a scheme is *way* beyond what an SDO (Standards Defining
Organization) could possibly succeed since it covers the entire ecosystem,
from bits and bytes in crypto HW to high-level XML protocols, user enrollment
processes and GUI.  An SDO could only take on one piece a time leading to
eternal projects with no useful outcome.

The payment use-case (which IMO is the most interesting one), is only dealt
with in very restricted any "pricy" SDOs that seldom returns anything since
banks do not build mobile phones.

In addition, the market doesn't really care about standards, it wants working
code and preferable shipped as Open Source.  My project takes this notion
one step further by also building on Open Hardware.  This is in stark contrast
to the smart card industry which only occasionally distribute datasheets
without requiring NDAs!

"The times are a-changing..." B. Dylan

Anders

---

From: max pritikin <[email-masked]>
Date: Sat, 30 Oct 2010 10:59:01 -0500

I think there is continued interest in making progress. And this  
thread highlights that our current PKIX offerings could be clarified.

On Oct 30, 2010, at 2:01 AM, Sill, Alan wrote:

>
> On Oct 30, 2010, at 6:47 AM, "Anders Rundgren" <[email-masked] 
> > wrote:
>
>> (in some way) "authenticated" public key.

In this context 'trivial' is great. That should mean it is relatively  
straightforward to provide a useful and definitive document for how  
this occurs.

This allows the following framing:

SCEP - An existing secure transport for the simple CMC simple pki  
messages [1] that follows the RFC5273 Section 4 HTTP POST/GET  
mechanisms but fully specifies the relative URLs. It includes a number  
of SCEP specific extensions that overlap CMC proper functionalities.

CMC enrollment over Secure Transport (CEST) - A proposed 'trivial' to  
implement profile of CMC (simple PKI messages) using HTTPS as the  
transport and following the RFC5273 Section 4 HTTPS POST/GET  
mechanisms. It will be necessary to specify the relative URLs, and the  
HTTPS authentication methods. The focus is on an extremely simple to  
implement using existing libraries profile of CMC borrowing from our  
experience with SCEP and CMC implementations. To obtain CMC proper  
functionalities use full CMC messages.

CMC - The full CMC protocol. Appropriate for clients that need the  
full CMC functionality.
CMP - The full CMP protocol. Appropriate for clients that need the  
full CMP functionality.

>>  Extensions, DNs, etc. only exist
> I agree that vendor buy-in in this setting may be unrealistic  
> (although always desirable), but would like to point out that in  
> addition to the use cases discussed before in this thread, there are  
> other reasons to make progress on this topic. The use case of  
> application and process self-enrollment both for server and client  
> processes in cloud settings provides one such motivation that is  
> free of this set of cell phone provider based self-restrictions.

SCEP and full CMC messages include complexity to support insecure  
transports. I think there will be significant interest in a profile  
specific to a widely used and easily leveraged secure transport.

- max

[1] As noted in my previous text this is a perspective being argued  
for the purposes of this discussion. I agree this is a shift in the  
framing of SCEP.

---

From: Anders Rundgren <[email-masked]>
Date: Sat, 30 Oct 2010 22:47:19 +0200

max pritikin wrote:
> 
> I think there is continued interest in making progress. And this thread 
> highlights that our current PKIX offerings could be clarified.

I still feel a little bit weary about mobile phone enrollment schemes
that do not support E2ES since this is already a part of many SIM-related
enrollment schemes. E2ES is not to be confused with TLS because here
we are talking about container-to-issuer communication and AFAIK few
if any cryptographic containers use TLS as E2ES method.  GlobalPlatform
use ETSI-specs like SCP10.  I don't think any E2ES scheme is compatible
with PKIX enrollment schemes or with cryptographic APIs like PKCS #11.

But it all boils down to what you want to accomplish.  My goal with SKS
is (among many things), establishing the foundation for using mobile phones
as virtual credit cards as well as long-term eliminating SIM-cards.

A prerequisite is that crypto devices are equipped with device certificates
that are used for creating sessions.

Anders

> straightforward to provide a useful and definitive document for how this 
> occurs.
> 
> messages [1] that follows the RFC5273 Section 4 HTTP POST/GET mechanisms 
> but fully specifies the relative URLs. It includes a number of SCEP 
> specific extensions that overlap CMC proper functionalities.
> 
> transport and following the RFC5273 Section 4 HTTPS POST/GET mechanisms. 
> It will be necessary to specify the relative URLs, and the HTTPS 
> authentication methods. The focus is on an extremely simple to implement 
> using existing libraries profile of CMC borrowing from our experience 
> with SCEP and CMC implementations. To obtain CMC proper functionalities 
> use full CMC messages.
> 
> CMC - The full CMC protocol. Appropriate for clients that need the full 
> CMC functionality.
> CMP - The full CMP protocol. Appropriate for clients that need the full 
> CMP functionality.
> 
>> processes in cloud settings provides one such motivation that is free 
>> of this set of cell phone provider based self-restrictions.
> 
> [1] As noted in my previous text this is a perspective being argued for 
> the purposes of this discussion. I agree this is a shift in the framing 
> of SCEP.
>

---

From: Stefan Santesson <[email-masked]>
Date: Sun, 31 Oct 2010 12:11:07 +0200

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: Yoav Nir <[email-masked]>
Date: Sun, 31 Oct 2010 13:38:50 +0200

According to https://datatracker.ietf.org/doc/draft-nourse-scep/

SCEP has been in various stages of "publication requested" since September 2007, and no substantial changes since December 2009.

I have no clue about what is going on behind the scenes, but it seems like the authors and/or the AD are in no great hurry to get this published.

Recent versions added some newfangled features like algorithm agility, SHA-2 and the like. Pretty neat for a document that started life in January 2000.

This coming January the document will celebrate its 11th birthday. Not a record (http://www.arkko.com/tools/lifecycle/extremes.html ), but still not a good example of the system working.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stefan Santesson
Sent: 31 October 2010 12:11
To: Anders Rundgren; max pritikin
Cc: [email-masked]
Subject: Re: [pkix] SCEP vs CMC vs CMP

--------------------

/Stefan

Scanned by Check Point Total Security Gateway.

---

From: Anders Rundgren <[email-masked]>
Date: Sun, 31 Oct 2010 12:58:44 +0100

> Reflecting on the whole thread.

Thanx Stefan,

 > deployed protocol that has no stable RFC reference.

Advancing SCEP to RFC is a short-term and good goal but I'm afraid this
will have almost nothing to do with future mobile enrollment schemes in
spite of Apple's use of it.

E2ES is the [discriminating] factor making current PKIX schemes
unsuited for this task.

 > do with certificate enrollment that will follow one generic model.

For mobile phones I believe that this is wrong.  The anticipated division will
be due to political issues and not due to technical or process requirements.
Just getting a wish-list is essentially impossible.  Which *vendor* would
even *think* about doing that???

/anders

---

From: Stefan Santesson <[email-masked]>
Date: Sun, 31 Oct 2010 13:53:41 +0200

> E2ES is the [discriminating] factor making current PKIX schemes

I read that you agree that SCEP should be published.

I have currently no opinion on its usability for the mobile sector.

> For mobile phones I believe that this is wrong.

If it is for the mobile sector, it is not generic..... So I take this as
agreeing with me :)

I would not be surprised if you are right about mobile phones as long as we
can define the targeted use cases. If we talk about mobile phones as simply
being a mobile computer where it's apps may need PKI, then I think we may
see all flavors.

>  The anticipated division will

You put your finger on an important point. It is not only what is
technically reasonable that defines what we can do.

/Stefan

---

From: Anders Rundgren <[email-masked]>
Date: Sun, 31 Oct 2010 18:31:17 +0100

Stefan Santesson wrote:
<snip>
> being a mobile computer where it's apps may need PKI, then I think we may

I would be interesting getting more information on why there could be a
*technical* need for many flavors. Although I could be wrong, I consider
my already published specification indeed addressing the entire mobile
phone market w.r.t. enrollment of PKI, OTP, Information Cards, U-Prov, etc.

It also has this E2ES component that is a de-facto standard in SIM provisioning
which no PKIX RFC or I-D supports.

I personally doubt that PKIX has the skills, the courage, and patience needed
for taking on mobile phone PKI enrollment for consumers.  Creating yet another
enterprise solution (MSFT already have one) is another thing but I think this is
even more vendor-specific like the Exchange-stuff that most phones support today.

Anders