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

[Peter Gutmann <[e-mail]>]

Paul Hoffman <[e-mail]> 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.