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

["Miller, Timothy J." <[e-mail]>]

>None of those are really cert-enrolment protocols though...

Well, PCAS is explicitly an enrollment protocol--you send a public key, you get back a certificate--as are Microsoft's ICEnroll and the WS-Trust based enrollment protocol (Certificate Enrollment Web Services) in Server 2k8r2.  

While it's true that KMIP explicitly disclaims enrollment, it nevertheless has the features you need for enrollment and can be (mis?)used that way.  Similarly so with XKMS.  Besides, it's funnier when you include them.  :)

>I've read that before and found it a bit silly, it basically says "issuing a
>certificate containing a verbatim copy of what the client asks for ('give me a
>certificate that makes me a CA, and issued for google.com') can result in
>unexpected rights amplification".  Well, duh.

IMHO the key point from CSS's discussion is that the SCEP authenticator doesn't actually bind to the identity to be requested or to the requestor, so you can enroll a different device than the one the RA thinks you're enrolling, or you can pass the authenticator along to an otherwise unauthorized person (or both).  This isn't a concern in a closed environment as long as you have either physical control of the devices enrolled, trusted and accountable "sponsors" acting on behalf of the non-person Subscriber, or (ideally) both.  Unfortunately in the general non-person Subscriber use case there's a scalability requirement that incentivizes over-automation and reduces accountability and control--and that opens up a hole in SCEP you can drive a truck through.   (Cue Anders again.  :)

Naturally human Subscribers can attempt the same shenanigans but there are at least the pretense of checks in those systems.  

-- T