Network Working Group                                          R. Barnes
Internet-Draft                                                   Mozilla
Intended status: Standards Track                      J. Hoffman-Andrews
Expires: April 6, September 22, 2016                                          EFF
                                                               J. Kasten
                                                  University of Michigan
                                                        October 04, 2015
                                                          March 21, 2016

          Automatic Certificate Management Environment (ACME)
                        draft-ietf-acme-acme-01
                        draft-ietf-acme-acme-02

Abstract

   Certificates in the Web's X.509 PKI (PKIX) are used for a number of
   purposes, the most significant of which is the authentication of
   domain names.  Thus, certificate authorities in the Web PKI are
   trusted to verify that an applicant for a certificate legitimately
   represents the domain name(s) in the certificate.  Today, this
   verification is done through a collection of ad hoc mechanisms.  This
   document describes a protocol that a certificate authority (CA) and
   an applicant can use to automate the process of verification and
   certificate issuance.  The protocol also provides facilities for
   other certificate management functions, such as certificate
   revocation.

   DANGER: Do not implement this specification.  It

   DISCLAIMER: This is a work in progress draft of ACME and has not yet
   had a known
   signature reuse vulnerability.  For details, see thorough security analysis.

   RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH: The source for
   this draft is maintained in GitHub.  Suggested changes should be
   submitted as pull requests at https://github.com/ietf-wg-acme/acme .
   Instructions are on that page as well.  Editorial changes can be
   managed in GitHub, but any substantive change should be discussed on
   the following
   discussion:

   https://mailarchive.ietf.org/arch/msg/acme/F71iz6qq1o_QPVhJCV4dqWf-
   4Yc ACME mailing list (acme@ietf.org).

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 6, September 22, 2016.

Copyright Notice

   Copyright (c) 2015 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Deployment Model and Operator Experience  . . . . . . . . . .   4
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5   6
   4.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Protocol Elements  Message Transport . . . . . . . . . . . . . . . . . . . . . .   9
     5.1.  HTTPS Requests  . . . . . . . . . . . . . . . . . . . . .   9
     5.2.  Registration Objects  .  Request Authentication  . . . . . . . . . . . . . . . . .  10   9
     5.3.  Authorization Objects . . .  Request URI Type Integrity  . . . . . . . . . . . . . . .  11  10
     5.4.  Errors  .  Replay protection . . . . . . . . . . . . . . . . . . . .  11
       5.4.1.  Replay-Nonce  . . . .  13
     5.5.  Replay protection . . . . . . . . . . . . . . . .  12
       5.4.2.  "nonce" (Nonce) JWS header parameter  . . . .  14
       5.5.1.  Replay-Nonce . . . .  12
     5.5.  Errors  . . . . . . . . . . . . . . . .  14
       5.5.2.  "nonce" (Nonce) JWS header parameter . . . . . . . .  15
     5.6.  Key Agreement .  12
   6.  Certificate Management  . . . . . . . . . . . . . . . . . . .  14
     6.1.  Resources . .  15
   6.  Certificate Management . . . . . . . . . . . . . . . . . . .  16
     6.1.  Resources . . .  14
       6.1.1.  Registration Objects  . . . . . . . . . . . . . . . .  16
       6.1.2.  Authorization Objects . . . . .  16
     6.2.  Directory . . . . . . . . . . .  17
     6.2.  Directory . . . . . . . . . . . . .  18
     6.3.  Registration . . . . . . . . . . .  18
     6.3.  Registration  . . . . . . . . . . .  18
       6.3.1.  Recovery Keys . . . . . . . . . . .  20
       6.3.1.  Account Key Roll-over . . . . . . . . .  20
     6.4.  Account Recovery . . . . . . .  22
       6.3.2.  Deleting an Account . . . . . . . . . . . . .  22
       6.4.1.  MAC-Based Recovery . . . .  23
     6.4.  Identifier Authorization  . . . . . . . . . . . . .  23
       6.4.2.  Contact-Based Recovery . . .  24
       6.4.1.  Responding to Challenges  . . . . . . . . . . . .  25
     6.5.  Identifier Authorization . .  26
       6.4.2.  Deleting an Authorization . . . . . . . . . . . . . .  27
     6.6.  28
     6.5.  Certificate Issuance  . . . . . . . . . . . . . . . . . .  31
     6.7.  29
     6.6.  Certificate Revocation  . . . . . . . . . . . . . . . . .  34  32
   7.  Identifier Validation Challenges  . . . . . . . . . . . . . .  35  33
     7.1.  Key Authorizations  . . . . . . . . . . . . . . . . . . .  37  35
     7.2.  HTTP  . . . . . . . . . . . . . . . . . . . . . . . . . .  38  35
     7.3.  TLS with Server Name Indication (TLS SNI) . . . . . . . .  40  38
     7.4.  Proof of Possession of a Prior Key  . . . . . . . . . . .  42
     7.5.  DNS . . . . . . . . . . . . . . . . . . . . . . . . . . .  44  39
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  46  41
   9.  Security Considerations  Well-Known URI for the HTTP Challenge . . . . . . . . . . . .  41
     9.1.  Replay-Nonce HTTP Header  . . . . . . .  46
     9.1.  Threat model . . . . . . . . .  41
     9.2.  "nonce" JWS Header Parameter  . . . . . . . . . . . . .  46
     9.2.  Integrity of Authorizations .  41
     9.3.  URN Sub-namespace for ACME (urn:ietf:params:acme) . . . .  42
     9.4.  New Registries  . . . . . . . . . .  47
     9.3.  Preventing Authorization Hijacking . . . . . . . . . . .  50
     9.4.  Denial-of-Service Considerations  42
       9.4.1.  Error Codes . . . . . . . . . . . .  52
     9.5.  CA Policy Considerations . . . . . . . . .  42
       9.4.2.  Identifier Types  . . . . . . .  52
   10. Acknowledgements . . . . . . . . . . .  43
       9.4.3.  Challenge Types . . . . . . . . . . .  53
   11. References . . . . . . . .  43
   10. Security Considerations . . . . . . . . . . . . . . . . .  53
     11.1.  Normative References . .  44
     10.1.  Threat model . . . . . . . . . . . . . . . .  53
     11.2.  Informative References . . . . . .  44
     10.2.  Integrity of Authorizations  . . . . . . . . . . .  55 . . .  45
     10.3.  Denial-of-Service Considerations . . . . . . . . . . . .  48
     10.4.  CA Policy Considerations . . . . . . . . . . . . . . . .  49
   11. Operational Considerations  . . . . . . . . . . . . . . . . .  49
     11.1.  Default Virtual Hosts  . . . . . . . . . . . . . . . . .  49
     11.2.  Use of DNSSEC Resolvers  . . . . . . . . . . . . . . . .  50
   12. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  50
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  51
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  51
     13.2.  Informative References . . . . . . . . . . . . . . . . .  53
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  56  54

1.  Introduction

   Certificates in the Web PKI [RFC5280] are most commonly used to
   authenticate domain names.  Thus, certificate authorities in the Web
   PKI are trusted to verify that an applicant for a certificate
   legitimately represents the domain name(s) in the certificate.

   Existing Web PKI certificate authorities tend to run on a set of ad
   hoc protocols for certificate issuance and identity verification.  A
   typical user experience is something like:

   o  Generate a PKCS#10 [RFC2314] Certificate Signing Request (CSR).

   o  Cut-and-paste the CSR into a CA web page.

   o  Prove ownership of the domain by one of the following methods:

      *  Put a CA-provided challenge at a specific place on the web
         server.

      *  Put a CA-provided challenge at a DNS location corresponding to
         the target domain.

      *  Receive CA challenge at a (hopefully) administrator-controlled
         e-mail address corresponding to the domain and then respond to
         it on the CA's web page.

   o  Download the issued certificate and install it on their Web
      Server.

   With the exception of the CSR itself and the certificates that are
   issued, these are all completely ad hoc procedures and are
   accomplished by getting the human user to follow interactive natural-
   language instructions from the CA rather than by machine-implemented
   published protocols.  In many cases, the instructions are difficult
   to follow and cause significant confusion.  Informal usability tests
   by the authors indicate that webmasters often need 1-3 hours to
   obtain and install a certificate for a domain.  Even in the best
   case, the lack of published, standardized mechanisms presents an
   obstacle to the wide deployment of HTTPS and other PKIX-dependent
   systems because it inhibits mechanization of tasks related to
   certificate issuance, deployment, and revocation.

   This document describes an extensible framework for automating the
   issuance and domain validation procedure, thereby allowing servers
   and infrastructural software to obtain certificates without user
   interaction.  Use of this protocol should radically simplify the
   deployment of HTTPS and the practicality of PKIX authentication for
   other protocols based on TLS [RFC5246].

2.  Deployment Model and Operator Experience

   The major guiding use case for ACME is obtaining certificates for Web
   sites (HTTPS [RFC2818]).  In that case, the server is intended to
   speak for one or more domains, and the process of certificate
   issuance is intended to verify that the server actually speaks for
   the domain. domain(s).

   Different types of certificates reflect different kinds of CA
   verification of information about the certificate subject.  "Domain
   Validation" (DV) certificates are by far the most common type.  For
   DV validation, the CA merely verifies that the requester has
   effective control of the web server and/or DNS server for the domain,
   but does not explicitly attempt to verify their real-world identity.
   (This is as opposed to "Organization Validation" (OV) and "Extended
   Validation" (EV) certificates, where the process is intended to also
   verify the real-world identity of the requester.)
   DV certificate validation commonly checks claims about properties
   related to control of a domain name - properties that can be observed
   by the issuing authority in an interactive process that can be
   conducted purely online.  That means that under typical
   circumstances, all steps in the request, verification, and issuance
   process can be represented and performed by Internet protocols with
   no out-of-band human intervention.

   When an operator deploys deploying a current HTTPS server, it an operator generally prompts
   him gets a
   prompt to generate a self-signed certificate.  When an operator
   deploys an ACME-compatible web server, the experience would be
   something like this:

   o  The ACME client prompts the operator for the intended domain
      name(s) that the web server is to stand for.

   o  The ACME client presents the operator with a list of CAs from
      which it could get a certificate.  (This list will change over
      time based on the capabilities of CAs and updates to ACME
      configuration.)  The ACME client might prompt the operator for
      payment information at this point.

   o  The operator selects a CA.

   o  In the background, the ACME client contacts the CA and requests
      that a certificate be issued for the intended domain name(s).

   o  Once the CA is satisfied, the certificate is issued and the ACME
      client automatically downloads and installs it, potentially
      notifying the operator via e-mail, SMS, etc.

   o  The ACME client periodically contacts the CA to get updated
      certificates, stapled OCSP responses, or whatever else would be
      required to keep the server functional and its credentials up-to-
      date.

   The overall idea is that it's nearly as easy to deploy with a CA-
   issued certificate as a self-signed certificate, and that once the
   operator has done so, the process is self-sustaining with minimal
   manual intervention.  Close integration of ACME with HTTPS servers,
   for example, can allow the immediate and automated deployment of
   certificates as they are issued, optionally sparing the human
   administrator from additional configuration work.

3.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   The two main roles in ACME are "client" and "server".  The ACME
   client uses the protocol to request certificate management actions,
   such as issuance or revocation.  An ACME client therefore typically
   runs on a web server, mail server, or some other server system which
   requires valid TLS certificates.  The ACME server runs at a
   certificate authority, and responds to client requests, performing
   the requested actions if the client is authorized.

   For simplicity, in all HTTPS transactions used by ACME, the

   An ACME client is the HTTPS represented by an "account key pair".  The client and
   uses the ACME server is private key of this key pair to sign all messages sent to
   the HTTPS server.

   In  The server uses the discussion below, we will refer to three different types of
   keys / key pairs:

   Subject Public Key:  A public key to be included in a certificate.

   Account Key Pair:  A key pair for which the ACME server considers the
      holder of the private key authorized to manage certificates for a
      given identifier.  The same key pair may be authorized for
      multiple identifiers.

   Recovery Key:  A MAC key that a client can use to demonstrate that it
      participated in a prior registration transaction.

   ACME messaging is based on HTTPS [RFC2818] and JSON [RFC7159].  Since
   JSON is a text-based format, binary fields are Base64-encoded.  For
   Base64 encoding, we use the variant defined in [RFC7515].  The
   important features of this encoding are (1) that it uses verify the URL-safe
   character set, and (2) that "=" padding characters are stripped.

   Some HTTPS bodies in ACME are authenticated
   authenticity and integrity-protected
   by being encapsulated in a JSON Web Signature (JWS) object [RFC7515].
   ACME uses a profile integrity of JWS, with the following restrictions:

   o  The JWS MUST use the Flattened JSON Serialization

   o  The JWS MUST be encoded using UTF-8

   o  The JWS Header or Protected Header MUST include "alg" and "jwk"
      fields

   o  The JWS MUST NOT have the value "none" in its "alg" field

   Additionally, JWS objects used in ACME MUST include messages from the "nonce"
   header parameter, defined below. client.

4.  Protocol Overview

   ACME allows a client to request certificate management actions using
   a set of JSON messages carried over HTTPS.  In some ways, ACME
   functions much like a traditional CA, in which a user creates an
   account, adds identifiers to that account (proving control of the
   domains), and requests certificate issuance for those domains while
   logged in to the account.

   In ACME, the account is represented by an account key pair.  The "add
   a domain" function is accomplished by authorizing the key pair for a
   given domain.  Certificate issuance and revocation are authorized by
   a signature with the key pair.

   The first phase of ACME is for the client to register with the ACME
   server.  The client generates an asymmetric key pair and associates
   this key pair with a set of contact information by signing the
   contact information.  The server acknowledges the registration by
   replying with a registration object echoing the client's input.

         Client                                                  Server

         Contact Information
         Signature                     ------->

                                       <-------            Registration

   Before a client can issue certificates, it must establish an
   authorization with the server for an account key pair to act for the
   identifier(s) that it wishes to include in the certificate.  To do
   this, the client must demonstrate to the server both (1) that it
   holds the private key of the account key pair, and (2) that it has
   authority over the identifier being claimed.

   Proof of possession of the account key is built into the ACME
   protocol.  All messages from the client to the server are signed by
   the client, and the server verifies them using the public key of the
   account key pair.

   To verify that the client controls the identifier being claimed, the
   server issues the client a set of challenges.  Because there are many
   different ways to validate possession of different types of
   identifiers, the server will choose from an extensible set of
   challenges that are appropriate for the identifier being claimed.
   The client responds with a set of responses that tell the server
   which challenges the client has completed.  The server then validates
   the challenges to check that the client has accomplished the
   challenge.

   For example, if the client requests a domain name, the server might
   challenge the client to provision a record in the DNS under that
   name, or to provision a file on a web server referenced by an A or
   AAAA record under that name.  The server would then query the DNS for
   the record in question, or send an HTTP request for the file.  If the
   client provisioned the DNS or the web server as expected, then the
   server considers the client authorized for the domain name.

         Client                                                  Server

         Identifier
         Signature                     ------->

                                       <-------              Challenges

         Responses
         Signature                     ------->

                                       <-------       Updated Challenge

                             <~~~~~~~~Validation~~~~~~~~>

         Poll                          ------->

                                       <-------           Authorization

   Once the client has authorized an account key pair for an identifier,
   it can use the key pair to authorize the issuance of certificates for
   the identifier.  To do this, the client sends a PKCS#10 Certificate
   Signing Request (CSR) to the server (indicating the identifier(s) to
   be included in the issued certificate) and a signature over the CSR
   by the private key of the account key pair.

   Note that as a result, the CSR is signed twice: One by the private
   key corresponding to the public key in the CSR, and once by the
   private key of the account key pair.  The former signature indicates
   that the holder of the key in the CSR is willing to act for the
   indicated identifiers, and the latter signature indicates to the
   server that the issuance of the certificate is authorized by the
   client (i.e., the domain holder).

   If the server agrees to issue the certificate, then it creates the
   certificate and provides it in its response.  The certificate is
   assigned a URI, which the client can use to fetch updated versions of
   the certificate.

         Client                                                 Server

         CSR
         Signature                    -------->

                                      <--------            Certificate

   To revoke a certificate, the client simply sends a revocation
   request, request
   indicating the certificate to be revoked, signed with an authorized
   key pair, and the pair.  The server indicates whether the request has succeeded.

         Client                                                 Server

         Revocation request
         Signature                    -------->

                                      <--------                 Result

   Note that while ACME is defined with enough flexibility to handle
   different types of identifiers in principle, the primary use case
   addressed by this document is the case where domain names are used as
   identifiers.  For example, all of the identifier validation
   challenges described in Section 7 below address validation of domain
   names.  The use of ACME for other protocols will require further
   specification, in order to describe how these identifiers are encoded
   in the protocol, and what types of validation challenges the server
   might require.

5.  Protocol Elements

   This section describes several components that are used by ACME,  Message Transport

   ACME uses a combination of HTTPS and
   general rules that apply JWS to create a messaging layer
   with a few important security properties.

   Communications between an ACME client and an ACME transactions. server are done
   over HTTPS, using JWS to provide som additional security properties
   for messages sent from the client to the server.  HTTPS provides
   server authentication and confidentiality.  With some ACME-specific
   extensions, JWS provides authentication of the client's request
   payloads, anti-replay protection, and a degree of integrity for the
   HTTPS request URI.

5.1.  HTTPS Requests

   Each ACME function is accomplished by the client sending a sequence
   of HTTPS requests to the server, carrying JSON messages. messages
   [RFC2818][RFC7159].  Use of HTTPS is REQUIRED.  Clients SHOULD
   support HTTP public key pinning [RFC7469], and servers SHOULD emit
   pinning headers.  Each subsection of Section 6 below describes the
   message formats used by the function, and the order in which messages
   are sent.

   In all HTTPS transactions used by ACME, the ACME client is the HTTPS
   client and the ACME server is the HTTPS server.

   ACME servers that are intended to be generally accessible need to use
   Cross-Origin Resource Sharing (CORS) in order to be accessible from
   browser-based clients [W3C.CR-cors-20130129].  Such servers SHOULD
   set the Access-Control-Allow-Origin header field to the value "*".

   Binary fields in the JSON objects used by ACME are encoded using
   base64url encoding described in [RFC4648] Section 5, according to the
   profile specified in JSON Web Signature [RFC7515] Section 2.  This
   encoding uses a URL safe character set.  Trailing '=' characters MUST
   be stripped.

