Re: [Acme] key agility?

On Fri, Dec 19, 2014 at 1:02 AM, Anders Rundgren <
anders.rundgren.net@gmail.com> wrote:
>
> On 2014-12-19 07:01, Daniel Kahn Gillmor wrote:
>
>> On 12/19/2014 12:09 AM, Anders Rundgren wrote:
>>
>>> On 2014-12-19 00:41, Phillip Hallam-Baker wrote:
>>>
>>>> On Thu, Dec 18, 2014 at 3:53 PM, Anders Rundgren
>>>> <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>>
>>>> wrote:
>>>>
>>>>      With a multi-step protocol some kind of key agility should be
>>>> possible to support.
>>>>      The client could for example start with telling its
>>>> preferences/capabilities.
>>>>
>>>>      Anders
>>>>
>>>>
>>>> I do not know what you mean here.
>>>>
>>>>
>>> The ability to negotiate client key algorithm.
>>>
>>
>> I think Anders is hinting at something like the following:
>>
>>   * some TLS servers today have both RSA and ECDSA keys, and will offer a
>> different cert depending on the capabilities offered by their clients.
>>
>>   * this capacity (to support both key algorithms at once) is an
>> important one to be able to do a transition when dealing with a
>> heterogenous network.
>>
>>   * acme should be able to support offering multiple certificates (with
>> different key algorithms) to a single client which requests them.
>>
>> Anders, is that what you're talking about?
>>
>
> Indeed, pardon for being so unclear :-(
>
>
Thanks for clarifying.  ACME incorporates the idea of multiple certificates
for the same identifier, even for different clients.  That's the reason for
the separation between the "authorized key pair" (~= client) and  the
"subject key pair" (~= certificate).  An authorized key pair can be used to
issue any number of certificates for any combination of names that it is
authorized for.

That general framework includes the kind of flexibility you're looking for.

--Richard

> Anders
>
>
>>         --dkg
>>
>>
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>