On Wed, 30 Sep 2015 21:48:32 -0700 Richard Barnes <r...@ipv.sx> wrote:
> The authorized key object is JSON, which means that the number of > serializations for it is bounded only be the size of the object the > server will accept. If a malicious client can generate an authorized > key object that collides with a legitimate one (a second preimage), > then he can authorize his own key. Having the server generate the > object puts all of the entropy that goes into the digest under the > control of the server. > [...] > In other words, there's a trade-off here between a little more surety > in the crypto and a little more protection against the CDN. Given > that ambiguity about crypto bit us last time, I opted for the former. 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 ;-) > Would it help to clarify that the CA MUST verify the token before > accepting the response, and the client MUST NOT provision the > validation until after the response is accepted? It would help in that the client would have to make two mistakes instead of just one. Nevertheless, if the choice is between counting on client implementers to not make mistakes and counting on SHA-256 to have second-preimage resistance, I think the choice is clear. -- Andrew _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