5.2.  Request Authentication

   All ACME requests with a non-empty body MUST encapsulate the body in
   a JWS object, signed using the account key pair.  The server MUST
   verify the JWS before processing the request.  (For readability,
   however, the examples below omit this encapsulation.)  Encapsulating
   request bodies in JWS provides a simple authentication of requests by
   way of key continuity.

   JWS objects sent in ACME requests MUST meet the following additional
   criteria:

   o  The JWS MUST use the Flattened JSON Serialization

   o  The JWS MUST be encoded using UTF-8

   o  The JWS Header or Protected Header MUST include "alg" and "jwk"
      fields

   o  The JWS MUST NOT have the value "none" in its "alg" field

   o  The JWS Protected Header MUST include the "nonce" field (defined
      below)

   Note that this implies that GET requests are not authenticated.
   Servers MUST NOT respond to GET requests for resources that might be
   considered sensitive.

   An ACME request carries a JSON dictionary that provides the details
   of

5.3.  Request URI Type Integrity

   It is common in deployment the client's request entity terminating TLS for HTTPS to be
   different from the server.  In order to avoid attacks
   that entity operating the logical HTTPS server, with a
   "request routing" layer in the middle.  For example, an ACME CA might arise
   have a content delivery network terminate TLS connections from sending
   clients so that it can inspect client requests for denial-of-service
   protection.

   These intermediaries can also change values in the request that are
   not signed in the HTTPS request, e.g., the request URI and headers.
   ACME uses JWS to provides a limited integrity mechanism, which
   protects against an intermediary changing the request object URI to anothe
   ACME URI of a resource different type.  (It does not protect against changing
   between URIs of the
   wrong same type, each e.g., from one authorization URI to
   another).

   An ACME request carries a JSON dictionary that provides the details
   of the client's request to the server.  Each request object MUST have
   a "resource" field that indicates what type of resource the request
   is addressed to, as defined in the below table:

                +----------------------+------------------+

                 +--------------------+------------------+
                 | Resource type      | "resource" value |
                +----------------------+------------------+
                 +--------------------+------------------+
                 | New registration   | new-reg          |
                 |                    |                  |
                 | Recover registration | recover-reg      |
                |                      |                  |
                | New authorization  | new-authz        |
                 |                    |                  |
                 | New certificate    | new-cert         |
                 |                    |                  |
                 | Revoke certificate | revoke-cert      |
                 |                    |                  |
                 | Registration       | reg              |
                 |                    |                  |
                 | Authorization      | authz            |
                 |                    |                  |
                 | Challenge          | challenge        |
                 |                    |                  |
                 | Certificate        | cert             |
                +----------------------+------------------+
                 +--------------------+------------------+

   Other fields in ACME request bodies are described below.

   ACME servers that are intended to be generally accessible need to use
   Cross-Origin Resource Sharing (CORS) in

5.4.  Replay protection

   In order to be accessible protect ACME resources from
   browser-based clients [W3C.CR-cors-20130129].  Such servers SHOULD
   set any possible replay attacks,
   ACME requests have a mandatory anti-replay mechanism.  This mechanism
   is based on the Access-Control-Allow-Origin header field server maintaining a list of nonces that it has
   issued to clients, and requiring any signed request from the value "*".

5.2.  Registration Objects client
   to carry such a nonce.

   An ACME registration resource represents server MUST include a set of metadata associated Replay-Nonce header field in each
   successful response it provides to an account key pair.  Registration resources have the following
   structure:

   key (required, dictionary):  The public key of the account key pair,
      encoded as a JSON Web Key object [RFC7517].

   contact (optional, array of string):  An array of URIs that a client, with contents as
   specified below.  In particular, the ACME server can use MUST provide a
   Replay-Nonce header field in response to contact the client a HEAD request for issues related to this
      authorization.  For example, the server may wish to notify the
      client about server-initiated revocation.

   agreement (optional, string):  A URI referring any valid
   resource.  (This allows clients to easily obtain a subscriber
      agreement or terms of service provided fresh nonce.)  It
   MAY also provide nonces in error responses.

   Every JWS sent by an ACME client MUST include, in its protected
   header, the server (see below).
      Including this field indicates the client's agreement "nonce" header parameter, with the
      referenced terms.

   authorizations (optional, string):  A URI from which a list of
      authorizations granted to this account can be fetched via a GET
      request.  The result contents as defined below.
   As part of JWS verification, the GET request ACME server MUST be a JSON object
      whose "authorizations" field is an array verify that the
   value of strings, where each
      string the "nonce" header is a value that the URI of an authorization belonging to this
      registration.  The server SHOULD include pending authorizations,
      and SHOULD NOT include authorizations that are invalid or expired.

   certificates (optional, string):  A URI from which previously
   provided in a list of
      certificates issued for this account can be fetched via Replay-Nonce header field.  Once a GET
      request.  The result of nonce value has
   appeared in an ACME request, the GET request server MUST be a JSON object
      whose "certificates" field is an array of strings, where each
      string is consider it invalid, in
   the URI of same way as a value it had never issued.

   When a certificate.  The server rejects a request because its nonce value was
   unacceptable (or not present), it SHOULD NOT include
      expired certificates.

   {
     "resource": "new-reg",
     "contact": [
       "mailto:cert-admin@example.com",
       "tel:+12025551212"
     ],
     "agreement": "https://example.com/acme/terms",
     "authorizations": "https://example.com/acme/reg/1/authz",
     "certificates": "https://example.com/acme/reg/1/cert",
   }

5.3.  Authorization Objects

   An ACME authorization object represents server's authorization for an
   account to represent an identifier.  In addition to the identifier,
   an authorization includes several metadata fields, such as the provide HTTP status
   of the authorization (e.g., "pending", "valid", or "revoked") code 400
   (Bad Request), and
   which challenges were used to validate possession of indicate the identifier.

   The structure of an ACME authorization resource is as follows:

   identifier (required, dictionary of string): error code
   "urn:ietf:params:acme:error:badNonce".

   The identifier that the
      account precise method used to generate and track nonces is authorized up to represent

      type (required, string):  The type of identifier. the
   server.  For example, the server could generate a random 128-bit
   value (required, string):  The identifier itself.

   status (optional, string):  The status for each response, keep a list of this authorization.
      Possible values are: "unknown", "pending", "processing", "valid",
      "invalid" issued nonces, and "revoked".  If strike
   nonces from this list as they are used.

5.4.1.  Replay-Nonce

   The "Replay-Nonce" header field is missing, then the
      default includes a server-generated value is "pending".

   expires (optional, string):  The date after which
   that the server will
      consider this authorization invalid, encoded in the format
      specified can use to detect unauthorized replay in RFC 3339 [RFC3339].

   challenges (required, array): future
   client requests.  The challenges that server should generate the client needs
      to fulfill value provided in order
   Replay-Nonce in such a way that they are unique to prove possession each message, with
   high probability.

   The value of the identifier (for
      pending authorizations).  For final authorizations, the challenges
      that were used.  Each array entry is a dictionary with parameters
      required Replay-Nonce field MUST be an octet string encoded
   according to validate the challenge, as specified base64url encoding described in Section 7.

   combinations (optional, array of arrays of integers):  A collection
      of sets of challenges, each of which would be sufficient to prove
      possession 2 of the identifier.
   [RFC7515].  Clients complete MUST ignore invalid Replay-Nonce values.

     base64url = [A-Z] / [a-z] / [0-9] / "-" / "_"

     Replay-Nonce = *base64url

   The Replay-Nonce header field SHOULD NOT be included in HTTP request
   messages.

5.4.2.  "nonce" (Nonce) JWS header parameter

   The "nonce" header parameter provides a set of
      challenges that unique value that covers at least one set in this array.
      Challenges are identified by their indices in enables the challenges
      array.  If no "combinations" element is included
   verifier of a JWS to recognize when replay has occurred.  The "nonce"
   header parameter MUST be carried in an
      authorization object, the client completes all challenges.

   The only type protected header of identifier defined by this specification is a fully-
   qualified domain name (type: "dns"). the JWS.

   The value of the identifier "nonce" header parameter MUST be an octet string,
   encoded according to the ASCII representation base64url encoding described in Section 2 of
   [RFC7515].  If the domain name.  Wildcard domain
   names (with "*" as value of a "nonce" header parameter is not valid
   according to this encoding, then the first label) verifier MUST NOT be included in
   authorization requests.  See Section 6.6 below for more information
   about wildcard domains.

   {
     "status": "valid",
     "expires": "2015-03-01",

     "identifier": {
       "type": "dns",
       "value": "example.org"
     },

     "challenges": [
       {
         "type": "http-01",
         "status": "valid",
         "validated": "2014-12-01T12:05Z",
         "keyAuthorization": "SXQe-2XODaDxNR...vb29HhjjLPSggwiE"
       }
     ],
   }

5.4. reject the JWS as
   malformed.

5.5.  Errors

   Errors can be reported in ACME both at the HTTP layer and within ACME
   payloads.  ACME servers can return responses with an HTTP error
   response code (4XX or 5XX).  For example: If the client submits a
   request using a method not allowed in this document, then the server
   MAY return status code 405 (Method Not Allowed).

   When the server responds with an error status, it SHOULD provide
   additional information using problem document
   [I-D.ietf-appsawg-http-problem].  The "type" and "detail" fields MUST
   be populated.  To facilitate automatic response to
   errors, this document defines the following standard tokens for use
   in the "type" field (within the "urn:acme:" "urn:ietf:params:acme:error:"
   namespace):

   +----------------+--------------------------------------------------+
   | Code           | Semantic Description                                      |
   +----------------+--------------------------------------------------+
   | badCSR         | The CSR is unacceptable (e.g., due to a short    |
   |                | key)                                             |
   |                |                                                  |
   | badNonce       | The client sent an unacceptable anti-replay      |
   |                | nonce                                            |
   |                |                                                  |
   | connection     | The server could not connect to the client for   |
   |                | DV validation                                       |
   |                |                                                  |
   | dnssec         | The server could not validate a DNSSEC signed    |
   |                | domain                                           |
   |                |                                                  |
   | malformed      | The request message was malformed                |
   |                |                                                  |
   | serverInternal | The server experienced an internal error         |
   |                |                                                  |
   | tls            | The server experienced a TLS error during DV        |
   |                | validation                                       |
   |                |                                                  |
   | unauthorized   | The client lacks sufficient authorization        |
   |                |                                                  |
   | unknownHost    | The server could not resolve a domain name       |
   |                |                                                  |
   | rateLimited    | The request exceeds a rate limit                 |
   |                |                                                  |
   | invalidContact | The provided contact URI for a registration was  |
   |                | invalid                                          |
   +----------------+--------------------------------------------------+

   This list is not exhaustive.  The server MAY return errors whose
   "type" field is set to a URI other than those defined above.  Servers
   MUST NOT use the ACME URN namespace for errors other than the
   standard types.  Clients SHOULD display the "detail" field of such
   errors.

   Authorization and challenge objects can also contain error
   information to indicate why the server was unable to validate
   authorization.

   TODO: Flesh out errors and syntax for them

5.5.  Replay protection

6.  Certificate Management

   In order to protect this section, we describe the certificate management functions
   that ACME resources from any possible replay attacks, enables:

   o  Account Key Registration

   o  Account Key Authorization

   o  Certificate Issuance

   o  Certificate Renewal

   o  Certificate Revocation

6.1.  Resources

   ACME requests have a mandatory anti-replay mechanism.  This mechanism is based on the server maintaining structured as a list REST application with a few types of nonces that it has
   issued to clients, and requiring any signed request from the client
   resources:

   o  Registration resources, representing information about an account

   o  Authorization resources, representing an account's authorization
      to carry such a nonce.

   An ACME server MUST include act for an identifier

   o  Challenge resources, representing a Replay-Nonce header field in each
   successful response it provides challenge to a client, with contents as
   specified below.  In particular, prove control of
      an identifier

   o  Certificate resources, representing issued certificates

   o  A "directory" resource

   o  A "new-registration" resource

   o  A "new-authorization" resource

   o  A "new-certificate" resource

   o  A "revoke-certificate" resource

   For the "new-X" resources above, the ACME server MUST have exactly one
   resource for each function.  This resource may be addressed by
   multiple URIs, but all must provide a
   Replay-Nonce header field equivalent functionality.

   ACME uses different URIs for different management functions.  Each
   function is listed in response to a HEAD request for any valid
   resource.  (This allows directory along with its corresponding URI,
   so clients only need to easily obtain be configured with the directory URI.  These
   URIs are connected by a fresh nonce.) few different link relations [RFC5988].

   The "up" link relation is used with challenge resources to indicate
   the authorization resource to which a challenge belongs.  It
   MAY is also provide nonces in error responses.

   Every JWS sent by an ACME client MUST include, in its protected
   header,
   used from certificate resources to indicate a resource from which the "nonce" header parameter, with contents as defined below.
   As part
   client may fetch a chain of JWS verification, the ACME server MUST verify CA certificates that could be used to
   validate the
   value of certificate in the "nonce" header original resource.

   The "directory" link relation is a value that present on all resources other than
   the server previously
   provided in a Replay-Nonce header field.  Once a nonce value has
   appeared in directory and indicates the directory URL.

   The following diagram illustrates the relations between resources on
   an ACME request, server.  The solid lines indicate link relations, and the server MUST consider it invalid,
   dotted lines correspond to relationships expressed in other ways,
   e.g., the same way as Location header in a value it had never issued.

   When 201 (Created) response.

                                  directory
                                      .
                                      .
          ....................................................
          .                  .                  .            .
          .                  .                  .            .
          V     "next"       V      "next"      V            V
       new-reg ---+----> new-authz ---+----> new-cert    revoke-cert
          .       |          .        |         .            ^
          .       |          .        |         .            | "revoke"
          V       |          V        |         V            |
         reg* ----+        authz -----+       cert-----------+
                            . ^                 |
                            . | "up"            | "up"
                            V |                 V
                          challenge         cert-chain

   The following table illustrates a server rejects typical sequence of requests
   required to establish a request because its nonce value was
   unacceptable (or not present), it SHOULD provide HTTP status code 400
   (Bad Request), and indicate new account with the ACME error code "urn:acme:badNonce".

   The precise method used to generate server, prove control of
   an identifier, issue a certificate, and track nonces fetch an updated certificate
   some time after issuance.  The "->" is up to the
   server.  For example, the server could generate a random 128-bit
   value mnemonic for each response, keep a list of issued nonces, and strike
   nonces from this list as they are used.

5.5.1.  Replay-Nonce

   The "Replay-Nonce" Location
   header field includes a server-generated value
   that the server can use pointing to detect unauthorized replay in future
   client requests.  The server should generate the value provided in
   Replay-Nonce in such a way that they are unique to each message, with
   high probability.

   The value of the Replay-Nonce field MUST be an octet string encoded
   according to the base64url encoding described in Section 2 of
   [RFC7515].  Clients MUST ignore invalid Replay-Nonce values.

     base64url = [A-Z] / [a-z] / [0-9] / "-" / "_"

     Replay-Nonce = *base64url

   The Replay-Nonce header field SHOULD NOT be included in HTTP request
   messages.

5.5.2.  "nonce" (Nonce) JWS header parameter

   The "nonce" header parameter provides a unique value that enables the
   verifier of a JWS to recognize when replay has occurred.  The "nonce"
   header parameter MUST be carried in the protected header of the JWS.

   The value of the "nonce" header parameter MUST be an octet string,
   encoded according to the base64url encoding described in Section 2 of
   [RFC7515].  If the value of a "nonce" header parameter is not valid
   according to this encoding, then the verifier MUST reject the JWS as
   malformed.

5.6.  Key Agreement

   Certain elements of the protocol will require the establishment of a
   shared secret between the client and the server, in such a way that
   an entity observing the ACME protocol cannot derive the secret.  In
   these cases, we use a simple ECDH key exchange, based on the system
   used by CMS [RFC5753]:

   o  Inputs:

      *  Client-generated key pair

      *  Server-generated key pair

      *  Length of the shared secret to be derived

      *  Label

   o  Perform the ECDH primitive operation to obtain Z (Section 3.3.1 of
      [SEC1])

   o  Select a hash algorithm according to the curve being used:

      *  For "P-256", use SHA-256

      *  For "P-384", use SHA-384

      *  For "P-521", use SHA-512

   o  Derive the shared secret value using the KDF in Section 3.6.1 of
      [SEC1] using Z and the selected hash algorithm, and with the UTF-8
      encoding of the label as the SharedInfo value

   In cases where the length of the derived secret is shorter than the
   output length of the chosen hash algorithm, the KDF referenced above
   reduces to a single hash invocation.  The shared secret is equal to
   the leftmost octets of the following:

   H( Z || 00000001 || label )

6.  Certificate Management

   In this section, we describe the certificate management functions
   that ACME enables:

   o  Account Key Registration

   o  Account Recovery

   o  Account Key Authorization

   o  Certificate Issuance

   o  Certificate Renewal

   o  Certificate Revocation

