Draft: draft-ietf-acme-acme

Commentary: There has been no implementer interest in the proof - of - possession challenge , and it makes the document more complex by having a completely different structure than the other challenges . If it is decided later that such a challenge is necessary , it can be in a follow - on extension specificiation . 
 Generally this seems fine , and I wholeheartedly agree with the purpose of the removal ( for now ) . One problem I ca n't open a comment for : Line 2099 , the last paragraph before " Preventing Authorization Hijacking " , still refers to the PoP Challenge . Without the PoP Challenge wording , a new reader may take that this to be referring to the implicit Proof of Possession of the ACME Account Key and thus be confused . Since it 's non - normative , perhaps you could simply modify that paragraph into something more like :
Paragraph (version A):
Different challenges allow the server to obtain proof of different
aspects of control over an identifier.  In some challenges, like HTTP
and TLS SNI, the client directly proves its ability to do certain
things related to the identifier.  In the Proof of Possession
challenge, the client proves historical control of the identifier, by
reference to a prior authorization transaction or certificate.
Paragraph (version B):
Different challenges allow the server to obtain proof of different
aspects of control over an identifier.  In some challenges, like HTTP
and TLS SNI, the client directly proves its ability to do certain
things related to the identifier.  The choice of which challenges to
offer to a client under which circumstances is a matter of server
policy.
Paragraph (version A):
The Proof of Possession challenge verifies that a client possesses a
private key corresponding to a server-specified public key, as
demonstrated by its ability to sign with that key.  This challenge is
meant to be used when the server knows of a public key that is
already associated with the identifier being claimed, and wishes for
new authorizations to be authorized by the holder of the
corresponding private key.  For DNS identifiers, for example, this
can help guard against domain hijacking.
Paragraph (version A):
This method is useful if a server policy calls for issuing a
certificate only to an entity that already possesses the subject
private key of a particular prior related certificate (perhaps issued
by a different CA).  It may also help enable other kinds of server
policy that are related to authenticating a client's identity using
digital signatures.
Paragraph (version A):
This challenge proceeds in much the same way as the proof of
possession of the authorized key pair in the main ACME flow
(challenge + authorizationRequest).  The server provides a nonce and
the client signs over the nonce.  The main difference is that rather
than signing with the private key of the key pair being authorized,
the client signs with a private key specified by the server.  The
server can specify which key pair(s) are acceptable directly (by
indicating a public key), or by asking for the key corresponding to a
certificate.
Paragraph (version A):
An array of certificates, in base64url-encoded DER format, that
contain acceptable public keys.
Paragraph (version A):
This JWS is NOT REQUIRED to have a "nonce" header parameter (as with
the JWS objects that carry ACME request objects).  This allows proof-
of-possession response objects to be computed off-line.  For example,
as part of a domain transfer, the new domain owner might require the
old domain owner to sign a proof-of-possession validation object, so
that the new domain owner can present that in an ACME transaction
later.
Paragraph (version A):
The validation JWS MUST contain a "jwk" header parameter indicating
the public key under which the server should verify the JWS.
Paragraph (version A):
The client's response includes the server-provided nonce, together
with a signature over that nonce by one of the private keys requested
by the server.
Paragraph (version A):
If all of the above verifications succeed, then the validation is
successful.  Otherwise, the validation fails.
Paragraph (version A):
Proof of possession of a prior key: The signature by the prior key
covers the account public key.
Paragraph (version A):
An active attacker on the validation channel can subvert the ACME
process, by performing normal ACME transactions and providing a
validation response for his own account key.  The risks due to
hosting providers noted above are a particular case.  For identifiers
where the server already has some credential associated with the
domain this attack can be prevented by requiring the client to
complete a proof-of-possession challenge.
Paragraph (version B):
An active attacker on the validation channel can subvert the ACME
process, by performing normal ACME transactions and providing a
validation response for his own account key.  The risks due to
hosting providers noted above are a particular case.  For identifiers
where the server already has some public key associated with the
domain this attack can be prevented by requiring the client to prove
control of the corresponding private key.