Draft: draft-ietf-acme-acme

Commentary: As discussed at IETF 96 , even with the new - app flow , it is still useful to be able to request authorization outside of an issuance transaction . This PR re - adds the new - authz transaction .
Paragraph (version B):
The application process described above presumes that authorization
objects are created reactively, in response to an application for
issuance.  Some servers may also wish to enable clients to obtain
authorization for an identifier proactively, outside of the context
of a specific issuance.  For example, a client hosting virtual
servers for a collection of names might wish to obtain authorization
before any servers are created, and only create a certificate when a
server starts up.
Paragraph (version B):
In some cases, a CA running an ACME server might have a completely
external, non-ACME process for authorizing a client to issue for an
identifier.  In these case, the CA should provision its ACME server
with authorization objects corresponding to thsee authorizations and
reflect them as alread-valid requirements in any issuance
applications requested by the client.
Paragraph (version B):
If a CA wishes to allow pre-authorization within ACME, it can offer a
"new authorization" resource in its directory by adding the key "new-
authz" with a URL for the new authorization resource.
Paragraph (version B):
To request authorization for an identifier, the client sends a POST
request to the new-authorization resource specifying the identifier
for which authorization is being requested and how the server should
behave with respect to existing authorizations for this identifier.
Paragraph (version B):
The type of identifier.
Paragraph (version B):
The identifier itself.
Paragraph (version B):
How an existing authorization should be handled.  Possible values
are "accept" and "require".
Paragraph (version B):
Before processing the authorization request, the server SHOULD
determine whether it is willing to issue certificates for the
identifier.  For example, the server should check that the identifier
is of a supported type.  Servers might also check names against a
blacklist of known high-value identifiers.  If the server is
unwilling to issue for the identifier, it SHOULD return a 403
(Forbidden) error, with a problem document describing the reason for
the rejection.
Paragraph (version B):
If the authorization request specifies "existing" with a value of
"accept" or "require", before proceeding, the server SHOULD determine
whether there are any existing, valid authorization resources for the
account and given identifier.  If one or more such authorizations
exists, a response SHOULD returned with status code 303 (See Other)
and a Location header pointing to the existing resource URL;
processing of the request then stops.  If there are multiple such
authorizations, the authorization with the latest expiry date SHOULD
be returned.  If no existing authorizations were found and the value
for "existing" was "require", then the server MUST return status code
404 (Not Found); if it was "accept" or was any other value or was
absent, processing continues as follows.
Paragraph (version B):
If the server is willing to proceed, it builds a pending
authorization object from the inputs submitted by the client.
Paragraph (version B):
The server allocates a new URI for this authorization, and returns a
201 (Created) response, with the authorization URI in a Location
header field, and the JSON authorization object in the body.  The
client then follows the process described in identifier-authorization
to complete the authorization process.
Paragraph (version A):
Authorization resources are created by the server in response to
certificate applications submitted by an account key holder; their
URLs are provided to the client in "authorization" requirement
objects.  The authorization object is implicitly tied to the account
key used to sign the new-application request.
Paragraph (version A):
When a client receives an application from the server with an
"authorization" requirement, it downloads the authorization resource
by sending a GET request to the indicated URL.
Paragraph (version B):
Authorization resources are created by the server in response to
certificate applications or authorization requests submitted by an
account key holder; their URLs are provided to the client in the
responses to these requests.  The authorization object is implicitly
tied to the account key used to sign the request.
Paragraph (version B):
When a client receives an application from the server with an
"authorization" requirement, it downloads the authorization resource
by sending a GET request to the indicated URL.  If the client
initiates authorization using a request to the new authorization
resource, it will have already recevied the pending authorization
object in the response to that request.