Just curious why ACME requires using an opaque random 128-bit value assigned by CA instead of the public key hash? This seems a bit non-obvious. My guess is that it makes it impossible to craft a public key whose hash will match the real key intended by the legitimate domain owner.
The account public key hash IS used for proof of ownership - https://tools.ietf.org/html/draft-ietf-acme-acme-15#section-8.1 . It has to match the account public key of the certificate order.
I’m not sure whether the 128-bit opaque has a significant security function other than to disambiguate challenges. You could just configure your webserver to reflect the challenge token from the request, if you wanted.
edit: I note that the draft mentions:
Secondly, the entropy requirement
makes it more difficult for ACME clients to implement a “naive”
validation server that automatically replies to challenges without
being configured per-challenge.
but it seems to be untrue, for the HTTP challenge at least.
Isn’t the public key… PUBLIC?
Wouldn’t a hash of public information be available to ALL?
I must have missed something - misread something…
The purpose of the challenge token is not to be secret, it’s to prove that the subscriber can place arbitrary content at a specific URL, demonstrating control of the domain.
Which is far from a hash from a public cert - which anyone can create and may essentially never change.
Exactly who could place trust on anyone based on just that?
I must be missing something in @anon95262142’s question:
But I just don’t see how (other than maybe the first person to do so) anyone who claims ownership based on a pre-existing condition can also be trusted. And even IF that were the case, how would the real owner authenticate on the next go 'round? [wouldn’t the new proof be the exact same hash?]