This seems OK to me. -Ekr
On Fri, Oct 2, 2015 at 2:00 PM, Richard Barnes <r...@ipv.sx> wrote: > How about something like this: > > Authorized key object is TOKEN.FINGERPRINT, where: > * TOKEN is the token in the challenge > * FINGERPRINT is the JWK thumbprint of the account key (per the relevant > JOSE spec) > > Same processing, except neither side has to send the object. (Might still > have the client echo the token.) > > Jacob, that gets you no base64(JSON), and EKR, that gets you determinacy. > > Copasetic? > > --Richard > > > > On Friday, October 2, 2015, Eric Rescorla <e...@rtfm.com> wrote: > >> 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
