On Sunday, 10 July 2016 14:29:34 UTC+1, Peter Gutmann wrote: > 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.
You've described the optimism, I was talking about the reality. I already provided the CERT reference for where the chasm between them opens up. Apple provide a nice diagram for would-be deployers in which the actual verification step is labelled "optional", and they provide source code for a reference implementation of their profile service needed to issue iPhones with a certificate, which is more or less a complete working system... and does no verification whatsoever. Funny thing about "reference implementations", they tend to become the actual implementation by a process of copy-paste. > 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. You'd have been talking to PayPal, specifically their "Partner Support" department, which will be a group managing affinity relationships within PayPal. > 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). A genuine EV certificate for a genuine (but crappy) PayPal marketing site. 2.5.4.5 aka id-at-serialNumber is an X500 OID used in the subject DN. As such it identifies the subject of the certificate, not the certificate itself. In particular for the web PKI id-at-serialNumber will be the identifier for this company in a register or index, such as in this case PayPal's company number 3014267 in the Delaware Division of Corporations. The certificates themselves do, as expected and required, each have their own completely different serial numbers, and they're both genuine. The fact that human agents behave inconsistently (in transcribing or not the punctuation at the end of PayPal Inc.) is permitted by the current BRs since this information is intended to be human readable. > Is it genuine or a phish? Paypal security says it's a phish, the EV cert says > it isn't. So far as I can see a Customer Services agent pushed the button to generate an form reply "thanks for telling us about phishing" email out to a concerned customer. Maybe they should not have done that. Calling this person "Paypal security" without the pay jump that would imply seems a bit unfair, they're probably expected to process dozens or even hundreds of such emails per hour. PayPal had been operating this site since at least 2013, but they eventually shut it down some time after that post, perhaps because it gave a negative impression, as you've demonstrated. > So SCEP provides pretty strong assurance of who you're talking to SCEP itself provides no assurance whatever, as you were originally proud to point out that "no-one cared". It is possible to achieve some assurance out of band but I still haven't seen examples of this in the wild. > 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). ACME itself today provides reasonable assurance only as to the (DNS) name of the entity you're talking to. Semi-automation of EV has come a long way, but I doubt that fully automated issuance of EV certificates is on the horizon. It is anticipated that an outfit like Symantec (Versign), if they used ACME for EV, would add one or more ACME challenges that could only be completed manually and require those for their EV certificates. > 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. Previously you said nobody cared, now you claim they have an unspecified "high-assurance mechanism". The reality is closer to the former, unfortunately. > So adding a minor extension to a proven, established protocol is naivety but > inventing a totally new, unproven one from scratch isn't? Insistence that it would constitute a "minor extension" is all yours and I think reflects further on your naivety. The challenge mechanisms make up a considerable fraction of the entire ACME standard on paper, and practical experience shows that this is the hardest part to get right. > Look, I can see that this is obviously an issue of religious dogma for you > that ACME is perfect and everything else isn't ACME is much too complicated to ever be perfect, but while you were bothering people in this unrelated thread, development of ACME continued, draft-ietf-acme-acme-03 was published and discussion of the open items continued in the appropriate IETF working group. > 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. Thank you, in the event you have anything actually useful to contribute to ACME, please do it on the ACME Working Group mailing list or bring it to IETF 96, if you have contributions (other than general disdain) to the state of the Web PKI as it pertains to Mozilla you should put them in a new thread here in mozilla.dev.security.policy with an appropriate subject line. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