6.1.  Resources

   ACME is structured as a REST application with a few types of
   resources:

   o  Registration resources, representing information about an account

   o  Authorization resources, representing an account's authorization
      to act for an identifier

   o  Challenge resources, representing a challenge to prove control of
      an identifier

   o  Certificate resources, representing issued certificates

   o  A "directory" resource

   o  A "new-registration" resource

   o  A "new-authorization" resource

   o  A "new-certificate" resource

   o  A "revoke-certificate" resource
   For the "new-X" resources above, the server MUST have exactly one
   resource for each function.  This resource may be addressed by
   multiple URIs, but all must provide equivalent functionality.

   In general, the intent is for authorization and certificate resources
   to contain only public information, so that CAs may publish these
   resources to document what certificates have been issued and how they
   were authorized.  Non-public information, such as contact
   information, is stored in registration resources.

   ACME uses different URIs for different management functions.  Each
   function is listed in a directory along with its corresponding URI,
   so clients only need to be configured with the directory URI.

   The "up" link relation is used with challenge resources to indicate
   the authorization resource to which a challenge belongs.  It is also
   used from certificate resources to indicate a resource from which the
   client may fetch a chain of CA certificates that could be used to
   validate the certificate in the original resource.

   The following diagram illustrates the relations between resources on
   an ACME server.  The solid lines indicate link relations, and the
   dotted lines correspond to relationships expressed in other ways,
   e.g., the Location header in a 201 (Created) response.

                                  directory
                                      .
                                      .
          ....................................................
          .                  .                  .            .
          .                  .                  .            .
          V     "next"       V      "next"      V            V
       new-reg ---+----> new-authz ---+----> new-cert    revoke-cert
          .       |          .        |         .            ^
          .       |          .        |         .            | "revoke"
          V       |          V        |         V            |
         reg* ----+        authz -----+       cert-----------+
                            . ^                 |
                            . | "up"            | "up"
                            V |                 V
                          challenge         cert-chain

   The following table illustrates a typical sequence of requests
   required to establish a new account with the server, prove control of
   an identifier, issue a certificate, and fetch an updated certificate
   some time after issuance.  The "->" is a mnemonic for a Location
   header pointing to a created resource.

          +--------------------+----------------+--------------+
          | Action             | Request        | Response     |
          +--------------------+----------------+--------------+
          | Register           | POST new-reg   | 201 -> reg   |
          |                    |                |              |
          | Request challenges | POST new-authz | 201 -> authz |
          |                    |                |              |
          | Answer challenges  | POST challenge | 200          |
          |                    |                |              |
          | Poll for status    | GET  authz     | 200          |
          |                    |                |              |
          | Request issuance   | POST new-cert  | 201 -> cert  |
          |                    |                |              |
          | Check for new cert | GET  cert      | 200          |
          +--------------------+----------------+--------------+

   The remainder of this section provides the details of how these
   resources are structured and how the ACME protocol makes use of them.

6.2.  Directory

   In order to help clients configure themselves with the right URIs for
   each ACME operation, ACME servers provide a directory object.  This
   should be the root URL with which clients are configured.  It is a
   JSON dictionary, whose keys are the "resource" values listed in
   Section 5.1, and whose values are the URIs used to accomplish the
   corresponding function.

   Clients access the directory by sending a GET request to the
   directory URI.

   HTTP/1.1 200 OK
   Content-Type: application/json

   {
     "new-reg": "https://example.com/acme/new-reg",
     "recover-reg": "https://example.com/acme/recover-reg",
     "new-authz": "https://example.com/acme/new-authz",
     "new-cert": "https://example.com/acme/new-cert",
     "revoke-cert": "https://example.com/acme/revoke-cert"
   }

6.3.  Registration

   A client creates a new account with the server by sending a POST
   request to the server's new-registration URI.  The body of the
   request is a stub registration object containing only the "contact"
   field (along with the required "resource" field).

   POST /acme/new-registration HTTP/1.1
   Host: example.com

   {
     "resource": "new-reg",
     "contact": [
       "mailto:cert-admin@example.com",
       "tel:+12025551212"
     ],
   }
   /* Signed as JWS */

   The server MUST ignore any values provided in the "key",
   "authorizations", and "certificates" fields in registration bodies
   sent by the client, as well as any other fields that it does not
   recognize.  If new fields are specified in the future, the
   specification of those fields MUST describe whether they may be
   provided by the client.

   The server creates a registration object with the included contact
   information.  The "key" element of the registration is set to the
   public key used to verify the JWS (i.e., the "jwk" element of the JWS
   header).  The server returns this registration object in a 201
   (Created) response, with the registration URI in a Location header
   field.  The server MUST also indicate its new-authorization URI using
   the "next" link relation.

   If the server already has a registration object with the provided
   account key, then it MUST return a 409 (Conflict) response and
   provide the URI of that registration in a Location header field.
   This allows a client that has an account key but not the
   corresponding registration URI to recover the registration URI.

   If the server wishes to present the client with terms under which the
   ACME service is to be used, it MUST indicate the URI where such terms
   can be accessed in a Link header with link relation "terms-of-
   service".  As noted above, the client may indicate its agreement with
   these terms by updating its registration to include the "agreement"
   field, with the terms URI as its value.

   HTTP/1.1 201 Created
   Content-Type: application/json
   Location: https://example.com/acme/reg/asdf
   Link: <https://example.com/acme/new-authz>;rel="next"
   Link: <https://example.com/acme/recover-reg>;rel="recover"
   Link: <https://example.com/acme/terms>;rel="terms-of-service"

   {
     "key": { /* JWK from JWS header */ },

     "contact": [
       "mailto:cert-admin@example.com",
       "tel:+12025551212"
     ]
   }

   If the client wishes to update this information in the future, it
   sends a POST request with updated information to the registration
   URI.  The server MUST ignore any updates to the "key",
   "authorizations, or "certificates" fields, and MUST verify that the
   request is signed with the private key corresponding to the "key"
   field of the request before updating the registration.

   Servers SHOULD NOT respond to GET requests for registration resources
   as these requests are not authenticated.  If a client wishes to query
   the server for information about its account (e.g., to examine the
   "contact" or "certificates" fields), then it SHOULD do so by sending
   a POST request with an empty update.  That is, it should send a JWS
   whose payload is trivial ({"resource":"reg"}).  In this case the
   server reply MUST contain the same link headers sent for a new
   registration, to allow a client to retreive the "new-authorization"
   and "terms-of-service" URI

6.3.1.  Recovery Keys

   If the client wishes to establish a secret key with the server that
   it can use to recover this account later (a "recovery key"), then it
   must perform a simple key agreement protocol as part of the new-
   registration transaction.  The client and server perform an ECDH
   exchange through the new-registration transaction (using the
   technique in Section 5.6), and the result is the recovery key.

   To request a recovery key, the client includes a "recoveryKey" field
   in its new-registration request.  The value of this field is a JSON
   object.

   client (required, JWK):  The client's ECDH public key
   length (required, number):  The length of the derived secret, in
      octets.

   In the client's request, this object contains a JWK for a random ECDH
   public key generated by the client and the client-selected length
   value.  Clients need to choose length values that balance security
   and usability.  On the one hand, a longer secret makes it more
   difficult for an attacker to recover the secret when it is used for
   recovery (see Section 6.4.1).  On the other hand, clients may wish to
   make the recovery key short enough created resource.

          +--------------------+----------------+--------------+
          | Action             | Request        | Response     |
          +--------------------+----------------+--------------+
          | Register           | POST new-reg   | 201 -> reg   |
          |                    |                |              |
          | Request challenges | POST new-authz | 201 -> authz |
          |                    |                |              |
          | Answer challenges  | POST challenge | 200          |
          |                    |                |              |
          | Poll for a user to easily write it
   down. status    | GET  authz     | 200          |
          |                    |                |              |
          | Request issuance   | POST /acme/new-registration HTTP/1.1
   Host: example.com

   {
     "resource": "new-reg",
     "contact": [
       "mailto:cert-admin@example.com",
       "tel:+12025551212"
     ],
     "recoveryKey": {
       "client": { "kty": "EC", ... },
       "length": 128
     }
   }
   /* Signed as JWS */

   The server MUST validate that the elliptic curve ("crv") and length
   value chosen by the client are acceptable, and that it is otherwise
   willing to create a recovery key.  If not, then it MUST reject the
   new-registration request.

   If the server agrees to create a recovery key, then it generates its
   own random ECDH key pair and combines it with with the client's
   public key as described in Section 5.6 above, using the label
   "recovery".  The derived secret value is the recovery key.  The
   server then returns to the client the ECDH key that it generated.
   The server MUST generate a fresh key pair new-cert  | 201 -> cert  |
          |                    |                |              |
          | Check for every transaction.

   server (required, JWK): new cert | GET  cert      | 200          |
          +--------------------+----------------+--------------+

   The server's ECDH public key
   HTTP/1.1 201 Created
   Content-Type: application/json
   Location: https://example.com/acme/reg/asdf

   {
     "key": { /* JWK from JWS header */ },

     "contact": [
       "mailto:cert-admin@example.com",
       "tel:+12025551212"
     ],

     "recoveryKey": {
       "server": { "kty": "EC", ... }
     }
   }

   On receiving the server's response, remainder of this section provides the client can compute details of how these
   resources are structured and how the
   recovery ACME protocol makes use of them.

6.1.1.  Registration Objects

   An ACME registration resource represents a set of metadata associated
   to an account key by combining pair.  Registration resources have the server's following
   structure:

   key (required, dictionary):  The public key together with of the
   private account key corresponding pair,
      encoded as a JSON Web Key object [RFC7517].

   contact (optional, array of string):  An array of URIs that the
      server can use to contact the public key that it sent client for issues related to this
      authorization.  For example, the
   server.

   Clients server may refresh wish to notify the recovery key associated with
      client about server-initiated revocation.

   agreement (optional, string):  A URI referring to a registration subscriber
      agreement or terms of service provided by sending a POST request with a new recoveryKey object.  If the server agrees to refresh (see below).
      Including this field indicates the recovery key, then it responds in client's agreement with the
   same way as
      referenced terms.

   authorizations (required, string):  A URI from which a list of
      authorizations granted to this account can be fetched via a new registration GET
      request.  The result of the GET request that asks for a recovery
   key.

   POST /acme/reg/asdf HTTP/1.1
   Host: example.com

   {
     "resource": "reg",
     "recoveryKey": {
       "client": { "kty": "EC", ... }
     }
   }
   /* Signed as JWS */

6.4.  Account Recovery

   Once MUST be a client has created an account with JSON object
      whose "authorizations" field is an ACME server, it array of strings, where each
      string is
   possible that the private key for the account will be lost.  The
   recovery contacts included in the registration allows the client URI of an authorization belonging to
   recover from this situation, as long as it still has access to these
   contacts.

   By "recovery", we mean
      registration.  The server SHOULD include pending authorizations,
      and SHOULD NOT include authorizations that the information associated with are invalid or expired.
      The server MAY return an old
   account key is bound incomplete list, along with a Link header
      with link relation "next" indicating a URL to retrieve further
      entries.

   certificates (required, string):  A URI from which a new list of
      certificates issued for this account key.  When can be fetched via a recovery process
   succeeds, the server provides GET
      request.  The result of the client with GET request MUST be a new registration
   whose contents are the same as base registration JSON object - except for
   the "key" field, which
      whose "certificates" field is an array of strings, where each
      string is set to the new account key. URI of a certificate.  The server
   reassigns resources associated with the base registration to the new
   registration (e.g., authorizations and certificates). SHOULD NOT include
      expired or revoked certificates.  The server
   SHOULD delete the old registration resource after it has been used as MAY return an
      incomplete list, along with a Link header with link relation
      "next" indicating a base URL to retrieve further entries.

   {
     "resource": "new-reg",
     "contact": [
       "mailto:cert-admin@example.com",
       "tel:+12025551212"
     ],
     "agreement": "https://example.com/acme/terms",
     "authorizations": "https://example.com/acme/reg/1/authz",
     "certificates": "https://example.com/acme/reg/1/cert",
   }

6.1.2.  Authorization Objects

   An ACME authorization object represents server's authorization for recovery. an
   account to represent an identifier.  In addition to the recovery mechanisms defined by ACME, individual
   client implementations may also offer implementation-specific
   recovery mechanisms.  For example, if a client creates account keys
   deterministically from a seed value, then this seed could be used to
   recover the account key by re-generating it.  Or an implementation
   could escrow identifier,
   an encrypted copy authorization includes several metadata fields, such as the status
   of the account key with a cloud
   storage provider, authorization (e.g., "pending", "valid", or "revoked") and give the encryption key
   which challenges were used to validate possession of the user identifier.

   The structure of an ACME authorization resource is as a
   recovery value.

6.4.1.  MAC-Based Recovery

   With MAC-based recovery, the client proves to the server that it
   holds a secret value established in the initial registration
   transaction. follows:

   identifier (required, dictionary of string):  The client requests MAC-based recovery by sending a MAC
   over identifier that the new
      account key, using the recovery key from the initial
   registration.

   method is authorized to represent

      type (required, string):  The string "mac"

   base type of identifier.

      value (required, string):  The URI for the registration to be
      recovered.

   mac identifier itself.

   status (required, string):  A JSON-formatted JWS object using an HMAC
      algorithm, whose payload  The status of this authorization.
      Possible values are: "unknown", "pending", "processing", "valid",
      "invalid" and "revoked".  If this field is missing, then the JWK representation of
      default value is "pending".

   expires (optional, string):  The timestamp after which the public
      key of server
      will consider this authorization invalid, encoded in the new account key pair.

   POST /acme/recover-reg HTTP/1.1
   Host: example.com

   {
     "resource": "recover-reg",
     "method": "mac",
     "base": "https://example.com/acme/reg/asdf",
     "mac": {
       "header": { "alg": "HS256" },
       "payload": base64(JWK(newAccountKey)),
       "signature": "5wUrDI3eAaV4wl2Rfj3aC0Pp--XB3t4YYuNgacv_D3U"
     }
   }
   /* Signed as JWS, format
      specified in RFC 3339 [RFC3339].  This field is REQUIRED for
      objects with new account key */

   On receiving such a request "valid" in the server MUST verify that:

   o  The base registration has a recovery key associated with it

   o "status field.

   challenges (required, array):  The "alg" value challenges that the client needs
      to fulfill in order to prove possession of the "mac" JWS represents a MAC algorithm

   o  The "mac" JWS identifier (for
      pending authorizations).  For final authorizations, the challenges
      that were used.  Each array entry is valid according a dictionary with parameters
      required to validate the challenge, as specified in Section 7.

   combinations (optional, array of arrays of integers):  A collection
      of sets of challenges, each of which would be sufficient to prove
      possession of the validation rules identifier.  Clients complete a set of
      challenges that covers at least one set in
      [RFC7515], using the recovery key as the MAC key

   o  The JWK this array.  Challenges
      are identified by their indices in the payload represents the new account key (i.e. the
      key used to verify the ACME message) challenges array.  If those conditions are met, and the recovery request no
      "combinations" element is otherwise
   acceptable to the server, then included in an authorization object, the recovery process has succeeded.
      client completes all challenges.

   The server creates a new registration resource based on the base
   registration and the new account key, and returns it on a 201
   (Created) response, together with a Location header indicating only type of identifier defined by this specification is a URI
   for fully-
   qualified domain name (type: "dns").  The value of the new registration.  If identifier
   MUST be the recovery request is unsuccessful, ASCII representation of the server returns an error response, such domain name.  Wildcard domain
   names (with "*" as 403 (Forbidden).

   HTTP/1.1 201 Created
   Content-Type: application/json
   Location: https://example.com/acme/reg/asdf
   Link: <https://example.com/acme/new-authz>;rel="next"
   Link: <https://example.com/acme/recover-reg>;rel="recover"
   Link: <https://example.com/acme/terms>;rel="terms-of-service" the first label) MUST NOT be included in
   authorization requests.  See Section 6.5 below for more information
   about wildcard domains.

   {
     "key":
     "status": "valid",
     "expires": "2015-03-01T14:09:00Z",

     "identifier": { /* JWK from JWS header */
       "type": "dns",
       "value": "example.org"
     },

     "contact":

     "challenges": [
       "mailto:cert-admin@example.com",
       "tel:+12025551212"
       {
         "type": "http-01",
         "status": "valid",
         "validated": "2014-12-01T12:05:00Z",
         "keyAuthorization": "SXQe-2XODaDxNR...vb29HhjjLPSggwiE"
       }
     ],

     "authorizations": "...",
     "certificate": "..."
   }

6.4.2.  Contact-Based Recovery

6.2.  Directory

   In order to help clients configure themselves with the right URIs for
   each ACME operation, ACME servers provide a directory object.  This
   should be the only URL needed to configure clients.  It is a JSON
   dictionary, whose keys are the "resource" values listed in
   Section 5.1, and whose values are the contact-based recovery process, URIs used to accomplish the client requests
   corresponding function.

   There is no constraint on the actual URI of the directory except that
   it should be different from the other ACME server send resources' URIs,
   and that it should not clash with other services.  For instance:

   o  a message host which function as both an ACME and Web server may want to one of
      keep the contact URIs registered root path "/" for an HTML "front page", and and place the
   account.  That message indicates some action that the
      ACME directory under path "/acme".

   o  a host which only functions as an ACME server requires could place the client's user to perform, e.g., clicking
      directory under path "/".

   The dictionary MAY additionally contain a link key "meta".  If present, it
   MUST be a JSON dictionary; each item in the dictionary is an email.  If item of
   metadata relating to the user successfully completes service provided by the server's required actions, then ACME server.

   The following metadata items are defined, all of which are OPTIONAL:

   "terms-of-service" (optional, string):  A URI identifying the server will bind current
      terms of service.

   "website" (optional, string)):  An HTTP or HTTPS URL locating a
      website providing more information about the account ACME server.

   "caa-identities" (optional, array of string):  Each string MUST be a
      lowercase hostname which the ACME server recognises as referring
      to itself for the new account key.

   (Note that this process is almost entirely out purposes of band with respect
   to ACME.  ACME only CAA record validation as defined in
      [RFC6844].  This allows the client clients to initiate the process, and determine the server correct issuer
      domain name to indicate use when configuring CAA record.

   Clients access the result.)

   To initiate contact-based recovery, directory by sending a GET request to the
   directory URI.

   HTTP/1.1 200 OK
   Content-Type: application/json

   {
     "new-reg": "https://example.com/acme/new-reg",
     "new-authz": "https://example.com/acme/new-authz",
     "new-cert": "https://example.com/acme/new-cert",
     "revoke-cert": "https://example.com/acme/revoke-cert",
     "meta": {
       "terms-of-service": "https://example.com/acme/terms",
       "website": "https://www.example.com/",
       "caa-identities": ["example.com"]
     }
   }

