There are a few issues with the Proof of Possession challenge as currently spec'ed (https://github.com/ietf-wg-acme/acme/blob/master/draft-ietf-acme-acme.md#proof-of-possession-of-a-prior-key).
1. A TLS handshake using DHE or ECDHE involves the server automatically signing something that begins with 32 bytes of client data*, followed by some non-client controlled data. Proof of Posession asks for a signature over a JSON body, the order of which is chosen by the client. If someone can figure out a way to order a JSON response so that the important parts are in the first 32 bytes, and the remainder of the message is ignored, they might be able to use a signature obtained simply by handshaking with a server that has the relevant cert deployed. 2. The response to the Proof of Posession challenge is expected to be JWS signed by a key in one of the provided certs, rather than the account key. This means that a third party who doesn't possess the account key could complete the PoP challenge. Arguably this is a benefit, but it requires very different handling from other challenge types, and is likely to complicate implementations. Possibilities: - Ask the client to sign a CSR containing a random token, with one of the appropriate private keys, and POST to the challenge URL with JWS signed by the account key and containing that CSR base64-encoded.* CSRs are already intended as a way to prove possession of a given key, and their format is more strictly specified so it is harder to manipulate the order of elements. - Use a weaker form of PoP, call it "Live Cert Check:" the CA connect to a running TLS server with a valid certificate for the name in question, validates the cert, and fetches a file under .well-known. This winds up being very similar to SimpleHTTP plus a valid certificate requirement. Any other suggestions? *Thanks to Adam Langley for pointing this out. *Thanks to Andrew Ayer for suggesting this. _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
