Subject: [Acme] Specify account by kid (reg URL) rather than key. #193

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Fri, 23 Sep 2016 14:33:54 -0700

This is the result of the conversation on the Implicit vs explicit keys
thread:

https://github.com/ietf-wg-acme/acme/pull/193

Previously, each authenticated POST included a copy of its public key in
the JWS protected header. Servers were required to canonicalize this key
in some way and look it up in a database, then verify the payload.
However, servers also had the option of verifying the payload, and then
looking up the key in the database.  This opened up a category of
potential bugs based on truncated database fields or hash collisions,
where an attacker could craft a key pair the would potentially be
matched to someone else's account.

Incidental benefits: Switching to kid makes payloads somewhat smaller,
and removes the need to define key equality in the ACME spec.

---

From: Hugo Landau <[email-masked]>
Date: Sun, 25 Sep 2016 02:16:52 +0100

I'm somewhat against this on the grounds that it introduces unnecessary
state into clients (the registration URI), increasing their complexity.

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Mon, 26 Sep 2016 21:51:41 -0700

I understand the concern, but I think that clients already have to store
a significant amount of state: the ACME directory URL, the private key,
and the domain names, certificates, and private keys of existing
certificates. I think that one more item, the account URL, is not a
heavy burden, especially when weighed against a real flaw in the
protocol. You could consider it akin to storing a username and password
for a more traditional login.

All that said, for clients that find it to be a big savings, there is
always the method of finding the account URL by POSTing again to new-reg
with the same key.

On 09/24/2016 06:16 PM, Hugo Landau wrote:
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 27 Sep 2016 15:01:01 +1000

I am inclined to think that this is a good change, on the basis that
it means that the server is minting the identifiers that the client
uses.  I think that Jacob is probably understating the potential for
bugs here.  And key canonicalization is a bad smell.

---

From: Daniel McCarney <[email-masked]>
Date: Tue, 27 Sep 2016 09:24:45 -0400

I'm also strongly in favour of this change. I think the minimal increase in
client
state/complexity is offset by the gain of knowing that the category of
potential
bugs that Jacob mentions are avoided.