Re: [pkix] Simple Certificate Enrollment Protocol (SCEP)

["Max Pritikin (pritikin)" <[e-mail]>]

Hi Max Pala, 

Some of the core ideas in the original SCEP draft were included into CMC (notice there is even a Cisco author shared between those two efforts). 

Unfortunately CMC lost some of the simplicity and directness of SCEP (e.g. CMC has a complex number of options). The approach didn’t really get traction and SCEP become something of a defacto standard despite its limitations. 

Those limitations are significant and as algorithm agility and other protocols have progressed SCEP is looking even more crufty/problematic then ever before. 

EST RFC7030 addresses these limitations by profiling CMC back into the simplicity original envisioned while maintaining the necessary functionality and providing a clear path for future extensibility and access to the full CMC feature set. Please take a look at it before suggesting additional work:
	http://tools.ietf.org/html/rfc7030

SCEP itself could be turned into a historic RFC purely to clarify that it is *historic* and not a work in progress. I don’t see a compelling reason to repeat this process again. 

- max

On Nov 10, 2014, at 3:50 PM, Dr. Massimiliano Pala <[e-mail]> wrote:

> Hi all,
> 
> I read the thread for a while. I actually do remember that there was a presentation for SCEP and a request for that to be adopted as a working item in this group that was refused based on the fact that we already have IETF protocols for that.
> 
> If this argument till stands, than any work on this item (or its successor) should be informational and not WG.
> However, I think it would be useful to resume a conversation about the status of enrollment protocols - in particular, if the current PKIX WG sponsored RFC are not used in the real world (maybe too complex or too many options?) maybe we should address the issue and work on an easier-to-deploy solution..??? After all, what is the use of a standard if nobody uses it in the real world? If that is the case, I think we need to be humble and admit the limits of the current standards and design a pattern to move forward.
> 
> It could also be that we like the status quo and leave things as they are today - if the majority of people are happy with what we have today.
> Can we have a poll about "is there a need to review/amend/simplify PKIX work for certificate enrollment" ?
> 
> Max Pritikin: I would be interested to meet and talk, can you please include me in the discussion/meetings about this?
> 
> Last consideration: Although I am not the WG chair, and it is not my role, I would like to keep the discussion in check. I have the impression that the topic is somewhat overloaded with non-technical aspects and I hope we can, instead, focus on technical aspects and on what is needed rather than on how this was handled in the past.
> 
> Cheers,
> Max
> 
> 
>> On Nov 7, 2014, at 1:03 PM, Max Pritikin (pritikin) <[e-mail]> wrote:
>> 
>> 
>>> On Oct 29, 2014, at 6:35 AM, Peter Gutmann <[e-mail]> wrote:
>>> 
>>> I've spent the time since the last exchange of messages on this thread talking
>>> to various SCEP users over their requirements.  It turns out that the figure
>>> I'd previously posted, of half a billion SCEP devices in active use, was
>>> rather an underestimate.  SCEP seems to be pretty much the universal device-
>>> provisioning protocol for non-PC/laptop devices, including mobile phones,
>>> SCADA devices, gaming machines, ATMs, firewalls, and so on.  It's also been
>>> described to me as the standard BYOD provisioning protocol, its use for this
>>> being so widespread that Server 2012 even added new, extra capabilities for
>>> dealing with BYOD use via SCEP (Windows Server 2008 and 2012 are pretty much
>>> the standard server implementations for dealing with this sort of thing).  As
>>> one person told me, "if a device speaks anything, it'll speak SCEP".
>>> 
>>> So, no matter how much Cisco would like to forget about it, it's extremely
>>> widely used, and there's no sign that this is going to change in the future.
>>> To paraphrase something someone said many years ago about IBM, "SCEP isn't the
>>> competition, it's the environment”.
>> 
>> Agreed! We can’t “forget” about it. This is why we paid so much attention to the process flow of SCEP when designing EST to insure minimal pain.
>> We also need to be able to move forward to suite-b and better client authentication methods. Thus the reason we had to describe something beyond SCEP (which can’t support these improvements). This led to the specific CMC profile that is EST.
>> 
>>> 
>>> To that end I'd like to request that the SCEP authors give me (or someone else
>>> who cares about it, e.g. one of the JSCEP folks) change control over the
>>> document so that we can finally get this published.  I submitted a list of
>>> changes for the current doc ages ago but things seem to have stalled since
>>> then (the changes were minor things that have come up in real-world usage,
>>> clarifications to the doc, places where ~15-year-old remnants still exist next
>>> to current ones, and just a general cleanup of the neglect that it's had for
>>> the last decade or so, it still talks about MD5 and single DES for example,
>>> but doesn't mention that newfangled AES thing that everyone's talking about).
>>> 
>>> Given that it's been more or less abandoned by Cisco, I'd like to finish the
>>> editing for it and finally get it published as an RFC so that the vast number
>>> of devices out there using it, and that will use it in the future, have a
>>> fixed standard that they can refer back to.
>> 
>> I’ll be at IETF next week. Lets meet with any interested parties and figure out a path forward.
>> 
>> A question: How is updating "half a billion SCEP devices” to a new version of SCEP any different than updating them to EST or similar?
>> 
>> - max
>> 
>>> 
>>> Peter.
>> 
>> _______________________________________________
>> pkix mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/pkix
> 
> _______________________________________________
> pkix mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pkix