Subject: [Acme] key agility?

From: Anders Rundgren <[email-masked]>
Date: Thu, 18 Dec 2014 21:53:22 +0100

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 18 Dec 2014 18:41:11 -0500

> preferences/capabilities.

I do not know what you mean here.

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 19 Dec 2014 06:09:12 +0100

On 2014-12-19 00:41, Phillip Hallam-Baker wrote:
> On Thu, Dec 18, 2014 at 3:53 PM, Anders Rundgren <[email-masked] <mailto:[email-masked]>> wrote:
>

The ability to negotiate client key algorithm.

Anders

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 19 Dec 2014 01:01:19 -0500

On 12/19/2014 12:09 AM, Anders Rundgren wrote:
>> On Thu, Dec 18, 2014 at 3:53 PM, Anders Rundgren
>> <[email-masked] <mailto:[email-masked]>>
>> wrote:
>>

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?

	--dkg

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 19 Dec 2014 07:02:47 +0100

> Anders, is that what you're talking about?

Indeed, pardon for being so unclear :-(

Anders

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 19 Dec 2014 10:46:03 -0500

> 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.

---

From: Richard Barnes <[email-masked]>
Date: Fri, 19 Dec 2014 13:11:23 -0500

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>