In the current version of the spec, for SimpleHTTPS Validation, the
client can specify the path (under .well-known/acme-challenge) where the
server should expect to find a copy of the token. The goal as I
understand it is to allow a single client to manage multiple pending
authorization requests without file collisions. However, I think this
adds unnecessary complexity and risk.
Proposal: For the SimpleHTTPS challenge, the client should not provide a
path. The server should always fetch
.well-known/acme-challenge/<token>.txt, and should expect the contents
to equal <token>.
For DVSNI and DNS challenges, the client provides a random string `s',
to be hashed with the server's random string `r'. What sort of attack
does this protect against? It seems unnecessarily risky to allow the
client input into the hash, and leads to some issues like
https://github.com/letsencrypt/acme-spec/issues/12.
Proposal: For the DVSNI and DNS challenges, the client should not
provide a random string `s', but should directly sign the server's
random string `r'.a
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
