Re: [Acme] Signature misuse vulnerability in draft-barnes-acme-04

[Jacob Hoffman-Andrews <[e-mail]>]

This is an excellent find, thanks for spotting it and writing it up.

On 08/11/2015 08:52 AM, Andrew Ayer wrote:
> To fix this, I propose simply publishing the authorized account public key (or a hash of it) in the
> TXT record (for DNS challenges), in the TLS certificate (for DVSNI), or in the file (for Simple HTTP).
This seems like a good approach, though I think it's not compatible with
the new domain validation requirements being worked on at the CA/B
Forum: https://cabforum.org/pipermail/validation/2015-July/000080.html,
which require a random token. We could propose an addition to those
requirements, once we have concrete spec language in place.

The nice thing about publishing account keys is that they can remain
constant over time, which would in theory allow for significant changes
to the protocol. For instance, DVSNI, SimpleHTTP, and DNS challenges
could be specified as re-validateable on demand, and in practice a CA
could revalidate the relevant challenges immediately before issuance,
not just at authorization time.

That, in turn, would resolve some thorny problems people have raised
(https://github.com/letsencrypt/boulder/issues/572) about transferring
authorizations between account keys, and removing authorizations from
account keys. For instance, if we specify that
/.well-known/certificate/acme-account-keys.json on any given host should
contain a list of JWKs authorized to issue certificates, then
authorizing a new hosting provider to issue certificates would be as
simple as adding their account key to that file. The hosting provider
could even check for themselves that it's present before beginning an
interaction with the ACME server. Similarly, someone who leaves a
hosting provider would be able to remove that provider's key from the
relevant file to deauthorize them from issuing future certificates.

A similar system could apply with key hashes for DVSNI and DNS.