6.3.  Registration

   A client sends creates a new account with the server by sending a POST
   request to the server's recover-registration URI, with a body specifying
   which registration is to be recovered. new-registration URI.  The body of the
   request MUST
   be signed by is a stub registration object containing only the client's new account key pair.

   method (required, string):  The string "contact"

   base (required, string):  The URI for
   field (along with the registration to be
      recovered. required "resource" field).

   POST /acme/recover-reg /acme/new-registration HTTP/1.1
   Host: example.com

   {
     "resource": "recover-reg",
     "method": "contact",
     "base": "https://example.com/acme/reg/asdf", "new-reg",
     "contact": [
       "mailto:forgetful@example.net"
     ]
       "mailto:cert-admin@example.com",
       "tel:+12025551212"
     ],
   }
   /* Signed as JWS, with new account key JWS */

   The server MUST ignore any values provided in the "key",
   "authorizations", and "certificates" fields in registration bodies
   sent by the client, as well as any other fields that it does not
   recognize.  If new fields are specified in the future, the
   specification of those fields MUST describe whether they may be
   provided by the client.

   The server agrees to attempt contact-based recovery, then it creates a new registration resource containing a stub registration
   object. object with the included contact
   information.  The stub "key" element of the registration has is set to the client's new account
   public key and
   contacts, but no authorizations or certificates associated. used to verify the JWS (i.e., the "jwk" element of the JWS
   header).  The server returns the stub contact this registration object in a 201
   (Created) response, along with a Location header field indicating the URI for the new
   registration resource (which will be the registration URI if the
   recovery succeeds).

   HTTP/1.1 201 Created
   Content-Type: application/json
   Location: https://example.com/acme/reg/qwer

   {
     "key": { /* new account key from JWS header */ },

     "contact": [
       "mailto:forgetful@example.net"
     ]
   }

   After recovery has been initiated, the server follows its chosen
   recovery process, out-of-band to ACME.  While the recovery process is
   ongoing, the client may poll the registration resource's URI for
   status, by sending a POST request with a trivial body
   ({"resource":"reg"}).  If the recovery process is still pending, the
   server sends a 202 (Accepted) status code, and in a Retry-After Location header
   field.  If the recovery process has failed, the  The server sends an error
   code (e.g., 404), and SHOULD delete also indicate its new-authorization URI
   using the stub registration resource. "next" link relation.

   If the recovery process has succeeded, then the server will send already has a
   200 (OK) response, containing the full registration object, object with any
   necessary information copied from the old registration).  The client
   may now use this in the same way as if he had gotten provided
   account key, then it from MUST return a new-
   registration transaction.

6.5.  Identifier Authorization

   The identifier authorization process establishes 409 (Conflict) response and
   provide the authorization URI of
   an account to manage certificates for that registration in a given identifier. Location header field.
   This
   process must assure the server of two things: First, allows a client that has an account key but not the client
   controls
   corresponding registration URI to recover the private key of registration URI.

   If the account key pair, and second, that server wishes to present the client holds with terms under which the identifier in question.  This process may be
   repeated to associate multiple identifiers
   ACME service is to be used, it MUST indicate the URI where such terms
   can be accessed in a key pair (e.g., to
   request certificates with multiple identifiers), or to associate
   multiple accounts Link header with an identifier (e.g., to allow multiple
   entities to manage certificates). link relation "terms-of-
   service".  As illustrated by noted above, the figure in client may indicate its agreement with
   these terms by updating its registration to include the overview section above, "agreement"
   field, with the
   authorization process proceeds terms URI as its value.  When these terms change in two phases.  The client first
   requests a new authorization, and
   way that requires an agreement update, the server issues challenges, then MUST use a
   different URI in the Link header.

   HTTP/1.1 201 Created
   Content-Type: application/json
   Location: https://example.com/acme/reg/asdf
   Link: <https://example.com/acme/new-authz>;rel="next"
   Link: <https://example.com/acme/terms>;rel="terms-of-service"
   Link: <https://example.com/acme/some-directory>;rel="directory"

   {
     "key": { /* JWK from JWS header */ },

     "contact": [
       "mailto:cert-admin@example.com",
       "tel:+12025551212"
     ]
   }

   If the client responds wishes to those challenges and the server validates the
   client's responses.

   To begin the key authorization process, update this information in the client future, it
   sends a POST request with updated information to the server's new-authorization resource.  The body of the
   POST request MUST contain a JWS object, whose payload is a partial
   authorization object.  This JWS object MUST contain only the
   "identifier" field, so that the server knows what identifier is being
   authorized. registration
   URI.  The server MUST ignore any other fields present in updates to the "key",
   "authorizations, or "certificates" fields, and MUST verify that the
   client's
   request object.

   The authorization object is implicitly tied to signed with the account private key used corresponding to sign the request.  Once created, "key"
   field of the authorization may only be
   updated by that account. request before updating the registration.

   For example, to update the contact information in the above
   registration, the client could send the following request:

   POST /acme/new-authorization /acme/reg/asdf HTTP/1.1
   Host: example.com

   {
     "resource": "new-authz",
     "identifier": {
       "type": "dns",
       "value": "example.org"
     } "reg",
     "contact": [
       "mailto:certificates@example.com",
       "tel:+12125551212"
     ],
   }
   /* Signed as JWS */

   Before processing the authorization further, the server

   Servers SHOULD
   determine whether it is willing NOT respond to issue certificates GET requests 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. registration resources
   as these requests are not authenticated.  If a client wishes to query
   the server is
   unwilling to issue for information about its account (e.g., to examine the identifier,
   "contact" or "certificates" fields), then it SHOULD return do so by sending
   a 403
   (Forbidden) error, POST request with a problem document describing the reason for
   the rejection.

   If the server is willing to proceed, an empty update.  That is, it builds should send a pending
   authorization object from the initial authorization object submitted
   by the client.

   o  "identifier" the identifier submitted by JWS
   whose payload is trivial ({"resource":"reg"}).  In this case the client.

   o  "status":
   server reply MUST be "pending"

   o  "challenges" and "combinations": As selected by contain the server's
      policy same link headers sent for this identifier

   o  The "expires" field MUST be absent.

   The server allocates a new URI for this authorization, and returns
   registration, to allow a
   201 (Created) response, with client to retrieve the authorization URI in a Location
   header field, "new-authorization"
   and the JSON authorization object in the body.

   HTTP/1.1 201 Created
   Content-Type: application/json
   Location: https://example.com/authz/asdf
   Link: <https://example.com/acme/new-cert>;rel="next"

   {
     "status": "pending",

     "identifier": {
       "type": "dns",
       "value": "example.org"
     },

     "challenges": [
       {
         "type": "http-01",
         "uri": "https://example.com/authz/asdf/0",
         "token": "IlirfxKKXAsHtmzK29Pj8A"
       },
       {
         "type": "dns-01",
         "uri": "https://example.com/authz/asdf/1",
         "token": "DGyRejmCefe7v4NfDGDKfA"
       }
     },

     "combinations": [
       [0, 2],
       [1, 2]
     ]
   }

   The "terms-of-service" URI

6.3.1.  Account Key Roll-over

   A client needs may wish to respond change the public key that is associated with information a
   registration, e.g., in order to complete mitigate the
   challenges. risk of key compromise.
   To do this, the client updates the authorization first constructs a JSON object
   received from representing a
   request to update the server by filling in any required information in registration:

   resource (required, string):  The string "reg", indicating an update
      to the elements registration.

   oldKey (required, string):  The JWK thumbprint of the "challenges" dictionary.  (This is also the stage
   where the old key
      [RFC7638], base64url-encoded

   {
     "resource": "reg",
     "oldKey": "D7J9RL1f-RWUl68JP-gW1KSl2TkIrJB7hK6rLFFeYMU"
   }

   The client should perform any actions required by signs this object with the
   challenge.) new key pair and encodes the
   object and signature as a JWS.  The client then sends these updates back this JWS to the
   server in the form "newKey" field of a
   JSON object with the response fields required by the challenge type,
   carried in a POST request to update the challenge URI (not authorization URI
   or the new-authorization URI).  This allows the client to send
   information only for challenges it is responding to.

   For example, if the client were to respond to the "http-01" challenge
   in the above authorization, it would send the following request: registration.

   POST /acme/authz/asdf/0 /acme/reg/asdf HTTP/1.1
   Host: example.com

   {
     "resource": "challenge",
     "type": "http-01",
     "token": "evaGxfADs6pSRb2LAv9IZf17Dt3juxGJ-PCt92wr-oA" "reg",
     "newKey": /* JSON object signed as JWS with new key */
   }
   /* Signed as JWS with original key */

   The server updates the authorization document by updating its
   representation of

   On receiving a request to the challenge registration URL with the response fields provided by "newKey"
   attribute set, the client.  The server MUST ignore any fields perform the following steps:

   1.  Check that the contents of the "newKey" attribute are a valid JWS

   2.  Check that the "newKey" JWS verifies using the key in the response "jwk"
       header parameter of the JWS

   3.  Check that the payload of the JWS is a valid JSON object

   4.  Check that are not specified as response fields the "resource" field of the object has the value "reg"

   5.  Check that the "oldKey" field of the object contains the JWK
       thumbprint of the account key for this type registration

   If all of these checks pass, then the server updates the registration
   by replacing the old account key with the public key carried in the
   "jwk" header parameter of challenge.
   The the "newKey" JWS object.

   If the update was successful, then the server provides sends a 200 (OK) response with
   status code 200 (OK) and the updated challenge registration object as its body.
   If the client's response is invalid for some reason, or does update was not
   provide the server with appropriate information to validate the
   challenge, successful, then the server MUST return responds with an HTTP
   error status code and a problem document describing the error.  On receiving
   such

6.3.2.  Deleting an error, the Account

   If a client MUST undo any actions that have been taken no longer wishes to fulfil the challenge, e.g., removing files that have been
   provisioned to a web server.

   Presumably, the client's responses provide the server an account key registered with enough
   information to validate one or more challenges.  The server is said
   to "finalize" the authorization when it has completed all
   the
   validations server, it is going to complete, and assigns may request that the authorization server delete its account by
   sending a
   status of "valid" or "invalid", corresponding POST request to whether it considers the account authorized for the identifier.  If the final state is
   "valid", URI containing the server "delete"
   field.

   delete (required, boolean): The boolean value "true".

   The request object MUST add an "expires" field to the authorization.
   When finalizing an authorization, the server MAY remove contain the
   "combinations" "resource" field (if present) or remove any challenges still
   pending.  The server SHOULD NOT remove challenges with status
   "invalid".

   Usually, the validation process will take some time, so as required
   above (with the client
   will need to poll value "reg").  It MUST NOT contain any fields besides
   "resource" and "delete".

   Note that although this object is very simple, the authorization resource to see when it risk of replay or
   fraudulent generation via signing oracles is
   finalized.  For challenges where mitigated by the client can tell when need
   for an anti-replay token in the server
   has validated protected header of the challenge (e.g., by seeing JWS.

   POST /acme/reg/asdf HTTP/1.1
   Host: example.com

   {
     "resource": "reg",
     "delete": true,
   }
   /* Signed as JWS */

   On receiving a POST to an HTTP or DNS request
   from account URI containing a "delete" field,
   the server), server MUST verify that no other fields were sent in the client SHOULD NOT begin polling until object
   (other than "resource"), and it has
   seen the validation request from the server.

   To check on MUST verify that the status value of an authorization, the client sends
   "delete" field is "true" (as a GET
   request to the authorization URI, and boolean, not a string).  If either of
   these checks fails, then the server responds with the
   current authorization object.  In responding to poll requests while MUST reject the validation is still in progress, request with
   status code 400 (Bad Request).

   If the server accepts the deletion request, then it MUST return delete the
   account and all related objects and send a 202
   (Accepted) response with a Retry-After header field.

   GET /acme/authz/asdf HTTP/1.1
   Host: example.com

   HTTP/1.1 200 OK

   {
     "status": "valid",
     "expires": "2015-03-01",

     "identifier": {
       "type": "dns",
       "value": "example.org"
     },

     "challenges": [
       {
         "type": "http-01"
         "status": "valid",
         "validated": "2014-12-01T12:05Z",
         "keyAuthorization": "SXQe-2XODaDxNR...vb29HhjjLPSggwiE"
       }
     ]
   }

6.6.  Certificate Issuance

   The holder of an authorized key pair for (OK)
   status code and an empty body.  The server SHOULD delete any
   authorization objects related to the deleted account, since they can
   no longer be used.  The server SHOULD NOT delete certificate objects
   related to the account, since certificates issued under the account
   continue to be valid until they expire or are revoked.

6.4.  Identifier Authorization

   The identifier may use ACME authorization process establishes the authorization of
   an account to request that a certificate be issued manage certificates for that identifier.  The
   client makes this request by sending a POST request to given identifier.  This
   process must assure the server's
   new-certificate resource.  The body server of two things: First, that the POST is a JWS object whose
   JSON payload contains a Certificate Signing Request (CSR) [RFC2986].
   The CSR encodes client
   controls the parameters private key of the requested certificate;
   authority to issue is demonstrated by the JWS signature by an account
   key, from which the server can look up related authorizations.

   csr (required, string):  A CSR encoding key pair, and second, that
   the parameters for client holds the
      certificate being requested.  The CSR is sent identifier in question.  This process may be
   repeated to associate multiple identifiers to a key pair (e.g., to
   request certificates with multiple identifiers), or to associate
   multiple accounts with an identifier (e.g., to allow multiple
   entities to manage certificates).

   As illustrated by the
      Base64-encoded version of figure in the DER format.  (Note: This field uses overview section above, the same modified Base64-encoding rules used elsewhere
   authorization process proceeds in this
      document, so it is different from PEM.)

   POST /acme/new-cert HTTP/1.1
   Host: example.com
   Accept: application/pkix-cert

   {
     "resource": "new-cert",
     "csr": "5jNudRx6Ye4HzKEqT5...FS6aKdZeGsysoCo4H9P",
   }
   /* Signed as JWS */ two phases.  The CSR encodes the client's client first
   requests with regard to a new authorization, and the content of server issues challenges, then
   the certificate client responds to be issued.  The CSR MUST indicate those challenges and the requested
   identifiers, either in server validates the commonName portion of
   client's responses.

   To begin the requested
   subject name, or in an extensionRequest attribute [RFC2985]
   requesting key authorization process, the client sends a subjectAltName extension. POST
   request to the server's new-authorization resource.  The values provided in body of the CSR are only
   POST request MUST contain a request, and are not
   guaranteed. JWS object, whose payload is a partial
   authorization object.  This JWS object MUST contain only the
   "identifier" field, so that the server knows what identifier is being
   authorized.  The server or CA may alter MUST ignore any other fields present in the certificate
   before issuance.  For example, the CA may remove identifiers that are
   not authorized for
   client's request object.

   The authorization object is implicitly tied to the account key that signed the request.

   It is up used
   to sign the server's local policy to decide which names are
   acceptable in a certificate, given request.  Once created, the authorizations authorization may only be
   updated by that account.

   POST /acme/new-authorization HTTP/1.1
   Host: example.com

   {
     "resource": "new-authz",
     "identifier": {
       "type": "dns",
       "value": "example.org"
     }
   }
   /* Signed as JWS */

   Before processing the server
   associates with authorization further, the client's account key.  A server MAY consider a
   client authorized for a wildcard domain if SHOULD
   determine whether it is authorized willing to issue certificates for the
   underlying domain name (without the "*" label).  Servers SHOULD NOT
   extend authorization across identifier types.
   identifier.  For example, if a
   client is authorized for "example.com", then the server should not
   allow check that the client 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 certificate 403
   (Forbidden) error, with an iPAddress
   subjectAltName, even if it contains an IP address to which
   example.com resolves. a problem document describing the reason for
   the rejection.

   If the CA decides server is willing to issue proceed, it builds a certificate, then pending
   authorization object from the initial authorization object submitted
   by the client.

   o  "identifier" the identifier submitted by the client

   o  "status": MUST be "pending" unless the server creates has out-of-band
      information about the client's authorization status

   o  "challenges" and "combinations": As selected by the server's
      policy for this identifier

   The server allocates a new certificate resource URI for this authorization, and returns a
   201 (Created) response, with the authorization URI for it in the a Location
   header field of a 201 (Created) response. field, and the JSON authorization object in the body.

   HTTP/1.1 201 Created
   Content-Type: application/json
   Location: https://example.com/acme/cert/asdf

   If https://example.com/authz/asdf
   Link: <https://example.com/acme/new-cert>;rel="next"
   Link: <https://example.com/acme/some-directory>;rel="directory"

   {
     "status": "pending",

     "identifier": {
       "type": "dns",
       "value": "example.org"
     },

     "challenges": [
       {
         "type": "http-01",
         "uri": "https://example.com/authz/asdf/0",
         "token": "IlirfxKKXAsHtmzK29Pj8A"
       },
       {
         "type": "dns-01",
         "uri": "https://example.com/authz/asdf/1",
         "token": "DGyRejmCefe7v4NfDGDKfA"
       }
     },

     "combinations": [[0], [1]]
   }

