The proposed simplification looks good to me and would make the Boulder
implementation much cleaner overall.

I also agree the ambiguity about which header the 'jwk' field is
provided in should be cleared up, it seems like there is no reason not
to require it in the protected header.

On 06/22/2016 11:26 AM, Jacob Hoffman-Andrews wrote:
> Any objections to the below? We'd like to start implementing in Boulder
> soon.
> 
> On 06/09/2016 03:59 PM, Jacob Hoffman-Andrews wrote:
>> On 03/31/2016 02:27 PM, Jacob Hoffman-Andrews wrote:
>>> I'd like to propose some changes to how we do account key roll-over. I
>>> think the current approach is too complex. The current version is
>>> included below for reference.
>>>
>>> Instead I'd like to propose:
>>>
>>> To update the key on a registration object, POST a double-signed JOSE
>>> object to the registration URL, with the field "key" containing the new
>>> key, in JWK format.
>>>
>>> The double-signed object should have two signatures: one from the old
>>> key, and one from the new key. This ensures that the key rollover is
>>> authorized by the existing account holder, and also proves that the
>>> requester possesses the private key corresponding to the new key.
>>>
>>> What do you all think?
>>>
>>> Relatedly, since we are introduce a self-signature to prove possession
>>> of the new key, we probably want to introduce the same guarantee on
>>> initial account creation. One easy way to achieve this would be to
>>> require that the "jwk" field be provided in the protected header, rather
>>> than in the protected or unprotected header as is allowed today.
>> I've posted a PR for this change, tweaked slightly to use a separate
>> resource: https://github.com/ietf-wg-acme/acme/pull/139.
>>
>> _______________________________________________
>> 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

Reply via email to