On 10/01/2015 07:04 PM, Andrew Ayer wrote: > Well... previously, the protocol was relying on a non-existent > property of digital signatures. With a client-constructed authorized > key object, it would be relying on the second-preimage resistance of > SHA-256, which is a pretty safe bet, to put it mildly. (Also, if I > were an attacker with a second-preimage attack against SHA-256, I > wouldn't bother attacking a CA - I'd just mint my own certs ;-) I agree here: If the goal is to defend against a second-preimage attack on the same hash we are issuing certs with, I don't think that goal is sensible and I'd rather go with the design that makes it harder for clients to make mistakes.
Also, Richard, when we talked about this last week we discussed how adding another layer of base64-encoded JSON (the authorizedKeys object) was an anti-pattern. One alternate design we discussed was to have the validation resource be a sha256 hash of the exact bytes the client POSTed to the challenge resource. This has the advantage of introducing one fewer object type. We can do away with the "authorizedKeys" object entirely, since the posted challenge object contains the account key (in JWS headers) and the token (if we require it so). _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
