Hi, > > > > > > [...] Secondly, the entropy requirement > > > > > > prevents ACME clients from implementing a "naive" > > > > > > validation server that automatically replies to challenges > > > > > > without participating in the creation of the initial > > > > > > authorization request. > > > > > > > > > > > > IMPORTANT: I'm not sure I see how this applies to the HTTP > > > > > > mechanism -- couldn't you write a script to reply > > > > > > to .well-known/acme-challenge/<foo> with <foo>.<key > > > > > > thumbprint> for a fixed key thumbprint? The validation > > > > > > thumbprint> server would ned to > > > > > > know about the ACME account in question, but not about any > > > > > > individual authorization request. > > > > > > > > > > It would also need to know the <foo> value, which is not > > > > > provided in the validation request specifically to avoid > > > > > this. > > > > > > > > As I said above, "[w]ell now I'm really confused." In the > > > > example HTTP challenge exchange (duplicated here): > > > > > > > > GET > > > > /.well-known/acme-challenge/LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0 > > > > Host: example.org > > > > > > > > HTTP/1.1 200 OK > > > > Content-Type: application/octet-stream > > > > > > > > LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0.9jg46WB3rR_AHD-EBXdN7cBkH1WOu0tA3M9fm21mqTI > > > > > > > > Doesn't the path in the GET include the <foo>? > > > > > > Yes, and some people are already using this to add a generic > > > authorization replier (which needs the thumbprint of the account > > > key). For example, the acme.sh client supports this "stateless > > > mode" (as it is called there): > > > https://github.com/Neilpang/acme.sh/wiki/Stateless-Mode > > > > Okay, that matches up with my understanding and maybe un-confuses > > me. > > > > But does this state of affairs nullify the text in the -14 about: > > > > [...] the entropy requirement > > prevents ACME clients from implementing a "naive" validation > > server that automatically replies to challenges without > > participating in the creation of the initial authorization request. > > > > ? > > Also, if we wanted to prevent this sort of dumb script, it seems like > we could have the ACME server do a > GET /.well-known/acme-challenge/<hash-of-token> > instead of > GET /.well-known/acme-challenge/<token> > > and expect the un-hashed token in the response body. (Witih obvious > questions about explicit hash agility vs. hardcoding a hash per > challenge type.)
That would work. However, I'm not sure whether this should really be disallowed. I also understand the text from draft-14 as you do, but I since this incorporates the account key hash, it doesn't validate for challenges coming from other ACME accounts. Also, there has been a proposal (https://github.com/ietf-wg-acme/acme/issues/393) to allow something similar for DNS validation (as dns-02), which explicitly mentions this automation. Since nobody responded that such an automation is unwanted, my assumption is that this automation is a feature and not a bug. It would be nice if this would be more clear from the text, though. Cheers, Felix _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
