Nick Lamb <[email protected]> writes: >Early drafts of SCEP, before it confined itself to "closed networks" even >spell out what the problem is before they basically say they're not going to >make any real attempt to tackle it. CMP, CMC and SCEP all resort to saying >that some "out of band" mechanism should be used to verify that the applicant >is or controls the subject DN and treat this problem as completely out of >scope.
Various SCEP drafts have contained all sorts of stuff that was dropped when no-one cared about it. The "out of band"/"beyond the scope of this document" is standard boilerplate that's used when no-one cares enough to include it in the document. In fact it pretty much explicitly says that it's not covered in the doc because no-one cared how it was done. So I'll repeat this again: It wasn't added to any existing protocol because no-one's ever cared about it before. If people do care about it, why not add it to any one of the many existing protocols rather than inventing yet another incompatible way of doing what numerous other protocols already do? Or is it that ACME is just a desperate attempt to derail StartCom's StartEncrypt at any cost? >"Schneier's Law" very much applies. What does that have to do with no-one bothering to add whatever magic ingredient ACME is claiming to have to any other protocol that does the same thing? Or are you claiming that ACME is flawed because it's a reinvention of the wheel by amateurs (which is what Schneier's Law would be saying)? That seems a bit unlikely... >Each week several hundred thousand certificates are issued using (an earlier >draft of) ACME by what is now as a result one of the Web PKI's top five >Certificate Authorities in terms of how many sites use its certificates. OK, I think I can parse that convoluted sentence... in response: Each week who knows how many certificates are issued using HTTP POST, Xenroll.dll, SCEP, CMP, and who knows what else. What's your point? Peter. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
