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

The only thing that could eventually replace SCEP for "devices" including
BYOD, would be a protocol that builds on embedded attestation keys like the
FIDO/Google U2F scheme.  Such a scheme could completely eliminate the
reliance on enrollment passwords.

For browsers-based enrollment none of the PKIX-protocols make any sense since
the former effectively is server-driven.  I.e. it is the server that asks the
client (platform) to generate a key-pair according to the server's specification.

Related: http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/

-Anders

On 2014-10-29 14:35, Peter Gutmann 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".
>
> 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.
>
> Peter.
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix
>