Draft: draft-ietf-acme-acme

Commentary: Based on the acme mailing list discussion[0 ] on " proactive " vs " on - finalization " issuance it seems there is more support for the proactive approach . Speaking on behalf of Let 's Encrypt and the  developers we 're willing to compromise and support proactive issuance as the sole issuance method in order to simplify the protocol & implementations . This PR changes the language around certificate issuance to reflect that the server MUST issue the certificate proactively once all the required challenges for an application have been fulfilled . The open issue corresponding to making this decision is removed now that there is one supported option . In an effort to close out open questions around applications this commit also removes the open issue around multiple certificates per application . If there is a demand for automating repeat issuance there should be a new thread started with a concrete proposal . 0 : 
 apologies ! I missed your comments until today . Both are resolved in Thank you for the feedback . 
 Oh ! They were fresh and I misread the dates . Not such a bad turn around after all :-) 
 Fantastic , thanks . Merging .
Mailing list commentary: Hi folks , I wanted to revisit a discussion on the server proactively issuing certificates . Section 4 , " Protocol Overview"[0 ] currently has a paragraph that reads : the the application be to the There is also an " Open Issue " remark related to proactive issuance in Section 6.1.3[1 ] . I think the specification should decide whether proactive issuance or on - finalization issuance should be used instead of allowing both with no indication to the client which will happen . It 's the preference of Let 's Encrypt that the specification only support on - finalization issuance . This is cheaper to implement and seems to be the path of least surprise . It also seems to better support large volume issuance when the client may want explicit control over when the certificates for multiple applications are issued . In the earlier " Re : [ Acme ] Preconditions " thread[2 ] seems to agree that there should be only one issuance method to simplify client behaviours , though he favours proactive issuance instead of on - finalization issuance . While it saves a round - trip message I ' m not sure that this alone is convincing enough to choose proactive issuance as the one issuance method . What are the thoughts of other list members ?    [ 0 ] [ 1 ] [ 2 ]
Paragraph (version A):
Once the validation process is complete and the server is satisfied
that the client has met its requirements, the server can either
proactively issue the requested certificate or wait for the client to
request that the application be "finalized", at which point the
certificate will be issued and provided to the client.
Paragraph (version B):
Once the validation process is complete and the server is satisfied
that the client has met its requirements, the server will issue the
requested certificate and make it available to the client.
Paragraph (version A):
The server SHOULD issue the requested certificate and update the
application resource with a URL for the certificate as soon as the
client has fulfilled the server's requirements.  If the client has
already satisfied the server's requirements at the time of this
request (e.g., by obtaining authorization for all of the identifiers
in the certificate in previous transactions), then the server MAY
proactively issue the requested certificate and provide a URL for it
in the "certificate" field of the application.  The server MUST,
however, still list the satisfied requirements in the "requirements"
array, with the state "valid".
Paragraph (version B):
The server MUST issue the requested certificate and update the
application resource with a URL for the certificate as soon as the
client has fulfilled the server's requirements.  If the client has
already satisfied the server's requirements at the time of this
request (e.g., by obtaining authorization for all of the identifiers
in the certificate in previous transactions), then the server MUST
proactively issue the requested certificate and provide a URL for it
in the "certificate" field of the application.  The server MUST,
however, still list the satisfied requirements in the "requirements"
array, with the state "valid".