Re: [Acme] key agility?

[Phillip Hallam-Baker <[e-mail]>]

On Fri, Dec 19, 2014 at 1:01 AM, Daniel Kahn Gillmor <[e-mail]>
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
> >> <[e-mail] <mailto:[e-mail]>>
> >> 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?


This is still unclear to me.

Are we talking about the client negotiating the provision of a certificate
pair so as to be able to support dual RSA/ECC issue?

Or are we talking about the client being able to select the use of an ECC
or RSA key to authenticate the ACME protocol.


If the first, I agree. If the second then I am very confused.

As I see the ACME protocol, it is an upgrade to the traditional Cert issue
protocol to support the new requirements of modern cert use including
embedded devices and the cloud. Enabling the ECC transition is another
important requirement.


Fortunately it is pretty easy to support any of these if we support a
service feature negotiation phase.

The guts of the protocol is a request of the form:

<Signature Parameters>

{ "IssueRequest" : {
    "Version" : "1.0",
    "CSR" : <CSR in Base64>,
    <other attributes>
    }

While it is simplest and most straightforward to treat ECC and RSA as issue
of two separate certs, combining them might simplify the management task
and in particular integration with TRANS.