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. _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
