Subject: [Acme] Key Roll-Over Equivalence

From: Daniel McCarney <[email-masked]>
Date: Tue, 12 Jul 2016 16:50:35 -0400

Section 6.2.1 of the ACME draft, "Account Key Roll-Over", specifies a
number of additional validation steps that MUST be performed for a
key-change request. Number 5 reads:

Check that the “key” field is not equivalent to the current account key or
> any other currently active account key.

What does "equivalence" mean in the context of JSON Web Keys?

Thanks!

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Tue, 12 Jul 2016 15:39:09 -0700

> What does "equivalence" mean in the context of JSON Web Keys?
This is good feedback, I didn't define it clearly in the code as-is. The
goal is this: Since accounts are uniquely identified by their key, keys
must be unique. Let's Encrypt / Boulder treats this as uniqueness across
the "key material" pieces, ignoring fields like "use" and "kid." More
specifically we marshal the key as an x509 SubjectPublicKeyInfo and hash it.

We should probably add to the ACME spec a notion of preventing duplicate
keys at registration time, formally define what it means to be a
duplicate, and apply the same concept here.