Re: [Acme] New draft and DANGER

On 10/01/2015 07:04 PM, Andrew Ayer wrote: > 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

Re: [Acme] New draft and DANGER

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

Re: [Acme] New draft and DANGER

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

Re: [Acme] New draft and DANGER

On 10/02/2015 02:00 PM, Richard Barnes wrote: > 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) This sounds reasonable. I don't see a reason to have the client echo

Re: [Acme] New draft and DANGER

I have implemented this solution in this PR: https://github.com/ietf-wg-acme/acme/pull/13 Last call for comments... On Fri, Oct 2, 2015 at 5:00 PM, Richard Barnes wrote: > How about something like this: > > Authorized key object is TOKEN.FINGERPRINT, where: > * TOKEN is the token