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

[Anders Rundgren <[e-mail]>]

On 2014-11-11 02:50, Dr. Massimiliano Pala wrote:

If we stick to personal computing devices they are de-facto defined by only
3 giant US vendors.  They are not interested in even discussing what they
see as potentially valuable, particularly not in a public mailing list.

Anyway, none of the PKIX protocols support provisioning of two-factor
credentials (Key + PIN).  This may sound like a minor problem to fix
but such a scheme requires the protocol having the key-container as
the true end-point rather than the client/P11.  The same is valid for
key attestation.

For IoT, like smart meters there are since years back specific solutions
based on non-X.509 certificates.

When the work with EST started it was taken for granted that ASN.1,
PKCS #10 etc. would be a requirement.  However, it seems that JSON
have taken ASN.1's role for new developments also in IETF, here thinking
of the JOSE suite.

Anders

> 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
>