6.4.1.  Responding to Challenges

   To prove control of the certificate is available at identifer and receive authorization, the time of
   client needs to respond with information to complete the response, it is
   provided challenges.
   To do this, the client updates the authorization object received from
   the server by filling in any required information in the body elements of
   the response.  If "challenges" dictionary.  (This is also the CA has not yet issued stage where the certificate,
   client should perform any actions required by the body of this response will be empty. challenge.)

   The client
   should then send sends these updates back to the server in the form of a GET
   JSON object with the response fields required by the challenge type,
   carried in a POST request to the certificate challenge URI to poll for (not authorization URI
   or the
   certificate.  As long as new-authorization URI).  This allows the certificate client to send
   information only for challenges it is unavailable, responding to.

   For example, if the server
   MUST provide a 202 (Accepted) response and include a Retry-After
   header client were to respond to indicate when the server believes the certificate will be
   issued (as "http-01" challenge
   in the example above).

   GET /acme/cert/asdf above authorization, it would send the following request:

   POST /acme/authz/asdf/0 HTTP/1.1
   Host: example.com
   Accept: application/pkix-cert

   HTTP/1.1 202 Accepted
   Retry-After: 120

   {
     "resource": "challenge",
     "type": "http-01",
     "keyAuthorization": "IlirfxKKXA...vb29HhjjLPSggwiE"
   }
   /* Signed as JWS */

   The default format of server updates the certificate is DER (application/pkix-cert).
   The client may request other formats authorization document by including an Accept header in updating its request.
   representation of the challenge with the response fields provided by
   the client.  The server provides metadata about the certificate MUST ignore any fields in HTTP headers.
   In particular, the response object
   that are not specified as response fields for this type of challenge.
   The server MUST include provides a Link relation header field
   [RFC5988] 200 (OK) response with relation "up" to the updated challenge
   object as its body.

   If the client's response is invalid for some reason, or does not
   provide a certificate under which
   this certificate was issued, and one the server with relation "author" appropriate information to
   indicate validate the
   challenge, then the registration under which this certicate was issued.  The server MAY also include MUST return an Expires header as HTTP error.  On receiving
   such an error, the client SHOULD undo any actions that have been
   taken to fulfill the challenge, e.g., removing files that have been
   provisioned to a hint web server.

   Presumably, the client's responses provide the server with enough
   information to validate one or more challenges.  The server is said
   to "finalize" the client
   about authorization when to renew the certificate.  (Of course, the real expiration
   of it has completed all the certificate
   validations it is controlled by the notAfter time in the
   certificate itself.)

   GET /acme/cert/asdf HTTP/1.1
   Host: example.com
   Accept: application/pkix-cert

   HTTP/1.1 200 OK
   Content-Type: application/pkix-cert
   Link: <https://example.com/acme/ca-cert>;rel="up";title="issuer"
   Link: <https://example.com/acme/revoke-cert>;rel="revoke"
   Link: <https://example.com/acme/reg/asdf>;rel="author"
   Location: https://example.com/acme/cert/asdf
   Content-Location: https://example.com/acme/cert-seq/12345

   [DER-encoded certificate]

   A certificate resource always represents the most recent certificate
   issued for the name/key binding expressed in the CSR.  If going to complete, and assigns the CA
   allows authorization a certificate
   status of "valid" or "invalid", corresponding to be renewed, then whether it publishes renewed
   versions of considers
   the certificate through account authorized for the same certificate URI.

   Clients retrieve renewed versions of identifier.  If the certificate using a GET
   query final state is
   "valid", the server MUST add an "expires" field to the certificate URI, which authorization.
   When finalizing an authorization, the server should then return in
   a 200 (OK) response. MAY remove the
   "combinations" field (if present) or remove any challenges still
   pending.  The server SHOULD provide a stable URI for each
   specific certificate in NOT remove challenges with status
   "invalid".

   Usually, the Content-Location header field, as shown
   above.  Requests to stable certificate URIs MUST always result in validation process will take some time, so the
   same certificate.

   To avoid unnecessary renewals, client
   will need to poll the CA may choose not authorization resource to issue a
   renewed certificate see when it is
   finalized.  For challenges where the client can tell when the server
   has validated the challenge (e.g., by seeing an HTTP or DNS request
   from the server), the client SHOULD NOT begin polling until it receives such has
   seen the validation request from the server.

   To check on the status of an authorization, the client sends a GET
   request (if it even
   allows renewal at all).  In such cases, if to the CA requires some time authorization URI, and the server responds with the
   current authorization object.  In responding to generate poll requests while
   the new certificate, validation is still in progress, the CA server MUST return a 202
   (Accepted) response, with and MAY include a Retry-After header field that indicates when to
   suggest a polling interval to the new
   certificate will be available.  The CA MAY include client.

   GET /acme/authz/asdf HTTP/1.1
   Host: example.com

   HTTP/1.1 200 OK

   {
     "status": "valid",
     "expires": "2015-03-01T14:09:00Z",

     "identifier": {
       "type": "dns",
       "value": "example.org"
     },

     "challenges": [
       {
         "type": "http-01"
         "status": "valid",
         "validated": "2014-12-01T12:05:00Z",
         "token": "IlirfxKKXAsHtmzK29Pj8A",
         "keyAuthorization": "IlirfxKKXA...vb29HhjjLPSggwiE"
       }
     ]
   }

6.4.2.  Deleting an Authorization

   If a client wishes to relinquish its authorization to issue
   certificates for an identifier, then it may request that the current (non-
   renewed) certificate as server
   delete the body of authorization.  The client makes this request by sending a
   POST request to the response.

   Likewise, authorization URI containing a payload in order to prevent unnecessary renewal due to queries by
   parties other than the account key holder, certificate URIs should be
   structured
   same format as capability URLs [W3C.WD-capability-urls-20140218].

   From the client's perspective, there is no in Section 6.3.2.  The only difference between a
   certificate URI that allows renewal and one is that does not.  If the
   client wishes to obtain a renewed certificate,
   value of the "resource" field is "authz".

   POST /acme/authz/asdf HTTP/1.1
   Host: example.com

   {
     "resource": "authz",
     "delete": true,
   }
   /* Signed as JWS */

   The server MUST perform the same validity checks as in Section 6.3.2
   and a GET reject the request to if they fail.  If the certificate URI does not yield one, then server deletes the client may initiate
   account then it MUST send a new-certificate transaction to request one.

6.7. response with a 200 (OK) status code and
   an empty body.

6.5.  Certificate Revocation

   To Issuance

   The holder of an account key pair authorized for one or more
   identifiers may use ACME to request that a certificate be revoked, the issued for
   any subset of those identifiers.  The client sends makes this request by
   sending a POST request to the ACME server's revoke-cert URI. new-certificate resource.  The
   body of the POST is a JWS object whose JSON payload contains a
   Certificate Signing Request (CSR) [RFC2986].  The CSR encodes the certificate
   parameters of the requested certificate; authority to issue is
   demonstrated by the JWS signature by an account key, from which the
   server can look up related authorizations.  Some attributes which
   cannot be
   revoked: reflected in a CSR are placed directly in the certificate
   request.

   csr (required, string):  The  A CSR encoding the parameters for the
      certificate to be revoked, being requested.  The CSR is sent in the Base64-encoded Base64url-
      encoded version of the DER format.  (Note: This field uses the
      same modified Base64-encoding Base64 encoding rules used elsewhere in this
      document, so it is different from PEM.)

   notBefore (optional, string):  The requested value of the notBefore
      field in the certificate, in the date format defined in [RFC3339]

   notAfter (optional, string):  The requested value of the notAfter
      field in the certificate, in the date format defined in [RFC3339]

   POST /acme/revoke-cert /acme/new-cert HTTP/1.1
   Host: example.com
   Accept: application/pkix-cert

   {
     "resource": "revoke-cert",
     "certificate": "MIIEDTCCAvegAwIBAgIRAP8..." "new-cert",
     "csr": "5jNudRx6Ye4HzKEqT5...FS6aKdZeGsysoCo4H9P",
     "notBefore": "2016-01-01T00:00:00Z",
     "notAfter": "2016-01-08T00:00:00Z"
   }
   /* Signed as JWS */

   Revocation requests are different from other ACME request in that
   they can be signed either with an account key pair or the key pair in
   the certificate.  Before revoking a certificate, the server MUST
   verify at least one of these conditions applies:

   o  the public key of the key pair signing the request matches the
      public key in the certificate.

   o */

   The CSR encodes the key pair signing client's requests with regard to the request is an account key, and content of
   the
      corresponding account is authorized certificate to act for all of be issued.  The CSR MUST indicate the
      identifier(s) requested
   identifiers, either in the certificate.

   If the revocation succeeds, the server responds with status code 200
   (OK).  If the revocation fails, commonName portion of the server returns an error.

   HTTP/1.1 200 OK
   Content-Length: 0

   --- requested
   subject name, or ---

   HTTP/1.1 403 Forbidden
   Content-Type: application/problem+json
   Content-Language: en

   {
     "type": "urn:acme:error:unauthorized"
     "detail": "No authorization in an extensionRequest attribute [RFC2985]
   requesting a subjectAltName extension.

   The values provided for name example.net"
     "instance": "http://example.com/doc/unauthorized"
   }

7.  Identifier Validation Challenges

   There are few types of identifier in the world for which there is a
   standardized mechanism to prove possession of a given identifier.  In
   all practical cases, CAs rely on CSR are only a variety of means to test whether request, and are not
   guaranteed.  The server SHOULD return an entity applying for error if it cannot fulfil
   the request as specified, but MAY issue a certificate with contents
   other than those requested, according to its local policy (e.g.,
   removing identifiers for which the client is not authorized).

   It is up to the server's local policy to decide which names are
   acceptable in a certificate, given identifier actually
   controls the authorizations that identifier.

   Challenges provide the server
   associates with assurance that an the client's account key
   holder key.  A server MAY consider a
   client authorized for a wildcard domain if it is also authorized for the
   underlying domain name (without the "*" label).  Servers SHOULD NOT
   extend authorization across identifier types.  For example, if a
   client is authorized for "example.com", then the entity that controls server should not
   allow the client to issue a certificate with an identifier.  For each type
   of challenge, iPAddress
   subjectAltName, even if it must be the case that in order for contains an entity IP address to
   successfully complete which
   example.com resolves.

   If the challenge CA decides to issue a certificate, then the entity must both:

   o  Hold server creates a
   new certificate resource and returns a URI for it in the private key Location
   header field of a 201 (Created) response.

   HTTP/1.1 201 Created
   Location: https://example.com/acme/cert/asdf

   If the account key pair used to respond to certificate is available at the challenge

   o  Control time of the identifier response, it is
   provided in question

   Section 9 documents how the challenges defined in this document meet
   these requirements.  New challenges will need to document how they
   do.

   To accommodate this reality, ACME includes an extensible challenge/
   response framework for identifier validation.  This section describes
   an initial set of Challenge types.  Each challenge must describe:

   o  Content of Challenge payloads (in Challenge messages)

   o  Content body of Response payloads (in authorizationRequest messages)

   o  How the server uses response.  If the Challenge and Response to verify control
      of an identifier

   The general structure of Challenge and Response payloads is as
   follows:

   type (required, string):  The type of Challenge or Response encoded
      in CA has not yet issued
   the object.

   uri (required, string):  The URI to which a certificate, the body of this response can will be posted.

   status (optional, string): : empty.  The status of this authorization.
   Possible values are: "unknown", "pending", "processing", "valid",
   "invalid" and "revoked".  If this field is missing, client
   should then send a GET request to the certificate URI to poll for the
   certificate.  As long as the default
   value certificate is "pending".

   validated (optional, string): : The time at which this challenge was
   completed by unavailable, the server, encoded server
   MUST provide a 202 (Accepted) response and include a Retry-After
   header to indicate when the server believes the certificate will be
   issued (as in the example above).

   GET /acme/cert/asdf HTTP/1.1
   Host: example.com
   Accept: application/pkix-cert

   HTTP/1.1 202 Accepted
   Retry-After: 120

   The default format specified in RFC 3339
   [RFC3339].

   error (optional, dictionary of string): : The error that occurred
   while the server was validating the challenge, if any.  This field certificate is
   structured as a problem document [I-D.ietf-appsawg-http-problem].

   All additional fields are specified DER (application/pkix-cert).
   The client may request other formats by the Challenge type. including an Accept header in
   its request.

   The server MUST ignore any values provided in provides metadata about the "uri", "status",
   "validated", and "error" fields of a Response payload.  If certificate in HTTP headers.
   In particular, the server
   sets a Challenge's "status" to "invalid", it SHOULD also MUST include the
   "error" a Link relation header field
   [RFC5988] with relation "up" to help the client diagnose why they failed the
   challenge.

   Different challenges allow provide a certificate under which
   this certificate was issued, and one with relation "author" to
   indicate the registration under which this certificate was issued.

   The server to obtain proof of different
   aspects of control over MAY include an identifier.  In some challenges, like HTTP
   and TLS SNI, Expires header as a hint to the client directly proves its ability to do certain
   things related
   about when to renew the identifier.  In certificate.  (Of course, the Proof real expiration
   of Possession
   challenge, the certificate is controlled by the notAfter time in the
   certificate itself.)

   If the CA participates in Certificate Transparency (CT) [RFC6962],
   then they may want to provide the client proves historical control of the identifier, by
   reference with a Signed Certificate
   Timestamp (SCT) that can be used to prove that a prior authorization transaction certificate was
   submitted to a CT log.  An SCT can be included as an extension in the
   certificate or as an extension to OCSP responses for the certificate.
   The choice of which Challenges to offer to a client under which
   circumstances is a matter of server policy.  A CA may choose
   different sets of challenges depending on whether it has interacted
   with a domain before, and how.  For example:

   o  New domain can also provide the client with no known certificates: Domain Validation (HTTP or
      TLS SNI)

   o  Domain direct access to an SCT
   for which known certs exist from other CAs: DV + Proof of
      Possession of previous CA-signed key

   o  Domain with a cert from this CA, lost account key: DV + PoP of
      ACME-certified Subject key

   o  Domain with certificate using a cert from this CA, all keys and recovery mechanisms
      lost: Out of band proof of authority Link relation header field with relation
   "ct-sct".

   GET /acme/cert/asdf HTTP/1.1
   Host: example.com
   Accept: application/pkix-cert

   HTTP/1.1 200 OK
   Content-Type: application/pkix-cert
   Link: <https://example.com/acme/ca-cert>;rel="up";title="issuer"
   Link: <https://example.com/acme/revoke-cert>;rel="revoke"
   Link: <https://example.com/acme/reg/asdf>;rel="author"
   Link: <https://example.com/acme/sct/asdf>;rel="ct-sct"
   Link: <https://example.com/acme/some-directory>;rel="directory"
   Location: https://example.com/acme/cert/asdf
   Content-Location: https://example.com/acme/cert-seq/12345

   [DER-encoded certificate]

   A certificate resource always represents the most recent certificate
   issued for the domain

   The identifier validation challenges described name/key binding expressed in this section all
   relate to validation of domain names. the CSR.  If ACME is extended in the
   future to support other types of identifier, there will need CA
   allows a certificate to be
   new Challenge types, and they will need to specify which types of
   identifier they apply to.

   [[ Editor's Note: In pre-RFC renewed, then it publishes renewed
   versions of this specification,
   challenges are labeled by type, and with the version certificate through the same certificate URI.

   Clients retrieve renewed versions of the draft in
   which they were introduced.  For example, if an HTTP challenge were
   introduced in version -03 and certificate using a breaking change made in version -05, GET
   query to the certificate URI, which the server should then there would be a challenge labeled "http-03" and one labeled
   "http-05" - but not one labeled "http-04", since challenge in version
   -04 was compatible with one return in version -04. ]]

   [[ Editor's Note: Operators
   a 200 (OK) response.  The server SHOULD NOT issue "combinations" arrays provide a stable URI for each
   specific certificate in
   authorization objects that require the client Content-Location header field, as shown
   above.  Requests to perform multiple
   challenges over the same type, e.g., ["http-03", "http-05"].
   Challenges within a type are testing stable certificate URIs MUST always result in the
   same capability of certificate.

   To avoid unnecessary renewals, the
   domain owner, and it CA may choose not be possible to satisfy both issue a
   renewed certificate until it receives such a request (if it even
   allows renewal at once. ]]

7.1.  Key Authorizations

   Several all).  In such cases, if the CA requires some time
   to generate the new certificate, the CA MUST return a 202 (Accepted)
   response, with a Retry-After header field that indicates when the new
   certificate will be available.  The CA MAY include the current (non-
   renewed) certificate as the body of the challenges response.

   Likewise, in this document makes use of order to prevent unnecessary renewal due to queries by
   parties other than the account key holder, certificate URIs should be
   structured as capability URLs [W3C.WD-capability-urls-20140218].

   From the client's perspective, there is no difference between a key
   authorization string.  A key authorization expresses
   certificate URI that allows renewal and one that does not.  If the
   client wishes to obtain a domain
   holder's authorization for renewed certificate, and a specified key GET request to satisfy a specified
   challenge, by concatenating
   the token for certificate URI does not yield one, then the challenge with client may initiate
   a key
   fingerprint, separated by new-certificate transaction to request one.

6.6.  Certificate Revocation

   To request that a "." character:

   key-authz = token || '.' || base64(JWK_Thumbprint(accountKey))

   The "JWK_Thumbprint" step indicates the computation specified in
   [RFC7638], using certificate be revoked, the SHA-256 digest.  As specified in client sends a POST
   request to the individual
   challenges below, ACME server's revoke-cert URI.  The body of the token for a challenge POST
   is a JWS object whose JSON string
   comprised entirely of characters in payload contains the base64 alphabet. certificate to be
   revoked:

   certificate (required, string):  The "||"
   operator indicates concatenation of strings.

   In computations involving key authorizations, such as the digest
   computations required for the DNS and TLS SNI challenges, the key
   authorization string MUST certificate to be represented revoked, in UTF-8 form (or,
   equivalently, ASCII).

7.2.  HTTP

   With Simple HTTP validation,
      the client base64url-encoded version of the DER format.  (Note: This
      field uses the same modified Base64 encoding rules used elsewhere
      in an this document, so it is different from PEM.)

   POST /acme/revoke-cert HTTP/1.1
   Host: example.com

   {
     "resource": "revoke-cert",
     "certificate": "MIIEDTCCAvegAwIBAgIRAP8..."
   }
   /* Signed as JWS */

   Revocation requests are different from other ACME transaction proves
   its control over a domain name by proving request in that it
   they can provision
   resources on be signed either with an HTTP account key pair or the key pair in
   the certificate.  Before revoking a certificate, the server MUST
   verify that responds for that domain name.  The
   ACME server challenges the client key used to provision a file with a specific
   JWS as its contents.

   As a domain may resolve sign the request is authorized to multiple IPv4 and IPv6 addresses, revoke
   the certificate.  The server will connect to SHOULD consider at least one of the hosts found in A and AAAA
   records, at its discretion.  Because many webservers allocate a
   default HTTPS virtual host to following
   keys authorized for a particular low-privilege tenant user given certificate:

   o  the public key in a subtle and non-intuitive manner, the challenge must be completed
   over HTTP, not HTTPS.

   type (required, string):  The string "http-01"

   token (required, string):  A random value certificate.

   o  an account key that uniquely identifies
      the challenge.  This value MUST have at least 128 bits is authorized to act for all of entropy, the
      identifier(s) in order to prevent an attacker from guessing it.  It MUST NOT
      contain any characters outside the URL-safe Base64 alphabet. certificate.

   If the revocation succeeds, the server responds with status code 200
   (OK).  If the revocation fails, the server returns an error.

   HTTP/1.1 200 OK
   Content-Length: 0

   --- or ---

   HTTP/1.1 403 Forbidden
   Content-Type: application/problem+json
   Content-Language: en

   {
     "type": "http-01",
     "token": "evaGxfADs6pSRb2LAv9IZf17Dt3juxGJ-PCt92wr-oA",
   }

   A client responds to this challenge by constructing a key "urn:ietf:params:acme:error:unauthorized"
     "detail": "No authorization from the "token" value provided for name example.net"
     "instance": "http://example.com/doc/unauthorized"
   }

