Subject: [Acme] ACME -06: account key roll-over

From: Yaron Sheffer <[email-masked]>
Date: Fri, 2 Jun 2017 23:34:51 +0300

I opened PRs for my other comments, but this one is not editorial.

There's a long list of checks to be run by the CA for account key 
roll-over, and the current check #8 is "Check that the “newKey” field of 
the key-change object also verifies the inner JWS." I think that 
requiring that "newKey" is bitwise identical to the inner "jwk" is both 
simpler and a stricter check. In principle there may be two different 
public keys that verify the same signature, but I don't think we want to 
see such a case here.

Thanks,
     Yaron

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 3 Jun 2017 13:25:41 +0300

On Fri, Jun 02, 2017 at 11:34:51PM +0300, Yaron Sheffer wrote:
> There's a long list of checks to be run by the CA for account key roll-over,
> and the current check #8 is "Check that the “newKey” field of the key-change
> object also verifies the inner JWS." I think that requiring that "newKey" is
> bitwise identical to the inner "jwk" is both simpler and a stricter check.
> In principle there may be two different public keys that verify the same
> signature, but I don't think we want to see such a case here.

Yeah, violation of DRY principle causing problems.

The standard signature security notion does not preclude various
unpleasant things, like:

- Key recovery (compute a public key that verifies a given signature
  for a given message).
- Aliases (two keys that validate the same things)
- Weak keys (keys that admit signatures that validate for all
  messages).

(Plus variations where probability of those things happening is high,
or "bad" keys not being efficiently recognizable).

And weak keys could be even nastier here than aliases here. IIRC
CryptoNote had a vulernability due to misusing Ed25519 in a way
that was weak to weak keys (there are 8 such keys for Ed25519).

-Ilari