I'm fine with having the client generate the object, but I think I'd be more comfortable if the data that the client had to provision for the challenge was deterministic, less for cryptographic reasons but simply to make it easier to reason about the protocol properties.
Maybe this is a case for a non-JSON encoding. -Ekr On Thu, Oct 1, 2015 at 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
