Hello All It was completely pocket. Apologize for the spam
Regards Ashok On Oct 1, 2015 7:35 PM, Ashok Bommisetti <abomm...@syr.edu> wrote: > > 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 <a...@andrewayer.name> wrote: > > > > 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 > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
