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

From: Peter Gutmann <[email-masked]>
Date: Tue, 14 Oct 2014 11:30:14 +0000

Erik Andersen <[email-masked]> writes:

>The smart grid security folks want to use SCEP as normative reference in
>their specification. 

It's already being used in a variety of SCADA applications (and is required in
some SCADA standards), so they're in good company there.

>In the current state of SCEP, this is probably against the rules of IEC. It
>might be desirable to progress SCEP to a more official status. That could be
>within PKIX as an RFC or as an ITU-T Recommendation to be progressed very
>quickly. The latter might require some consent from Cisco.

That's going to be tricky, Cisco really wants people to forget about SCEP and
move onto EST (thanks to Michael Jenkins for pointing out the name, I was too
lazy to Google it :-).  I've submitted a bunch of corrections to SCEP (there
are some things that were bolted on later that really don't work as specified,
or under-specified, in the spec) but haven't been able to get any traction on
it.  At the moment I don't know what it'd take to get SCEP published as any
sort of standard.  OTOH as you point out it is a very widely-used de facto
standard, while the actual "standards" (CMP, CMC, etc) barely exist and don't
interoperate when they do).

It's a bit of a COBOL vs. OCaml thing, one is old and clunky and just gets the
job done (SCEP), the other is complex and full of esoteric features and only
understood by about seven people, three of whom mutter to themselves a lot and
aren't allowed near sharp objects because of what they might do with them
(CMP/CMC/etc).

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 16 Oct 2014 11:07:13 +0000

Paul Hoffman <[email-masked]> writes:

>> Thanks for your quick answer.
>
>Which, unfortunately, was wrong. SCEP's lack of standardization was not
>because PKIX had their own protocols: 

So PKIX would have adopted it as a WG item had Cisco asked?

>Which SCEP? The on-the-wire protocol changed from draft to draft, and I
>believe that the final draft does not match Cisco's implementation. If you
>point at one draft, you will have terrible interoperability, and what
>interoperability you get will be to a flawed protocol. See below.

I've been tracking SCEP for about a decade, including being involved in
deploying stuff based on standards that refer to decade-old versions, and
never had any interop problems due to anything other than buggy
implementations (and I'm specifically talking Microsoft's NDES here).  That
has nothing to do with the spec, it's just a really bad implementation (think
1990s Microsoft, implementing about 2/3 of a protocol spec and then getting a
third of that wrong).  However NDES is so widely deployed and used that pretty
much everyone has worked around the problems in it, so it's not really an
issue.

I'm looking at this from a non-Cisco point of view.  Cisco's implementation
may have terrible interoperability (I have no idea, I've never used it), but
for general SCEP use it's been pretty good, and certainly far, far better than
any of the more complex cert-enrolment protocols I've played with.  And that's
SCEP's advantage, it may be very limited but there's not much you can get
wrong with PKCS #10-inside-PKCS #7.

>Cisco consistently published drafts of SCEP without "submitting it to the
>IETF" because Cisco and Cisco's competitors didn't want to deal with having
>to change their codebases. 

The problem is that SCEP is no longer Cisco's baby, and hasn't been for a long
time.  There are more than half a billion (non-Cisco) devices actively using
SCEP today (that's a lower bound since there's a lot of hidden SCADA gear that
can't be measured), and in the tens of millions of SCEP servers (or at least
SCEP-capable, they're not all being used to run SCEP).  Cisco may not care
about SCEP any more, but an awful lot of other users do.

>It did not offer a lot of stuff that a good cert enrollment protocol should
>offer; that wasn't the point.

Sure.  If you just wanted to provision a device with an RSA cert, it was fine.
Anything else...

>If the "smart grid security folks" want to reference a well-written
>certificate enrollment protocol, they should stay the heck away from SCEP and
>point to EST.

... provided they don't mind doing their own implementation of EST from
scratch, and persuading everyone they ever want to talk to to do the same.

Oh, and good luck finding a widely-used server implementation to
run/administer the whole thing through.

SCEP sucks for anything other than device-cert-provisioning, but it works (and
cert-provisioning is all that most users seem to want in any case, although
I'm not sure if that's a case of the Sapir-Whorf hypothesis for crypto in
effect :-).  I can take my code, or JSCEP, or whatever, point it at a Windows
server, and issue certs with it, all administered through Active Directory or
whatever management tools you want.  A Smith and Wesson beats four aces.

Peter.