7.  Identifier Validation Challenges

   There are few types of identifiers in the challenge and
   the client's account key.  The client then provisions the key
   authorization as world for which there is a
   standardized mechanism to prove possession of a resource given identifier.  In
   all practical cases, CAs rely on the HTTP server a variety of means to test whether
   an entity applying for a certificate with a given identifier actually
   controls that identifier.

   Challenges provide the domain in
   question.

   evaGxfADs6pSRb2LAv9IZf17Dt3juxGJ-PCt92wr-oA
   .nP1qzpXGymHBrUEepNY9HCsQk7K8KhOypzEt62jcerQ

   The path at which the resource is provisioned server with assurance that an account key
   holder is comprised of also the
   fixed prefix ".well-known/acme-challenge/", followed by entity that controls an identifier.  For each type
   of challenge, it must be the "token"
   value case that in the challenge.

  .well-known/acme-challenge/evaGxfADs6pSRb2LAv9IZf17Dt3juxGJ-PCt92wr-oA
   The client's response to this challenge indicates its agreement order for an entity to
   this
   successfully complete the challenge by sending the server entity must both:

   o  Hold the private key authorization covering
   the challenge's token and of the client's account key:

   keyAuthorization (required, string):  The key authorization for this
      challenge.  This value MUST match the token from pair used to respond to
      the challenge and

   o  Control the client's account key.

   {
     "keyAuthorization": "evaGxfADs...62jcerQ"
   }
   /* Signed as JWS */

   On receiving a response, identifier in question

   Section 10 documents how the challenges defined in this document meet
   these requirements.  New challenges will need to document how they
   do.

   ACME uses an extensible challenge/response framework for identifier
   validation.  The server MUST verify that presents a set of challenge in the key
   authorization object it sends to a client (as objects in the response matches
   "challenges" array), and the "token" value client responds by sending a response
   object in the a POST request to a challenge and the client's account key.  If they do not match, then
   the server MUST return URI.

   This section describes an HTTP error in initial set of challenge types.  Each
   challenge must describe:

   1.  Content of challenge objects

   2.  Content of response to the POST request
   in which the client sent the challenge.

   Given a Challenge/Response pair, objects

   3.  How the server verifies uses the client's challenge and response to verify control
       of an identifier

   Challenge objects all contain the domain by verifying that the resource was provisioned
   as expected.

   1.  Form a URI by populating following basic fields:

   type (required, string):  The type of challenge encoded in the
      object.

   uri (required, string):  The URI template [RFC6570]
       "http://{domain}/.well-known/acme-challenge/{token}", where:

       *  the domain field is set to the domain name being verified; which a response can be posted.

   status (required, string):  The status of this authorization.
      Possible values are: "pending", "valid", and

       *  the token "invalid".  If this
      field is set to the token in the challenge.

   2.  Verify that missing, then the resulting URI default value is well-formed.

   3.  Dereference the URI using an HTTP or HTTPS GET request.  If using
       HTTPS, the ACME server MUST ignore the certificate provided "pending".

   validated (optional, string):  The time at which this challenge was
      completed by the HTTPS server.

   4.  Verify that the Content-Type header of server, encoded in the response format specified in RFC
      3339 [RFC3339].  This field is either
       absent, or has REQUIRED if the value "text/plain".

   5.  Verify "status" field is
      "valid".

   error (optional, dictionary of string):  The error that occurred
      while the body of server was validating the response challenge, if any.  This field
      is well-formed key
       authorization.

   6.  Verify that key authorization provided structured as a problem document
      [I-D.ietf-appsawg-http-problem].

   All additional fields are specified by the server matches the
       token for this challenge and the client's account key. type.  If all of the above verifications succeed, then
   server sets a challenge's "status" to "invalid", it SHOULD also
   include the "error" field to help the validation is
   successful.  If client diagnose why they failed
   the request fails, or challenge.

   Different challenges allow the body does not pass these
   checks, then it has failed.

7.3.  TLS with Server Name Indication (TLS SNI)

   The TLS with Server Name Indication (TLS SNI) validation method
   proves server to obtain proof of different
   aspects of control over a domain name by requiring the client to
   configure a TLS server referenced by an A/AAAA record under identifier.  In some challenges, like HTTP
   and TLS SNI, the
   domain name client directly proves its ability to respond do certain
   things related to specific connection attempts utilizing the
   Server Name Indication extension [RFC6066]. identifier.  The server verifies the
   client's challenge by accessing the reconfigured server and verifying choice of which challenges to
   offer to a particular challenge certificate client under which circumstances is presented.

   type (required, string):  The string "tls-sni-01"

   token (required, string):  A random value that uniquely identifies
      the challenge.  This value MUST have at least 128 bits a matter of entropy, server
   policy.

   The identifier validation challenges described in order this section all
   relate to prevent an attacker from guessing it.  It MUST NOT
      contain any characters outside the URL-safe Base64 alphabet.

   n (required, number):  Number validation of tls-sni-01 iterations

   {
     "type": "tls-sni-01",
     "token": "evaGxfADs6pSRb2LAv9IZf17Dt3juxGJ-PCt92wr-oA",
     "n": 25
   }

   A client responds to this challenge by constructing a key
   authorization from the "token" value provided domain names.  If ACME is extended in the
   future to support other types of identifier, there will need to be
   new challenge types, and they will need to specify which types of
   identifier they apply to.

   [[ Editor's Note: In pre-RFC versions of this specification,
   challenges are labeled by type, and with the client's account key.  The client first computes the SHA-256
   digest Z0 version of the UTF8-encoded key authorization, draft in
   which they were introduced.  For example, if an HTTP challenge were
   introduced in version -03 and encodes Z0 a breaking change made in
   UTF-8 lower-case hexadecimal form.  The client version -05,
   then generates
   iterated hash values Z1...Z(n-1) as follows:

   Z(i) = lowercase_hexadecimal(SHA256(Z(i-1))).

   The client generates there would be a self-signed certificate for each iteration of
   Zi challenge labeled "http-03" and one labeled
   "http-05" - but not one labeled "http-04", since challenge in version
   -04 was compatible with a single subjectAlternativeName extension dNSName one in version -04. ]]

   [[ Editor's Note: Operators SHOULD NOT issue "combinations" arrays in
   authorization objects that is
   "<Zi[0:32]>.<Zi[32:64]>.acme.invalid", where "Zi[0:32]" and
   "Zi[32:64]" represent the first 32 and last 32 characters of the hex-
   encoded value, respectively (following require the notation used in Python).
   The client then configures the TLS server at to perform multiple
   challenges over the domain such that
   when same type, e.g., ["http-03", "http-05"].
   Challenges within a handshake is initiated with type are testing the Server Name Indication
   extension set to "<Zi[0:32]>.<Zi[32:64]>.acme.invalid", same capability of the
   corresponding generated certificate is presented.

   The response
   domain owner, and it may not be possible to satisfy both at once. ]]

7.1.  Key Authorizations

   Several of the TLS SNI challenge simply acknowledges that the
   client is ready to fulfill challenges in this challenge.

   keyAuthorization (required, string):  The document makes use of a key
   authorization for this
      challenge.  This value MUST match the token from the challenge and
      the client's account key.

   {
     "keyAuthorization": "evaGxfADs...62jcerQ",
   }
   /* Signed as JWS */

   On receiving string.  A key authorization is a response, the server MUST verify string that the expresses
   a domain holder's authorization for a specified key
   authorization in the response matches to satisfy a
   specified challenge, by concatenating the "token" value in token for the challenge and the client's account key.  If they do not match, then
   with a key fingerprint, separated by a "." character:

   key-authz = token || '.' || base64url(JWK\_Thumbprint(accountKey))

   The "JWK_Thumbprint" step indicates the server MUST return an HTTP error computation specified in response to
   [RFC7638], using the POST request SHA-256 digest.  As specified in which the client sent individual
   challenges below, the challenge.

   Given token for a Challenge/Response pair, the ACME server verifies the
   client's control challenge is a JSON string
   comprised entirely of characters in the domain by verifying that the TLS server was
   configured appropriately.

   1.  Choose a subset URL-safe Base64 alphabet.
   The "||" operator indicates concatenation of strings.

   In computations involving key authorizations, such as the N iterations to check, according to local
       policy.

   2.  For each iteration, compute digest
   computations required for the Zi-value from DNS and TLS SNI challenges, the key
   authorization string MUST be represented in the same way as the client.

   3.  Open a TLS connection UTF-8 form (or,
   equivalently, ASCII).

   An example of how to the domain name being validated on the
       requested port, presenting the value
       "<Zi[0:32]>.<Zi[32:64]>.acme.invalid" compute a JWK thumbprint can be found in the SNI field (where the
       comparison is case-insensitive).

   4.  Verify
   Section 3.1 of [RFC7638].  Note that the certificate contains some cryptographic libraries
   prepend a subjectAltName extension
       with zero octet to the dNSName representation of "<Z[0:32]>.<Z[32:64]>.acme.invalid", the RSA public key
   parameters N and that
       no other dNSName entries E, in order to avoid ambiguity with regard to the
   sign of the form "*.acme.invalid" are present number.  As noted in JWA [RFC7518], a JWK object MUST NOT
   include this zero octet.  That is, any initial zero octets MUST be
   stripped before the subjectAltName extension.

   It is RECOMMENDED that values are base64url-encoded.

7.2.  HTTP

   With HTTP validation, the client in an ACME server verify transaction proves its
   control over a random subset of the
   N iterations with an appropriate sized to ensure domain name by proving that an attacker who it can provision certs for a default virtual host, but not for arbitrary
   simultaneous virtual hosts, cannot pass the challenge.  For instance,
   testing a subset of 5 of N=25 domains ensures that such resources
   on an attacker
   has only a one in 25/5 chance of success if they post certs Zn in
   random succession.  (This probability is enforced by the requirement HTTP server that each certificate have only one Zi value.)

   It is RECOMMENDED responds for that the domain name.  The ACME
   server validation TLS connections
   from multiple vantage points to reduce the risk of DNS hijacking
   attacks.

   If all of the above verifications succeed, then the validation is
   successful.  Otherwise, challenges the validation fails.

