Hacker News new | past | comments | ask | show | jobs | submit login

In practice most non-Internet PKIs don't actually want to do proof of control which is ACME's secret sauce. As you'll see much of the document is about the proof of control, because that's both the hardest problem and the only reason for ACME to exist at all.

In private PKIs either proof of control over the name is considered an out-of-band problem or it's elided altogether. I wrote about this when Peter Gutmann was being angry about ACME years ago, Gutmann saw ACME as redundant because of existing protocols like SCEP. If you want certificate issuance automation but you don't need proof of control over the names then you don't need ACME - SCEP (or half a dozen others) are fine for this purpose and you should use those.

Now, of course if you don't want proof of control but you do want automation it's worth taking a moment to reconsider exactly what your goals really are: What is a certificate doing for me here? What exactly am I certifying, if anything? But if the technical requirement is there, regardless of whether it makes philosophical sense, SCEP delivers and ACME is overkill.

As I wrote in my thread with Peter, it's usual with things like SCEP to provide a default implementation in which the part where you only give certificates to the Right People is left marked /* TODO */. Thus often the result is pure security theatre, certificates are issued equally to bad guys or good guys without distinction and nothing at all is really being certified.

Manual processes may or may not be better in terms of actually certifying anything.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: