Bbbbbb b. Bbbbbb by b bbbbb by bbbbb. Hxbbb. BBB. BBB b bbh huh. H. N. F by by bbbbb BBB b.
On Oct 1, 2015 7:04 PM, Andrew Ayer <[email protected]> wrote: > > On Wed, 30 Sep 2015 21:48:32 -0700 > Richard Barnes <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
