Change:
6.4.1. <ins> 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. 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. 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. 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. The identifier that the account is authorized to represent The type of identifier. The identifier itself. How an existing authorization should be handled.  Possible values are "accept" and "require". 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. 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. If the server is willing to proceed, it builds a pending authorization object from the inputs submitted by the client. "identifier" the identifier submitted by the client "status": MUST be "pending" unless the server has out-of-band information about the client's authorization status "challenges" and "combinations": As selected by the server's policy for this identifier 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. 6.4.2. </ins> To download the issued certificate, the client simply sends a GET request to the certificate URL.

Discussion:
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.