7.4.  Proof of Possession of a Prior Key

   The Proof of Possession challenge verifies that a client possesses a
   private key corresponding to provision a server-specified public key, file at a specific path,
   with a specific string as
   demonstrated by its ability to sign with that key.  This challenge is
   meant content.

   As a domain may resolve to be used when multiple IPv4 and IPv6 addresses, the
   server knows will connect to at least one of the hosts found in A and AAAA
   records.  Because many web servers allocate a public key default HTTPS virtual
   host to a particular low-privilege tenant user in a subtle and non-
   intuitive manner, the challenge must be completed over HTTP, not
   HTTPS.

   type (required, string):  The string "http-01"

   token (required, string):  A random value that is
   already associated with uniquely identifies
      the challenge.  This value MUST have at least 128 bits of entropy,
      in order to prevent an attacker from guessing it.  It MUST NOT
      contain any characters outside the identifier being claimed, URL-safe Base64 alphabet and wishes for
   new authorizations
      MUST NOT contain any padding characters ("=").

   {
     "type": "http-01",
     "token": "evaGxfADs6pSRb2LAv9IZf17Dt3juxGJ-PCt92wr-oA",
   }

   A client responds to be authorized this challenge by constructing a key
   authorization from the holder of "token" value provided in the
   corresponding private challenge and
   the client's account key.  For DNS identifiers, for example, this
   can help guard against domain hijacking.

   This method is useful if a server policy calls for issuing a
   certificate only to an entity that already possesses  The client then provisions the subject
   private key of a particular prior related certificate (perhaps issued
   by
   authorization as a different CA).  It may also help enable other kinds of resource on the HTTP server
   policy that are related to authenticating a client's identity using
   digital signatures.

   This challenge proceeds in much for the same way as domain in
   question.

   The path at which the proof of
   possession resource is provisioned is comprised of the authorized key pair
   fixed prefix ".well-known/acme-challenge/", followed by the "token"
   value in the main ACME flow
   (challenge + authorizationRequest). challenge.  The server provides a nonce and value of the client signs over resource MUST be the nonce.  The main difference is that rather
   than signing with ASCII
   representation of the private key of authorization.

  .well-known/acme-challenge/evaGxfADs6pSRb2LAv9IZf17Dt3juxGJ-PCt92wr-oA

   The client's response to this challenge indicates its agreement to
   this challenge by sending the server the key pair being authorized, authorization covering
   the challenge's token and the client's account key.  In addition, the
   client signs with a private key specified by MAY advise the server.  The server can specify at which key pair(s) are acceptable directly (by
   indicating a public key), or by asking for IP the key corresponding to a
   certificate. challenge is
   provisioned.

   keyAuthorization (required, string):  The server provides key authorization for this
      challenge.  This value MUST match the following fields as part of token from the challenge:

   type (required, string):  The string "proofOfPossession-01"

   certs challenge and
      the client's account key.

   address (optional, array of string):  An array of certificates, IPv4 or IPv6 address, in
      Base64-encoded DER format, that contain acceptable public keys.

   {
     "type": "proofOfPossession-01",
     "certs": ["MIIF7z...bYVQLY"]
   }

   In response to dotted
      decimal form or [RFC4291] form, respectively.  If given, this challenge, the client uses
      address MUST be included in the private key
   corresponding to one set of the acceptable public keys to sign a JWS
   object including data related IP addresses to which the challenge.  The validation
   object covered by
      domain name resolves when the signature has server attempts validation.  If
      given, the following fields:

   type (required, string):  The string "proofOfPossession"

   identifiers (required, identifier):  A list server SHOULD connect to that specific IP address
      instead of identifiers for which arbitrarily choosing an IP from the holder set of A and AAAA
      records to which the prior key authorizes the new key

   accountKey (required, JWK):  The client's account public key

   {
     "type": "proofOfPossession-01",
     "identifiers: [{"type": "dns", "value": "example.com"}],
     "accountKey": domain name resolves.

   { "kty": "RSA", ... }
     "keyAuthorization": "evaGxfADs...62jcerQ"
   }

   This
   /* Signed as JWS is NOT REQUIRED to have */

   On receiving a "nonce" header parameter (as with response, the JWS objects server MUST verify 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 key
   authorization in the
   old domain owner to sign a proof-of-possession validation object, so
   that response matches the new domain owner can present that "token" value in an ACME transaction
   later.

   The validation JWS the
   challenge and the client's account key.  If they do not match, then
   the server MUST contain a "jwk" header parameter indicating return an HTTP error in response to the public key under POST request
   in which the client sent the challenge.

   Given a challenge/response pair, the server should verify verifies the JWS.

   The client's response includes the server-provided nonce, together
   with a signature over that nonce by one
   control of the private keys requested domain by verifying that the server.

   type (required, string):  The string "proofOfPossession"

   authorization (required, JWS):  The validation JWS

   {
     "type": "proofOfPossession-01",
     "authorization": {
       "header": {
         "alg": "RS256",
         "jwk": {
           "kty": "RSA",
           "e": "AQAB",
           "n": "AMswMT...3aVtjE"
         }
       },
       "payload": "SfiR1...gSAl7A",
       "signature": "XcQLfL...cW5beg"
     }
   }
   To validate resource was provisioned
   as expected.

   1.  Form a proof-of-possession challenge, the server performs URI by populating the
   following steps:

   1.  Verify that URI template [RFC6570]
       "http://{domain}/.well-known/acme-challenge/{token}", where:

       *  the public key in domain field is set to the "jwk" header of domain name being verified; and

       *  the
       "authorization" JWS corresponds token field is set to one of the certificates token in the
       "certs" field of the challenge challenge.

   2.  Verify that the "authorization" JWS using resulting URI is well-formed.

   3.  If the key indicated client has supplied an address to use, verify that the
       address is included in its
       "jwk" header

   3.  Decode the payload of A or AAAA records to which the JWS as UTF-8 encoded JSON domain
       name resolves.  If the address is not included in the result, the
       validation fails.

   4.  Dereference the URI using an HTTP GET request.  If an address was
       supplied by the client, use that address to establish the HTTP
       connection.

   5.  Verify that there are exactly three fields in the decoded object,
       and that:

       *  The "type" field body of the response is set to "proofOfPossession"

       * well-formed key
       authorization.  The "identifier" field contains server SHOULD ignore whitespace characters at
       the identifier for which end of the body.

   6.  Verify that key authorization is being validated

       *  The "accountKey" field provided by the server matches the account key
       token for which the this challenge was issued and the client's account key.

   If all of the above verifications succeed, then the validation is
   successful.  Otherwise, the validation fails.

7.5.  DNS

   When  If the identifier being validated is a domain name, request fails, or the client can
   prove body does not pass these
   checks, then it has failed.

7.3.  TLS with Server Name Indication (TLS SNI)

   The TLS with Server Name Indication (TLS SNI) validation method
   proves control of that over a domain name by provisioning resource records under
   it.  The DNS challenge requires requiring the client to provision
   configure a TXT TLS server referenced by an A/AAAA record
   containing a designated value under a specific validation the
   domain
   name. name to respond to specific connection attempts utilizing the
   Server Name Indication extension [RFC6066].  The server verifies the
   client's challenge by accessing the reconfigured server and verifying
   a particular challenge certificate is presented.

   type (required, string):  The string "dns-01" "tls-sni-02"

   token (required, string):  A random value that uniquely identifies
      the challenge.  This value MUST have at least 128 bits of entropy,
      in order to prevent an attacker from guessing it.  It MUST NOT
      contain any characters outside the URL-safe Base64 alphabet. alphabet and
      MUST NOT contain any padding characters ("=").

   {
     "type": "dns-01", "tls-sni-02",
     "token": "evaGxfADs6pSRb2LAv9IZf17Dt3juxGJ-PCt92wr-oA"
   }

   A client responds to this challenge by constructing a key
   authorization from self-signed
   certificate which the "token" value provided in client MUST provision at the challenge and domain name
   concerned in order to pass the client's account key. challenge.

   The client then computes certificate may be constructed arbitrarily, except that each
   certificate MUST have exactly two subjectAlternativeNames, SAN A and
   SAN B.  Both MUST be dNSNames.

   SAN A MUST be constructed as follows: compute the SHA-256 digest of
   the key authorization. UTF-8-encoded challenge token and encode it in lowercase
   hexadecimal form.  The record provisioned to the DNS dNSName is "x.y.token.acme.invalid", where x
   is the base64 encoding first half of this
   digest.  The client constructs the validation domain name by
   prepending the label "_acme-challenge" to hexadecimal representation and y is the domain name being
   validated, then provisions a TXT record with
   second half.

   SAN B MUST be constructed as follows: compute the SHA-256 digest value under
   that name.  For example, if of
   the domain name being validated UTF-8 encoded key authorization and encode it in lowercase
   hexadecimal form.  The dNSName is "x.y.ka.acme.invalid" where x is
   the first half of the hexadecimal representation and y is
   "example.com", then the second
   half.

   The client would provision MUST ensure that the following DNS
   record:

   _acme-challenge.example.com. 300 IN TXT "gfj9Xq...Rg85nM" certificate is served to TLS
   connections specifying a Server Name Indication (SNI) value of SAN A.

   The response to the DNS TLS-SNI challenge simply acknowledges that the
   client is ready to fulfill this challenge.

   keyAuthorization (required, string):  The key authorization for this
      challenge.  This value MUST match the token from the challenge and
      the client's account key.

   {
     "keyAuthorization": "evaGxfADs...62jcerQ",
   }
   /* Signed as JWS */

   On receiving a response, the server MUST verify that the key
   authorization in the response matches the "token" value in the
   challenge and the client's account key.  If they do not match, then
   the server MUST return an HTTP error in response to the POST request
   in which the client sent the challenge.

   To validate

   Given a DNS challenge, challenge/response pair, the ACME server performs the following steps:

   1.  Compute verifies the SHA-256 digest
   client's control of the key authorization

   2.  Query for TXT records under the validation domain name

   3.  Verify by verifying that the contents of one of the TXT records matches the
       digest value

   If all of the above verifications succeed, then the validation is
   successful.  If no DNS record is found, or DNS record and response
   payload do not pass TLS server was
   configured appropriately, using these checks, then steps:

   1.  Compute SAN A and SAN B in the validation fails.

8.  IANA Considerations

   TODO

   o  Register .well-known path

   o  Register Replay-Nonce HTTP header

   o  Register "nonce" JWS header parameter

   o  Register "urn:acme" namespace

   o  Create identifier validation method registry

   o  Registries of syntax tokens, e.g., message types / error types?

9.  Security Considerations

   ACME is same way as the client.

   2.  Open a protocol for managing certificates that attest TLS connection to
   identifier/key bindings.  Thus the foremost security goal of ACME is
   to ensure domain name being validated on the integrity of this process, i.e., to ensure that
       requested port, presenting SAN A in the
   bindings attested by certificates are correct, and that only
   authorized entities can manage certificates.  ACME identifies clients
   by their account keys, so this overall goal breaks down into two more
   precise goals:

   1.  Only an entity that controls a identifier can get an account key
       authorized for that identifier

   2.  Once authorized, an account key's authorizations cannot be
       improperly transferred to another account key SNI field.  In this section, we discuss the threat model that underlies ACME and
       ClientHello initiating the ways TLS handshake, the server MUST include
       a server_name extension (i.e., SNI) containing SAN A.  The server
       SHOULD ensure that ACME achieves these security goals within it does not reveal SAN B in any way when
       making the TLS connection, such that threat
   model.  We also discuss the denial-of-service risks presentation of SAN B in
       the returned certificate proves association with the client.

   3.  Verify that ACME servers
   face, and the certificate contains a few subjectAltName extension
       containing dNSName entries of SAN A and SAN B and no other miscellaneous considerations.

9.1.  Threat model

   As a service on
       entries.  The comparison MUST be insensitive to case and ordering
       of names.

   It is RECOMMENDED that the Internet, ACME broadly exists within server validation TLS connections
   from multiple vantage points to reduce the Internet
   threat model [RFC3552].  In analyzing ACME, it risk of DNS hijacking
   attacks.

   If all of the above verifications succeed, then the validation is useful to think
   successful.  Otherwise, the validation fails.

7.4.  DNS

   When the identifier being validated is a domain name, the client can
   prove control of
   an ACME server interacting with other Internet hosts along three
   "channels":

   o  An ACME channel, over which that domain by provisioning a resource record under
   it.  The DNS challenge requires the ACME HTTPS requests are exchanged
   o  A client to provision a TXT record
   containing a designated value under a specific validation channel, over which domain
   name.

   type (required, string):  The string "dns-01"

   token (required, string):  A random value that uniquely identifies
      the challenge.  This value MUST have at least 128 bits of entropy,
      in order to prevent an attacker from guessing it.  It MUST NOT
      contain any characters outside the ACME server performs
      additional requests URL-safe Base64 alphabet and
      MUST NOT contain any padding characters ("=").

   {
     "type": "dns-01",
     "token": "evaGxfADs6pSRb2LAv9IZf17Dt3juxGJ-PCt92wr-oA"
   }

   A client responds to validate this challenge by constructing a key
   authorization from the "token" value provided in the challenge and
   the client's control account key.  The client then computes the SHA-256
   digest of an
      identifier

   o  A contact channel, over which the ACME server sends messages key authorization.

   The record provisioned to the registered contacts for ACME clients

   +------------+
   |    ACME    |     ACME Channel
   |   Client   |--------------------+
   +------------+                    |
          ^                          V
          |   Contact Channel  +------------+
          +--------------------|    ACME    |
                               |   Server   |
                               +------------+
   +------------+                    |
   | Validation |<-------------------+
   |   Server   |  Validation Channel
   +------------+

   In practice, DNS is the risks to these channels are not entirely separate,
   but they are different in most cases.  Each base64url encoding of this
   digest.  The client constructs the three channels,
   for example, uses a different communications pattern: validation domain name by
   prepending the ACME
   channel will comprise inbound HTTPS connections label "_acme-challenge" to the ACME server, domain name being
   validated, then provisions a TXT record with the validation channel outbound HTTP or DNS requests, and digest value under
   that name.  For example, if the contact
   channel will use channels such as email and PSTN.

   Broadly speaking, ACME aims to be secure against active and passive
   attackers on any individual channel.  Some vulnerabilities arise
   (noted below), when an attacker can exploit both domain name being validated is
   "example.com", then the ACME channel and
   one of client would provision the following DNS
   record:

   _acme-challenge.example.com. 300 IN TXT "gfj9Xq...Rg85nM"

   The response to the others.

   On DNS challenge provides the ACME channel, in addition computed key
   authorization to network-layer attackers, we also
   need acknowledge that the client is ready to account fulfill this
   challenge.

   keyAuthorization (required, string):  The key authorization for application-layer man in this
      challenge.  This value MUST match the middle attacks, token from the challenge and
   for abusive use of
      the protocol itself.  Protection against
   application-layer MitM addresses potential attackers such client's account key.

   {
     "keyAuthorization": "evaGxfADs...62jcerQ",
   }
   /* Signed as Content
   Distribution Networks (CDNs) and middleboxes with JWS */

   On receiving a TLS MitM
   function.  Preventing abusive use of ACME means ensuring response, the server MUST verify that an
   attacker with access to the validation or contact channels can't
   obtain illegitimate key
   authorization by acting as an ACME client
   (legitimately, in terms of the protocol).

9.2.  Integrity of Authorizations

   ACME allows anyone response matches the "token" value in the
   challenge and the client's account key.  If they do not match, then
   the server MUST return an HTTP error in response to the POST request challenges for an identifier by
   registering an account key and sending
   in which the client sent the challenge.

   To validate a new-authorization request DNS challenge, the server performs the following steps:

   1.  Compute the SHA-256 digest of the key authorization

   2.  Query for TXT records under the validation domain name

   3.  Verify that account key.  The integrity the contents of one of the authorization process
   thus depends on TXT records matches the
       digest value

   If all of the above verifications succeed, then the validation is
   successful.  If no DNS record is found, or DNS record and response
   payload do not pass these checks, then the identifier validation challenges to ensure fails.

8.  IANA Considerations

   [[ Editor's Note: Should we create a registry for tokens that go into
   the challenge can only be completed various JSON objects used by someone who both (1) holds this protocol, i.e., the
   private key of field names
   in the account key pair, and (2) controls JSON objects? ]]

9.  Well-Known URI for the identifier
   in question.

   Validation responses need to HTTP Challenge

   The "Well-Known URIs" registry should be bound to an account key pair in order
   to avoid situations where an ACME MitM can switch out a legitimate
   domain holder's account key for one of his choosing, e.g.:

   o  Legitimate domain holder registers account key pair A

   o  MitM registers account key pair B

   o  Legitimate domain holder sends a new-authorization request signed
      under account key A

   o  MitM suppresses updated with the legitimate request, but sends following
   additional value (using the same request
      signed under account key B

   o  ACME server issues challenges template from [RFC5785]):

   URI suffix: acme-challenge

   Change controller: IETF

   Specification document(s): This document, Section Section 7.2

   Related information: N/A

9.1.  Replay-Nonce HTTP Header

   The "Message Headers" registry should be updated with the following
   additional value:

   | Header Field Name | Protocol | Status | Reference |
   +:------------+:------+:------+:-----------+ | Replay-Nonce | http |
   standard | Section 5.4.1 |

9.2.  "nonce" JWS Header Parameter

   The "JSON Web Signature and MitM forwards them to Encryption Header Parameters" registry
   should be updated with the
      legitimate domain holder following additional value:

   o  Legitimate domain holder provisions the validation response  Header Parameter Name: "nonce"

   o  ACME server performs validation query and sees  Header Parameter Description: Nonce
   o  Header Parameter Usage Location(s): JWE, JWS

   o  Change Controller: IESG

   o  Specification Document(s): Section 5.4.2 of RFC XXXX

   [[ RFC EDITOR: Please replace XXXX above with the response
      provisioned by RFC number assigned
   to this document ]]

9.3.  URN Sub-namespace for ACME (urn:ietf:params:acme)

   The "IETF URN Sub-namespace for Registered Protocol Parameter
   Identifiers" registry should be updated with the legitimate domain holder

   o  Because following additional
   value, following the challenges were issued template in response to a message signed
      account key B, [RFC3553]:

   Registry name:  acme

   Specification:  RFC XXXX

   Repository:  URL-TBD

   Index value:  No transformation needed.  The

   [[ RFC EDITOR: Please replace XXXX above with the ACME server grants authorization RFC number assigned
   to account key
      B (the MitM) instead this document, and replace URL-TBD with the URL assigned by IANA
   for registries of account key A (the legitimate domain
      holder) ACME parameters. ]]

9.4.  New Registries

   This document requests that IANA create three new registries:

   1.  ACME Error Codes

   2.  ACME Identifier Types

   3.  ACME Challenge Types

   All of the challenges above that require an out-of-band query by the
   server have these registries should be administered under a binding to the account private key, such Specification
   Required policy [RFC5226].

9.4.1.  Error Codes

   This registry lists values that the only
   the account private key holder can successfully respond to the
   validation query:

   o  HTTP: The value are used within URN values that are
   provided in the validation request is signed by
      the account private key. "type" field of problem documents in ACME.

   Template:

   o  TLS SNI:  Code: The validation TLS request uses the account key pair as label to be included in the server's key pair. URN for this error,
      following "urn:ietf:params:acme:"

   o  DNS: The MAC covers  Description: A human-readable description of the account key, and error

   o  Reference: Where the MAC key error is derived
      from an ECDH public key signed with the account private key.

   o  Proof of possession of a prior key: defined

   Initial contents: The signature by the prior key
      covers codes and descriptions in the account public key.

   The association of challenges to identifiers is typically done by
   requiring table in
   Section 5.5 above, with the client Reference field set to point to perform some action that only someone who
   effectively controls the identifier can perform.  For the challenges
   in this document,
   specification.

9.4.2.  Identifier Types

   This registry lists the actions are: types of identifiers that ACME clients may
   request authorization to issue in certificates.

   Template:

   o  HTTP: Provision files under .well-known on a web server for  Label: The value to be put in the
      domain

   o  TLS SNI: Configure a TLS server for "type" field of the domain identifier
      object

   o  DNS: Provision DNS resource records for  Reference: Where the domain

   o  Proof of possession of a prior key: Sign using identifier type is defined

   Initial contents:

                           +-------+-----------+
                           | Label | Reference |
                           +-------+-----------+
                           | dns   | RFC XXXX  |
                           +-------+-----------+

   [[ RFC EDITOR: Please replace XXXX above with the private key
      specified by RFC number assigned
   to this document ]]

9.4.3.  Challenge Types

   This registry lists the server

   There are several ways that these assumptions can be violated, both
   by misconfiguration and by attack.  For example, on a web server that
   allows non-administrative users to write to .well-known, any user ACME servers can
   claim offer to own validate
   control of an identifier.  The "Identifier Type" field in template
   MUST be contained in the server's hostname by responding Label column of the ACME Identifier Types
   registry.

   Template:

   o  Label: The value to a Simple HTTP
   challenge, and likewise for TLS configuration and TLS SNI. be put in the "type" field of challenge
      objects using this validation mechanism

   o  Identifier Type: The use type of hosting providers identifier that this mechanism
      applies to

   o  Reference: Where the challenge type is defined

   Initial Contents

                 +---------+-----------------+-----------+
                 | Label   | Identifier Type | Reference |
                 +---------+-----------------+-----------+
                 | http    | dns             | RFC XXXX  |
                 |         |                 |           |
                 | tls-sni | dns             | RFC XXXX  |
                 |         |                 |           |
                 | dns     | dns             | RFC XXXX  |
                 +---------+-----------------+-----------+

   [[ RFC EDITOR: Please replace XXXX above with the RFC number assigned
   to this document ]]

10.  Security Considerations

   ACME is a particular risk protocol for ACME
   validation.  If managing certificates that attest to
   identifier/key bindings.  Thus the owner foremost security goal of ACME is
   to ensure the domain has outsourced operation integrity of
   DNS or web services this process, i.e., to a hosting provider, there is nothing ensure that can
   be done against tampering by the hosting provider.  As far as the
   outside world is concerned, the zone or web site provided
   bindings attested by certificates are correct, and that only
   authorized entities can manage certificates.  ACME identifies clients
   by their account keys, so this overall goal breaks down into two more
   precise goals:

   1.  Only an entity that controls an identifier can get an account key
       authorized for that identifier

   2.  Once authorized, an account key's authorizations cannot be
       improperly transferred to another account key

   In this section, we discuss the
   hosting provider is threat model that underlies ACME and
   the real thing.

   More limited forms of delegation can ways that ACME achieves these security goals within that threat
   model.  We also lead to an unintended party
   gaining discuss the ability to successfully complete a validation
   transaction.  For example, suppose an denial-of-service risks that ACME server follows HTTP
   redirects in Simple HTTP validation servers
   face, and a web site operator
   provisions few other miscellaneous considerations.

10.1.  Threat model

   As a catch-all redirect rule that redirects requests for
   unknown resources to different domain.  Then service on the target of Internet, ACME broadly exists within the
   redirect could use that Internet
   threat model [RFC3552].  In analyzing ACME, it is useful to get a certificate through Simple HTTP
   validation, since think of
   an ACME server interacting with other Internet hosts along three
   "channels":

   o  An ACME channel, over which the ACME HTTPS requests are exchanged
   o  A validation path will not be known to channel, over which the
   primary server.

   The DNS is ACME server performs
      additional requests to validate a common point of vulnerability for all client's control of these
   challenges.  An entity that can provision false DNS records for a
   domain can attack the DNS challenge directly, and can provision false
   A/AAAA records to direct an
      identifier

   o  A contact channel, over which the ACME server sends messages to send its TLS SNI or HTTP
   validation query
      the registered contacts for ACME clients

   +------------+
   |    ACME    |     ACME Channel
   |   Client   |--------------------+
   +------------+                    |
          ^                          V
          |   Contact Channel  +------------+
          +--------------------|    ACME    |
                               |   Server   |
                               +------------+
   +------------+                    |
   | Validation |<-------------------+
   |   Server   |  Validation Channel
   +------------+

   In practice, the risks to a server these channels are not entirely separate,
   but they are different in most cases.  Each of the attacker's choosing.  There are three channels,
   for example, uses a
   few different mitigations that ACME servers can apply:

   o  Checking communications pattern: the DNSSEC status of DNS records used in ACME validation
      (for zones that are DNSSEC-enabled)

   o  Querying the DNS from multiple vantage points to address local
      attackers

   o  Applying mitigations against DNS off-path attackers, e.g., adding
      entropy
   channel will comprise inbound HTTPS connections to requests [I-D.vixie-dnsext-dns0x20] or only using TCP

   Given these considerations, the ACME server,
   the validation process makes it
   impossible for any attacker on channel outbound HTTP or DNS requests, and the contact
   channel will use channels such as email and PSTN.

   Broadly speaking, ACME channel, or a aims to be secure against active and passive
   attackers on any individual channel.  Some vulnerabilities arise
   (noted below), when an attacker on can exploit both the validation ACME channel to hijack the authorization
   process to authorize a key and
   one of the attacker's choice.

   An attacker that can only see others.

   On the ACME channel would channel, in addition to network-layer attackers, we also
   need to convince account for application-layer man in the validation server to provide middle attacks, and
   for abusive use of the protocol itself.  Protection against
   application-layer MitM addresses potential attackers such as Content
   Distribution Networks (CDNs) and middleboxes with a response TLS MitM
   function.  Preventing abusive use of ACME means ensuring that would authorize an
   attacker with access to the
   attacker's account key, but this is prevented validation or contact channels can't
   obtain illegitimate authorization by binding acting as an ACME client
   (legitimately, in terms of the
   validation response protocol).

10.2.  Integrity of Authorizations

   ACME allows anyone to the request challenges for an identifier by
   registering an account key used to and sending a new-authorization request challenges.  A
   passive attacker on
   under that account key.  The integrity of the validation channel can observe authorization process
   thus depends on the correct identifier validation response and even replay it, but challenges to ensure that response
   the challenge can only be
   used with completed by someone who both (1) holds the
   private key of the account key for which it was generated.

   An active attacker on pair, and (2) controls the identifier
   in question.

   Validation responses need to be bound to an account key pair in order
   to avoid situations where an ACME MitM can switch out a legitimate
   domain holder's account key for one of his choosing, e.g.:

   o  Legitimate domain holder registers account key pair A

   o  MitM registers account key pair B

   o  Legitimate domain holder sends a new-authorization request signed
      under account key A

   o  MitM suppresses the validation channel can subvert legitimate request, but sends the same request
      signed under account key B

   o  ACME
   process, by performing normal ACME transactions server issues challenges and providing a
   validation response for his own account key.  The risks due MitM forwards them to
   hosting providers noted above are a particular case.  For identifiers
   where the
      legitimate domain holder

   o  Legitimate domain holder provisions the validation response

   o  ACME server already has some credential associated with performs validation query and sees the
   domain this attack can be prevented response
      provisioned by requiring the client to
   complete a proof-of-possession challenge.

9.3.  Preventing Authorization Hijacking

   The account recovery processes described legitimate domain holder

   o  Because the challenges were issued in Section 6.4 allow
   authorization response to be transferred from one a message signed
      account key to another, in
   case B, the former account key pair's private key is lost. ACME needs
   to prevent these processes from being exploited by an attacker to
   hijack the authorizations attached server grants authorization to one account key and assign them to a
      B (the MitM) instead of account key A (the legitimate domain
      holder)

   All of the attacker's choosing.

   Recovery takes place in two steps: 1.  Provisioning recovery
   information (contact or recovery key) 2.  Using recovery information
   to recover challenges above that require an account

   The provisioning process needs out-of-band query by the
   server have a binding to ensure that only the account key
   holder ends up with information that is useful for recovery.  The
   recovery process needs to assure private key, such that only the (now former)
   account private key holder can successfully execute recovery, i.e., that this entity respond to the validation
   query:

   o  HTTP: The value provided in the validation request is signed by
      the only one that can choose account private key.

   o  TLS SNI: The validation TLS request uses the new account key that receives pair as
      the
   capabilities held by server's key pair.

   o  DNS: The MAC covers the account being recovered.

   MAC-based recovery can be performed if the attacker knows key, and the account MAC key and registration URI for is derived
      from an ECDH public key signed with the account being recovered.  Both private key.

   The association of
   these are difficult challenges to obtain for a network attacker, because ACME
   uses HTTPS, though if the recovery key and registration URI are
   sufficiently predictable, identifiers is typically done by
   requiring the attacker might be able client to guess them.
   An ACME MitM perform some action that only someone who
   effectively controls the identifier can see perform.  For the registration URI, but still has to guess challenges
   in this document, the
   recovery key, since neither actions are:

   o  HTTP: Provision files under .well-known on a web server for the ECDH in
      domain

   o  TLS SNI: Configure a TLS server for the provisioning phase nor
   HMAC in domain

   o  DNS: Provision DNS resource records for the recovery phase will reveal it to him.

   ACME clients domain

   There are several ways that these assumptions can thus mitigate problems with MAC-based recovery be violated, both
   by
   using long recovery keys.  ACME servers should enforce a minimum
   recovery key length, misconfiguration and impose rate limits by attack.  For example, on recovery a web server that
   allows non-administrative users to write to .well-known, any user can
   claim to own the server's hostname by responding to limit an
   attacker's ability HTTP
   challenge, and likewise for TLS configuration and TLS SNI.

   The use of hosting providers is a particular risk for ACME
   validation.  If the owner of the domain has outsourced operation of
   DNS or web services to test different guesses about a hosting provider, there is nothing that can
   be done against tampering by the recovery key.

   Contact-based recovery uses both hosting provider.  As far as the ACME channel and
   outside world is concerned, the contact
   channel.  The provisioning process zone or web site provided by the
   hosting provider is only visible the real thing.

   More limited forms of delegation can also lead to an unintended party
   gaining the ability to successfully complete a validation
   transaction.  For example, suppose an ACME MitM, server follows HTTP
   redirects in HTTP validation and even then, a web site operator provisions a
   catch-all redirect rule that redirects requests for unknown resources
   to different domain.  Then the MitM can only observe target of the contact information
   provided.  If redirect could use that
   to get a certificate through HTTP validation, since the ACME attacker does validation
   path will not also have access be known to the
   contact channel, there is no risk. primary server.

   The security DNS is a common point of vulnerability for all of these
   challenges.  An entity that can provision false DNS records for a
   domain can attack the contact-based recovery process is entirely
   dependent on DNS challenge directly, and can provision false
   A/AAAA records to direct the security ACME server to send its TLS SNI or HTTP
   validation query to a server of the contact channel.  The details of
   this will depend on attacker's choosing.  There are a
   few different mitigations that ACME servers can apply:

   o  Always querying the specific out-of-band technique used by DNS using a DNSSEC-validating resolver
      (enhancing security for zones that are DNSSEC-enabled)

   o  Querying the
   server.  For example: DNS from multiple vantage points to address local
      attackers

   o  If  Applying mitigations against DNS off-path attackers, e.g., adding
      entropy to requests [I-D.vixie-dnsext-dns0x20] or only using TCP

   Given these considerations, the ACME validation process makes it
   impossible for any attacker on the server requires ACME channel, or a user passive
   attacker on the validation channel to click a link in a message sent hijack the authorization
   process to authorize a contact address, then key of the contact attacker's choice.

   An attacker that can only see the ACME channel will would need to ensure convince
   the validation server to provide a response that would authorize the message
   attacker's account key, but this is only available to prevented by binding the legitimate owner of
   validation response to the
      contact address.  Otherwise, a account key used to request challenges.  A
   passive attacker could see on the link validation channel can observe the correct
   validation response and click even replay it, but that response can only be
   used with the account key for which it first, or an was generated.

   An active attacker could redirect on the
      message.

   o  If validation channel can subvert the server requires a user to respond to ACME
   process, by performing normal ACME transactions and providing a message sent
   validation response for his own account key.  The risks due to
   hosting providers noted above are a
      contact address containing a secret value, then the contact
      channel will need to ensure that an attacker cannot observe particular case.  For identifiers
   where the
      secret value and spoof a message from server already has some public key associated with the contact address.

   In practice, many contact channels that
   domain this attack can be used to reach many
   clients do not provide strong assurances of prevented by requiring the types noted above.
   In designing and deploying contact-based recovery schemes, ACME
   servers operators will need client to find an appropriate balance between
   using contact channels that can reach many clients and using contact-
   based recovery schemes that achieve an appropriate level of risk
   using those contact channels.

9.4. prove
   control of the corresponding private key.

10.3.  Denial-of-Service Considerations

   As a protocol run over HTTPS, standard considerations for TCP-based
   and HTTP-based DoS mitigation also apply to ACME.

   At the application layer, ACME requires the server to perform a few
   potentially expensive operations.  Identifier validation transactions
   require the ACME server to make outbound connections to potentially
   attacker-controlled servers, and certificate issuance can require
   interactions with cryptographic hardware.

   In addition, an attacker can also cause the ACME server to send
   validation requests to a domain of its choosing by submitting
   authorization requests for the victim domain.

   All of these attacks can be mitigated by the application of
   appropriate rate limits.  Issues closer to the front end, like POST
   body validation, can be addressed using HTTP request limiting.  For
   validation and certificate requests, there are other identifiers on
   which rate limits can be keyed.  For example, the server might limit
   the rate at which any individual account key can issue certificates,
   or the rate at which validation can be requested within a given
   subtree of the DNS.

9.5.

10.4.  CA Policy Considerations

   The controls on issuance enabled by ACME are focused on validating
   that a certificate applicant controls the identifier he claims.
   Before issuing a certificate, however, there are many other checks
   that a CA might need to perform, for example:

   o  Has the client agreed to a subscriber agreement?

   o  Is the claimed identifier syntactically valid?

   o  For domain names:

      *  If the leftmost label is a '*', then have the appropriate
         checks been applied?

      *  Is the name on the Public Suffix List?

      *  Is Public Suffix List?

      *  Is the name a high-value name?

      *  Is the name a known phishing domain?

   o  Is the key in the CSR sufficiently strong?

   o  Is the CSR signed with an acceptable algorithm?

   CAs that use ACME to automate issuance will need to ensure that their
   servers perform all necessary checks before issuing.

11.  Operational Considerations

   There are certain factors that arise in operational reality that
   operators of ACME-based CAs will need to keep in mind when
   configuring their services.  For example:

   o  It is advisable to perform DNS queries via TCP to mitigate DNS
      forgery attacks over UDP

   [[ TODO: Other operational considerations ]]

11.1.  Default Virtual Hosts

   In many cases, TLS-based services are deployed on hosted platforms
   that use the Server Name Indication (SNI) TLS extension to
   distinguish between different hosted services or "virtual hosts".
   When a client initiates a TLS connection with an SNI value indicating
   a provisioned host, the hosting platform routes the connection to
   that host.

   When a connection come in with an unknown SNI value, one might expect
   the hosting platform to terminate the TLS connection.  However, some
   hosting platforms will choose a virtual host to be the "default", and
   route connections with unknown SNI values to that host.

   In such cases, the owner of the default virtual host can complete a
   TLS-based challenge (e.g., "tls-sni-02") for any domain with an A
   record that points to the hosting platform.  This could result in
   mis-issuance in cases where there are multiple hosts with different
   owners resident on the hosting platform.

   A CA that accepts TLS-based proof of domain control should attempt to
   check whether a domain is hosted on a domain with a default virtual
   host before allowing an authorization request for this host to use a
   TLS-based challenge.  A default virtual host can be detected by
   initiating TLS connections to the host with random SNI values within
   the name a high-value name?

      *  Is namespace used for the name a known phishing domain?

   o  Is TLS-based challenge (the "acme.invalid"
   namespace for "tls-sni-02").

11.2.  Use of DNSSEC Resolvers

   An ACME-based CA will often need to make DNS queries, e.g., to
   validate control of DNS names.  Because the key in security of such
   validations ultimately depends on the CSR sufficiently strong?
   o  Is authenticity of DNS data, every
   possible precaution should be taken to secure DNS queries done by the CSR signed with an acceptable algorithm?

   CAs
   CA.  It is therefore RECOMMENDED that use ACME ACME-based CAs make all DNS
   queries via DNSSEC-validating stub or recursive resolvers.  This
   provides additional protection to automate issuance will need domains which choose to ensure make use of
   DNSSEC.

   An ACME-based CA must use only a resolver if it trusts the resolver
   and every component of the network route by which it is accessed.  It
   is therefore RECOMMENDED that ACME-based CAs operate their
   servers perform own
   DNSSEC-validating resolvers within their trusted network and use
   these resolvers both for both CAA record lookups and all necessary checks before issuing.

10. record
   lookups in furtherance of a challenge scheme (A, AAAA, TXT, etc.).

12.  Acknowledgements

   In addition to the editors listed on the front page, this document
   has benefited from contributions from a broad set of contributors,
   all the way back to its inception.

   o  Peter Eckersley, EFF

   o  Eric Rescorla, Mozilla

   o  Seth Schoen, EFF
   o  Alex Halderman, University of Michigan

   o  Martin Thomson, Mozilla

   o  Jakub Warmuz, University of Oxford

   This document draws on many concepts established by Eric Rescorla's
   "Automated Certificate Issuance Protocol" draft.  Martin Thomson
   provided helpful guidance in the use of HTTP.

11.

13.  References

11.1.

13.1.  Normative References

   [I-D.ietf-appsawg-http-problem]
              mnot, m. and E. Wilde, "Problem Details for HTTP APIs",
              draft-ietf-appsawg-http-problem-01
              draft-ietf-appsawg-http-problem-03 (work in progress),
              September 2015.
              January 2016.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/
              RFC2119, 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC2314]  Kaliski, B., "PKCS #10: Certification Request Syntax
              Version 1.5", RFC 2314, DOI 10.17487/RFC2314, March 1998,
              <http://www.rfc-editor.org/info/rfc2314>.

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818,
              DOI 10.17487/RFC2818, May 2000,
              <http://www.rfc-editor.org/info/rfc2818>.

   [RFC2985]  Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object
              Classes and Attribute Types Version 2.0", RFC 2985,
              DOI 10.17487/RFC2985, November 2000,
              <http://www.rfc-editor.org/info/rfc2985>.

   [RFC2986]  Nystrom, M. and B. Kaliski, "PKCS #10: Certification
              Request Syntax Specification Version 1.7", RFC 2986,
              DOI 10.17487/RFC2986, November 2000,
              <http://www.rfc-editor.org/info/rfc2986>.

   [RFC3339]  Klyne, G. and C. Newman, "Date and Time on the Internet:
              Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
              <http://www.rfc-editor.org/info/rfc3339>.

   [RFC3986]  Berners-Lee,

   [RFC3553]  Mealling, M., Masinter, L., Hardie, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66, RFC
              3986, DOI 10.17487/RFC3986, January 2005,
              <http://www.rfc-editor.org/info/rfc3986>.

   [RFC4514]  Zeilenga, K., Ed., "Lightweight Directory Access G. Klyne, "An
              IETF URN Sub-namespace for Registered Protocol
              (LDAP): String Representation of Distinguished Names",
              Parameters", BCP 73, RFC
              4514, 3553, DOI 10.17487/RFC4514, 10.17487/RFC3553, June
              2003, <http://www.rfc-editor.org/info/rfc3553>.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006,
              <http://www.rfc-editor.org/info/rfc4514>. <http://www.rfc-editor.org/info/rfc4291>.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
              <http://www.rfc-editor.org/info/rfc4648>.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <http://www.rfc-editor.org/info/rfc5226>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/
              RFC5246, 10.17487/RFC5246, August 2008,
              <http://www.rfc-editor.org/info/rfc5246>.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <http://www.rfc-editor.org/info/rfc5280>.

   [RFC5753]  Turner, S.

   [RFC5785]  Nottingham, M. and D. Brown, "Use of Elliptic Curve
              Cryptography (ECC) Algorithms in Cryptographic Message
              Syntax (CMS)", E. Hammer-Lahav, "Defining Well-Known
              Uniform Resource Identifiers (URIs)", RFC 5753, 5785,
              DOI 10.17487/RFC5753, January 10.17487/RFC5785, April 2010, <http://www.rfc-editor.org/info/rfc5753>.
              <http://www.rfc-editor.org/info/rfc5785>.

   [RFC5988]  Nottingham, M., "Web Linking", RFC 5988,
              DOI 10.17487/
              RFC5988, 10.17487/RFC5988, October 2010,
              <http://www.rfc-editor.org/info/rfc5988>.

   [RFC6066]  Eastlake 3rd, D., "Transport Layer Security (TLS)
              Extensions: Extension Definitions", RFC 6066,
              DOI 10.17487/RFC6066, January 2011,
              <http://www.rfc-editor.org/info/rfc6066>.

   [RFC6570]  Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
              and D. Orchard, "URI Template", RFC 6570,
              DOI 10.17487/
              RFC6570, 10.17487/RFC6570, March 2012,
              <http://www.rfc-editor.org/info/rfc6570>.

   [RFC6844]  Hallam-Baker, P. and R. Stradling, "DNS Certification
              Authority Authorization (CAA) Resource Record", RFC 6844,
              DOI 10.17487/RFC6844, January 2013,
              <http://www.rfc-editor.org/info/rfc6844>.

   [RFC6962]  Laurie, B., Langley, A., and E. Kasper, "Certificate
              Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
              <http://www.rfc-editor.org/info/rfc6962>.

   [RFC7159]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
              2014, <http://www.rfc-editor.org/info/rfc7159>.

   [RFC7469]  Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
              Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April
              2015, <http://www.rfc-editor.org/info/rfc7469>.

   [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
              Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
              2015, <http://www.rfc-editor.org/info/rfc7515>.

   [RFC7517]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
              DOI 10.17487/
              RFC7517, 10.17487/RFC7517, May 2015,
              <http://www.rfc-editor.org/info/rfc7517>.

   [RFC7518]  Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
              DOI 10.17487/RFC7518, May 2015,
              <http://www.rfc-editor.org/info/rfc7518>.

   [RFC7638]  Jones, M. and N. Sakimura, "JSON Web Key (JWK)
              Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September
              2015, <http://www.rfc-editor.org/info/rfc7638>.

   [SEC1]     Standards for Efficient Cryptography Group, "SEC 1:
              Elliptic Curve Cryptography", May 2009,
              <http://www.secg.org/sec1-v2.pdf>.

11.2.

13.2.  Informative References

   [I-D.vixie-dnsext-dns0x20]
              Vixie, P. and D. Dagon, "Use of Bit 0x20 in DNS Labels to
              Improve Transaction Identity", draft-vixie-dnsext-
              dns0x20-00 (work in progress), March 2008.

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/
              RFC2818, May 2000,
              <http://www.rfc-editor.org/info/rfc2818>.

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              DOI 10.17487/RFC3552, July 2003,
              <http://www.rfc-editor.org/info/rfc3552>.

   [W3C.CR-cors-20130129]
              Kesteren, A., "Cross-Origin Resource Sharing", World Wide
              Web Consortium CR CR-cors-20130129, January 2013,
              <http://www.w3.org/TR/2013/CR-cors-20130129>.

   [W3C.WD-capability-urls-20140218]
              Tennison, J., "Good Practices for Capability URLs", World
              Wide Web Consortium WD WD-capability-urls-20140218,
              February 2014,
              <http://www.w3.org/TR/2014/WD-capability-urls-20140218>.

Authors' Addresses

   Richard Barnes
   Mozilla

   Email: rlb@ipv.sx

   Jacob Hoffman-Andrews
   EFF

   Email: jsha@eff.org

   James Kasten
   University of Michigan

   Email: jdkasten@umich.edu