WIP: Enable servers to require authorization before order #350
Conversation
draft-ietf-acme-acme.md
Outdated
| MUST, however, still list the completed authorizations in the "authorizations" | ||
| array. | ||
| Once the client has fulfilled the server's requirements, the server MUST update | ||
| the order resoruce with a URL for the certificate. It SHOULD begin the issuance |
draft-ietf-acme-acme.md
Outdated
| Once the client has fulfilled the server's requirements, the server MUST update | ||
| the order resoruce with a URL for the certificate. It SHOULD begin the issuance | ||
| process at this point, but MAY postpone issuance until it receives a GET request | ||
| for the certificate URL. |
There was a problem hiding this comment.
Let's Encrypt currently constructs certificate URLs using the serial # of the certificate. It's not a big deal but I wanted to note that a MUST for updating the order with a certificate URL when the order is authorized and a MAY for postponing issuance until GET means CAs that delay issuance can't reference any certificate attributes in the URL since they have to construct it before issuance.
| (Unauthorized) and error code "authorizationFirst". Any error document with | ||
| this error code MUST include a field "authorizations" containing an array of | ||
| URLs for authorization objects that must be completed before the new-order | ||
| request can succeed. |
There was a problem hiding this comment.
This seems awkward - are there any other places in the protocol where the caller is expected to pull a non-standard field out of an error document in order to learn how to proceed with a subsequent API operation?
There was a problem hiding this comment.
Don't know if this counts as a subsequent API operation, but the section on re-agreement to ToS has the client direct the user to a URI from the "instance" field.
In any case, the inclusion of additional data in problem documents is well defined.
An alternative solution to #342