Nick Lamb <[email protected]> writes: >SCEP (and all the real SCEP implementations that I could find) take the >optimistic view that this is somebody else's problem, and so the practical >result is security theatre.
Uhh, do you even know how SCEP is used? When you're provisioning a VPN gateway, SCADA device, an iPhone, or one of the other systems that SCEP is used with, the cert issue is auth'd with a PSK unique to that system, so you know that if you see a cert with DNP3 ID ABC or AppleID XYZ, you really are talking to the exact device/service you think you're talking to. In contrast with the web PKI (and presumably ACME), you think you're talking to Paypal but you could just as easily be talking to a Paypal phishing site. Here's one example, a phishing email identified by Paypal security as being a phish, redirecting people to an equally phishy site www.paypal-special.com, which however had an EV cert with a serial number that duplicated that of a genuine Paypal cert: http://security.stackexchange.com/questions/49200/apparently-paypal-affiliated-site-with-very-suspect-security/58470). Is it genuine or a phish? Paypal security says it's a phish, the EV cert says it isn't. So SCEP provides pretty strong assurance of who you're talking to, ACME (if it follows the web PKI) provides the illusion of assurance (you think you're talking to Paypal but it's actually a phisher). The fact that SCEP, in its original design, doesn't do DV or whatever isn't a shortcoming of the spec, it's because there's no need for such a low-assurance mechanism when you've already got a high-assurance mechanism available. Having said that, if you do think DV or whatever provides some guarantee of security, there's nothing preventing you from adding it to SCEP, CMP, CMC, EST, or whatever. >Certificates are issued, public key mathematics is done, there is superficial >appearance of a secure system but no useful assurance of identity is achieved >and so no real threat is neutralised. That's actually a pretty good description of the web PKI. And, presumably, ACME if that's what it's meant to automate. >This idea that you should just be able to "add whatever magic ingredient" is >the exact sort of naivety that Bruce is talking about. So adding a minor extension to a proven, established protocol is naivety but inventing a totally new, unproven one from scratch isn't? Look, I can see that this is obviously an issue of religious dogma for you that ACME is perfect and everything else isn't, in light of which it doesn't seem productive to continue this discussion, it'll just annoy everyone else who's having to listen. Also, while it was fun initially, I'm now getting bored. I'll bow out now. Peter. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
