Tech-invite   3GPPspecs   Glossaries   IETFRFCs   Groups   SIP   ABNFs   Ti+   Search in Tech-invite

in Index   Prev   Next
in Index   None   None  Group: ACME

RFC 8555

Automatic Certificate Management Environment (ACME)

Pages: 95
Proposed STD
Errata
Part 5 of 6 – Pages 68 to 86
First   Prev   Next

Top   ToC   Page 68   prevText
9.  IANA Considerations

9.1.  Media Type: application/pem-certificate-chain

   A file of this type contains one or more certificates encoded with
   the PEM textual encoding, according to [RFC7468].  The textual
   encoding of certificates in this file MUST use the strict encoding
   and MUST NOT include explanatory text.  The ABNF for this format is
   as follows, where "stricttextualmsg" and "eol" are as defined in
   Section 3 of RFC 7468:

   certchain = stricttextualmsg *(eol stricttextualmsg)

   In order to provide easy interoperation with TLS, the first
   certificate MUST be an end-entity certificate.  Each following
   certificate SHOULD directly certify the one preceding it.  Because
   certificate validation requires that trust anchors be distributed
   independently, a certificate that represents a trust anchor MAY be
   omitted from the chain, provided that supported peers are known to
   possess any omitted certificates.

   The following has been registered in the "Media Types" registry:
   Type name: application

   Subtype name: pem-certificate-chain

   Required parameters: None

   Optional parameters: None

   Encoding considerations: 7bit

   Security considerations: Carries a cryptographic certificate and its
   associated certificate chain.  This media type carries no active
   content.

   Interoperability considerations: None

   Published specification: RFC 8555

   Applications that use this media type: ACME clients and servers, HTTP
   servers, other applications that need to be configured with a
   certificate chain

   Additional information:

      Deprecated alias names for this type: n/a
      Magic number(s): n/a
Top   ToC   Page 69
      File extension(s): .pem
      Macintosh file type code(s): n/a

   Person & email address to contact for further information: See
   Authors' Addresses section.

   Intended usage: COMMON

   Restrictions on usage: n/a

   Author: See Authors' Addresses section.

   Change controller: IETF <iesg@ietf.org>

9.2.  Well-Known URI for the HTTP Challenge

   The following value has been registered in the "Well-Known URIs"
   registry (using the template from [RFC5785]):

   URI suffix: acme-challenge

   Change controller: IETF

   Specification document(s): RFC 8555, Section 8.3

   Related information: N/A

9.3.  Replay-Nonce HTTP Header

   The following value has been registered in the "Message Headers"
   registry:

   +-------------------+----------+----------+-------------------------+
   | Header Field Name | Protocol | Status   | Reference               |
   +-------------------+----------+----------+-------------------------+
   | Replay-Nonce      | http     | standard | RFC 8555, Section 6.5.1 |
   +-------------------+----------+----------+-------------------------+
Top   ToC   Page 70
9.4.  "url" JWS Header Parameter

   The following value has been registered in the "JSON Web Signature
   and Encryption Header Parameters" registry:

   o  Header Parameter Name: "url"

   o  Header Parameter Description: URL

   o  Header Parameter Usage Location(s): JWE, JWS

   o  Change Controller: IESG

   o  Specification Document(s): RFC 8555, Section 6.4.1

9.5.  "nonce" JWS Header Parameter

   The following value has been registered in the "JSON Web Signature
   and Encryption Header Parameters" registry:

   o  Header Parameter Name: "nonce"

   o  Header Parameter Description: Nonce

   o  Header Parameter Usage Location(s): JWE, JWS

   o  Change Controller: IESG

   o  Specification Document(s): RFC 8555, Section 6.5.2

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

   The following value has been registered in the "IETF URN Sub-
   namespace for Registered Protocol Parameter Identifiers" registry,
   following the template in [RFC3553]:

   Registry name:  acme

   Specification:  RFC 8555

   Repository:  http://www.iana.org/assignments/acme

   Index value:  No transformation needed.
Top   ToC   Page 71
9.7.  New Registries

   IANA has created the following registries:

   1.  ACME Account Object Fields (Section 9.7.1)

   2.  ACME Order Object Fields (Section 9.7.2)

   3.  ACME Authorization Object Fields (Section 9.7.3)

   4.  ACME Error Types (Section 9.7.4)

   5.  ACME Resource Types (Section 9.7.5)

   6.  ACME Directory Metadata Fields (Section 9.7.6)

   7.  ACME Identifier Types (Section 9.7.7)

   8.  ACME Validation Methods (Section 9.7.8)

   All of these registries are under a heading of "Automated Certificate
   Management Environment (ACME) Protocol" and are administered under a
   Specification Required policy [RFC8126].

9.7.1.  Fields in Account Objects

   The "ACME Account Object Fields" registry lists field names that are
   defined for use in ACME account objects.  Fields marked as
   "configurable" may be included in a newAccount request.

   Template:

   o  Field name: The string to be used as a field name in the JSON
      object

   o  Field type: The type of value to be provided, e.g., string,
      boolean, array of string

   o  Requests: Either the value "none" or a list of types of requests
      where the field is allowed in a request object, taken from the
      following values:

      *  "new" - Requests to the "newAccount" URL

      *  "account" - Requests to an account URL

   o  Reference: Where this field is defined
Top   ToC   Page 72
   Initial contents: The fields and descriptions defined in
   Section 7.1.2.

   +------------------------+---------------+--------------+-----------+
   | Field Name             | Field Type    | Requests     | Reference |
   +------------------------+---------------+--------------+-----------+
   | status                 | string        | new, account | RFC 8555  |
   |                        |               |              |           |
   | contact                | array of      | new, account | RFC 8555  |
   |                        | string        |              |           |
   |                        |               |              |           |
   | externalAccountBinding | object        | new          | RFC 8555  |
   |                        |               |              |           |
   | termsOfServiceAgreed   | boolean       | new          | RFC 8555  |
   |                        |               |              |           |
   | onlyReturnExisting     | boolean       | new          | RFC 8555  |
   |                        |               |              |           |
   | orders                 | string        | none         | RFC 8555  |
   +------------------------+---------------+--------------+-----------+

9.7.2.  Fields in Order Objects

   The "ACME Order Object Fields" registry lists field names that are
   defined for use in ACME order objects.  Fields marked as
   "configurable" may be included in a newOrder request.

   Template:

   o  Field name: The string to be used as a field name in the JSON
      object

   o  Field type: The type of value to be provided, e.g., string,
      boolean, array of string

   o  Configurable: Boolean indicating whether the server should accept
      values provided by the client

   o  Reference: Where this field is defined
Top   ToC   Page 73
   Initial contents: The fields and descriptions defined in
   Section 7.1.3.

      +----------------+-----------------+--------------+-----------+
      | Field Name     | Field Type      | Configurable | Reference |
      +----------------+-----------------+--------------+-----------+
      | status         | string          | false        | RFC 8555  |
      |                |                 |              |           |
      | expires        | string          | false        | RFC 8555  |
      |                |                 |              |           |
      | identifiers    | array of object | true         | RFC 8555  |
      |                |                 |              |           |
      | notBefore      | string          | true         | RFC 8555  |
      |                |                 |              |           |
      | notAfter       | string          | true         | RFC 8555  |
      |                |                 |              |           |
      | error          | string          | false        | RFC 8555  |
      |                |                 |              |           |
      | authorizations | array of string | false        | RFC 8555  |
      |                |                 |              |           |
      | finalize       | string          | false        | RFC 8555  |
      |                |                 |              |           |
      | certificate    | string          | false        | RFC 8555  |
      +----------------+-----------------+--------------+-----------+

9.7.3.  Fields in Authorization Objects

   The "ACME Authorization Object Fields" registry lists field names
   that are defined for use in ACME authorization objects.  Fields
   marked as "configurable" may be included in a newAuthz request.

   Template:

   o  Field name: The string to be used as a field name in the JSON
      object

   o  Field type: The type of value to be provided, e.g., string,
      boolean, array of string

   o  Configurable: Boolean indicating whether the server should accept
      values provided by the client

   o  Reference: Where this field is defined
Top   ToC   Page 74
   Initial contents: The fields and descriptions defined in
   Section 7.1.4.

        +------------+-----------------+--------------+-----------+
        | Field Name | Field Type      | Configurable | Reference |
        +------------+-----------------+--------------+-----------+
        | identifier | object          | true         | RFC 8555  |
        |            |                 |              |           |
        | status     | string          | false        | RFC 8555  |
        |            |                 |              |           |
        | expires    | string          | false        | RFC 8555  |
        |            |                 |              |           |
        | challenges | array of object | false        | RFC 8555  |
        |            |                 |              |           |
        | wildcard   | boolean         | false        | RFC 8555  |
        +------------+-----------------+--------------+-----------+

9.7.4.  Error Types

   The "ACME Error Types" registry lists values that are used within URN
   values that are provided in the "type" field of problem documents in
   ACME.

   Template:

   o  Type: The label to be included in the URN for this error,
      following "urn:ietf:params:acme:error:"

   o  Description: A human-readable description of the error

   o  Reference: Where the error is defined

   Initial contents: The types and descriptions in the table in
   Section 6.7 above, with the Reference field set to point to this
   specification.

9.7.5.  Resource Types

   The "ACME Resource Types" registry lists the types of resources that
   ACME servers may list in their directory objects.

   Template:

   o  Field name: The value to be used as a field name in the directory
      object

   o  Resource type: The type of resource labeled by the field
Top   ToC   Page 75
   o  Reference: Where the resource type is defined

   Initial contents:

              +------------+--------------------+-----------+
              | Field Name | Resource Type      | Reference |
              +------------+--------------------+-----------+
              | newNonce   | New nonce          | RFC 8555  |
              |            |                    |           |
              | newAccount | New account        | RFC 8555  |
              |            |                    |           |
              | newOrder   | New order          | RFC 8555  |
              |            |                    |           |
              | newAuthz   | New authorization  | RFC 8555  |
              |            |                    |           |
              | revokeCert | Revoke certificate | RFC 8555  |
              |            |                    |           |
              | keyChange  | Key change         | RFC 8555  |
              |            |                    |           |
              | meta       | Metadata object    | RFC 8555  |
              +------------+--------------------+-----------+

9.7.6.  Fields in the "meta" Object within a Directory Object

   The "ACME Directory Metadata Fields" registry lists field names that
   are defined for use in the JSON object included in the "meta" field
   of an ACME directory object.

   Template:

   o  Field name: The string to be used as a field name in the JSON
      object

   o  Field type: The type of value to be provided, e.g., string,
      boolean, array of string

   o  Reference: Where this field is defined
Top   ToC   Page 76
   Initial contents: The fields and descriptions defined in
   Section 7.1.1.

         +-------------------------+-----------------+-----------+
         | Field Name              | Field Type      | Reference |
         +-------------------------+-----------------+-----------+
         | termsOfService          | string          | RFC 8555  |
         |                         |                 |           |
         | website                 | string          | RFC 8555  |
         |                         |                 |           |
         | caaIdentities           | array of string | RFC 8555  |
         |                         |                 |           |
         | externalAccountRequired | boolean         | RFC 8555  |
         +-------------------------+-----------------+-----------+

9.7.7.  Identifier Types

   The "ACME Identifier Types" registry lists the types of identifiers
   that can be present in ACME authorization objects.

   Template:

   o  Label: The value to be put in the "type" field of the identifier
      object

   o  Reference: Where the identifier type is defined

   Initial contents:

                           +-------+-----------+
                           | Label | Reference |
                           +-------+-----------+
                           | dns   | RFC 8555  |
                           +-------+-----------+

9.7.8.  Validation Methods

   The "ACME Validation Methods" registry lists identifiers for the ways
   that CAs can validate control of identifiers.  Each method's entry
   must specify whether it corresponds to an ACME challenge type.  The
   "Identifier Type" field must be contained in the Label column of the
   "ACME Identifier Types" registry.
Top   ToC   Page 77
   Template:

   o  Label: The identifier for this validation method

   o  Identifier Type: The type of identifier that this method applies
      to

   o  ACME: "Y" if the validation method corresponds to an ACME
      challenge type; "N" otherwise

   o  Reference: Where the validation method is defined

   This registry may also contain reserved entries (e.g., to avoid
   collisions).  Such entries should have the "ACME" field set to "N"
   and the "Identifier Type" set to "RESERVED".

   Initial Contents

            +------------+-----------------+------+-----------+
            | Label      | Identifier Type | ACME | Reference |
            +------------+-----------------+------+-----------+
            | http-01    | dns             | Y    | RFC 8555  |
            |            |                 |      |           |
            | dns-01     | dns             | Y    | RFC 8555  |
            |            |                 |      |           |
            | tls-sni-01 | RESERVED        | N    | RFC 8555  |
            |            |                 |      |           |
            | tls-sni-02 | RESERVED        | N    | RFC 8555  |
            +------------+-----------------+------+-----------+

   When evaluating a request for an assignment in this registry, the
   designated expert should ensure that the method being registered has
   a clear, interoperable definition and does not overlap with existing
   validation methods.  That is, it should not be possible for a client
   and server to follow the same set of actions to fulfill two different
   validation methods.

   The values "tls-sni-01" and "tls-sni-02" are reserved because they
   were used in pre-RFC versions of this specification to denote
   validation methods that were removed because they were found not to
   be secure in some cases.

   Validation methods do not have to be compatible with ACME in order to
   be registered.  For example, a CA might wish to register a validation
   method to support its use with the ACME extensions to CAA [ACME-CAA].
Top   ToC   Page 78
10.  Security Considerations

   ACME is a protocol for managing certificates that attest to
   identifier/key bindings.  Thus, the foremost security goal of ACME is
   to ensure the integrity of this process, i.e., to ensure that 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 an identifier can get an
       authorization for that identifier

   2.  Once authorized, an account key's authorizations cannot be
       improperly used by another account

   In this section, we discuss the threat model that underlies ACME and
   the ways that ACME achieves these security goals within that threat
   model.  We also discuss the denial-of-service risks that ACME servers
   face, and a few other miscellaneous considerations.

10.1.  Threat Model

   As a service on the Internet, ACME broadly exists within the Internet
   threat model [RFC3552].  In analyzing ACME, it is useful to think of
   an ACME server interacting with other Internet hosts along two
   "channels":

   o  An ACME channel, over which the ACME HTTPS requests are exchanged

   o  A validation channel, over which the ACME server performs
      additional requests to validate a client's control of an
      identifier
Top   ToC   Page 79
   +------------+
   |    ACME    |     ACME Channel
   |   Client   |--------------------+
   +------------+                    |
                                     V
                               +------------+
                               |    ACME    |
                               |   Server   |
                               +------------+
   +------------+                    |
   | Validation |<-------------------+
   |   Server   |  Validation Channel
   +------------+

                   Communications Channels Used by ACME

   In practice, the risks to these channels are not entirely separate,
   but they are different in most cases.  Each channel, for example,
   uses a different communications pattern: the ACME channel will
   comprise inbound HTTPS connections to the ACME server and the
   validation channel outbound HTTP or DNS requests.

   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 the ACME channel and
   one of the others.

   On the ACME channel, in addition to network-layer attackers, we also
   need to account for man-in-the-middle (MitM) attacks at the
   application layer 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 TLS MitM function.  Preventing abusive use of ACME
   means ensuring that an attacker with access to the validation channel
   can't obtain illegitimate authorization by acting as an ACME client
   (legitimately, in terms of the protocol).

   ACME does not protect against other types of abuse by a MitM on the
   ACME channel.  For example, such an attacker could send a bogus
   "badSignatureAlgorithm" error response to downgrade a client to the
   lowest-quality signature algorithm that the server supports.  A MitM
   that is present on all connections (such as a CDN) can cause denial-
   of-service conditions in a variety of ways.
Top   ToC   Page 80
10.2.  Integrity of Authorizations

   ACME allows anyone to request challenges for an identifier by
   registering an account key and sending a newOrder request using that
   account key.  The integrity of the authorization process thus depends
   on the identifier validation challenges to ensure that the challenge
   can only be completed by someone who both (1) holds the private key
   of the account key 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 a MitM on ACME HTTPS requests can switch
   out a legitimate domain holder's account key for one of his choosing.
   Such MitMs can arise, for example, if a CA uses a CDN or third-party
   reverse proxy in front of its ACME interface.  An attack by such an
   MitM could have the following form:

   1.  Legitimate domain holder registers account key pair A

   2.  MitM registers account key pair B

   3.  Legitimate domain holder sends a newOrder request signed using
       account key A

   4.  MitM suppresses the legitimate request but sends the same request
       signed using account key B

   5.  ACME server issues challenges and MitM forwards them to the
       legitimate domain holder

   6.  Legitimate domain holder provisions the validation response

   7.  ACME server performs validation query and sees the response
       provisioned by the legitimate domain holder

   8.  Because the challenges were issued in response to a message
       signed with account key B, the ACME server grants authorization
       to account key B (the MitM) instead of account key A (the
       legitimate domain holder)
Top   ToC   Page 81
   Domain                                         ACME
   Holder                  MitM                  Server
     |                      |                      |
     | newAccount(A)        |                      |
     |--------------------->|--------------------->|
     |                      |                      |
     |                      | newAccount(B)        |
     |                      |--------------------->|
     | newOrder(domain, A)  |                      |
     |--------------------->|                      |
     |                      | newOrder(domain, B)  |
     |                      |--------------------->|
     |                      |                      |
     |   authz, challenges  |   authz, challenges  |
     |<---------------------|<---------------------|
     |                      |                      |
     | response(chall, A)   | response(chall, B)   |
     |--------------------->|--------------------->|
     |                      |                      |
     |  validation request  |                      |
     |<--------------------------------------------|
     |                      |                      |
     | validation response  |                      |
     |-------------------------------------------->|
     |                      |                      |
     |                      |                      | Considers challenge
     |                      |                      | fulfilled by B
     |                      |                      |

             Man-in-the-Middle Attack Exploiting a Validation
                    Method without Account Key Binding

   All of the challenges defined in this document have a binding between
   the account private key and the validation query made by the server,
   via the key authorization.  The key authorization reflects the
   account public key and is provided to the server in the validation
   response over the validation channel.

   The association of challenges to identifiers is typically done by
   requiring the client to perform some action that only someone who
   effectively controls the identifier can perform.  For the challenges
   in this document, the actions are as follows:

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

   o  DNS: Provision DNS resource records for the domain
Top   ToC   Page 82
   There are several ways that these assumptions can be violated, both
   by misconfiguration and by attacks.  For example, on a web server
   that allows non-administrative users to write to .well-known, any
   user can claim to own the web server's hostname by responding to an
   HTTP challenge.  Similarly, if a server that can be used for ACME
   validation is compromised by a malicious actor, then that malicious
   actor can use that access to obtain certificates via ACME.

   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 a hosting provider, there is nothing that can
   be done against tampering by the hosting provider.  As far as the
   outside world is concerned, the zone or website provided by the
   hosting provider is 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 server follows HTTP
   redirects in HTTP validation and a website operator provisions a
   catch-all redirect rule that redirects requests for unknown resources
   to a different domain.  Then the target of the redirect could use
   that to get a certificate through HTTP validation since the
   validation path will not be known to the primary server.

   The 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 DNS challenge directly and can provision false
   A/AAAA records to direct the ACME server to send its HTTP validation
   query to a remote server of the attacker's choosing.  There are a few
   different mitigations that ACME servers can apply:

   o  Always querying the DNS using a DNSSEC-validating resolver
      (enhancing security 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 to requests [DNS0x20] or only using TCP

   Given these considerations, the ACME validation process makes it
   impossible for any attacker on the ACME channel or a passive attacker
   on the validation channel to hijack the authorization process to
   authorize a key of the attacker's choice.

   An attacker that can only see the ACME channel would need to convince
   the validation server to provide a response that would authorize the
   attacker's account key, but this is prevented by binding the
Top   ToC   Page 83
   validation response to the account key used to request challenges.  A
   passive attacker on the validation channel can observe the correct
   validation response and even replay it, but that response can only be
   used with the account key for which it was generated.

   An active attacker on the validation channel can subvert the ACME
   process, by performing normal ACME transactions and providing a
   validation response for his own account key.  The risks due to
   hosting providers noted above are a particular case.

   Attackers can also exploit vulnerabilities in Internet routing
   protocols to gain access to the validation channel (see, e.g.,
   [RFC7132]).  In order to make such attacks more difficult, it is
   RECOMMENDED that the server perform DNS queries and make HTTP
   connections from multiple points in the network.  Since routing
   attacks are often localized or dependent on the position of the
   attacker, forcing the attacker to attack multiple points (the
   server's validation vantage points) or a specific point (the DNS /
   HTTP server) makes it more difficult to subvert ACME validation using
   attacks on routing.

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.  And in order to prevent attackers from
   circumventing these limits simply by minting new accounts, servers
   would need to limit the rate at which accounts can be registered.
Top   ToC   Page 84
10.4.  Server-Side Request Forgery

   Server-Side Request Forgery (SSRF) attacks can arise when an attacker
   can cause a server to perform HTTP requests to an attacker-chosen
   URL.  In the ACME HTTP challenge validation process, the ACME server
   performs an HTTP GET request to a URL in which the attacker can
   choose the domain.  This request is made before the server has
   verified that the client controls the domain, so any client can cause
   a query to any domain.

   Some ACME server implementations include information from the
   validation server's response (in order to facilitate debugging).
   Such implementations enable an attacker to extract this information
   from any web server that is accessible to the ACME server, even if it
   is not accessible to the ACME client.  For example, the ACME server
   might be able to access servers behind a firewall that would prevent
   access by the ACME client.

   It might seem that the risk of SSRF through this channel is limited
   by the fact that the attacker can only control the domain of the URL,
   not the path.  However, if the attacker first sets the domain to one
   they control, then they can send the server an HTTP redirect (e.g., a
   302 response) which will cause the server to query an arbitrary URL.

   In order to further limit the SSRF risk, ACME server operators should
   ensure that validation queries can only be sent to servers on the
   public Internet, and not, say, web services within the server
   operator's internal network.  Since the attacker could make requests
   to these public servers himself, he can't gain anything extra through
   an SSRF attack on ACME aside from a layer of anonymization.

10.5.  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?
Top   ToC   Page 85
      *  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?

   o  Has issuance been authorized or forbidden by a Certification
      Authority Authorization (CAA) record ([RFC6844])?

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

   CAs using ACME to allow clients to agree to terms of service should
   keep in mind that ACME clients can automate this agreement, possibly
   not involving a human user.

   ACME does not specify how the server constructs the URLs that it uses
   to address resources.  If the server operator uses URLs that are
   predictable to third parties, this can leak information about what
   URLs exist on the server, since an attacker can probe for whether a
   POST-as-GET request to the URL returns 404 (Not Found) or 401
   (Unauthorized).

   For example, suppose that the CA uses highly structured URLs with
   guessable fields:

   o  Accounts: https://example.com/:accountID

   o  Orders: https://example.com/:accountID/:domainName

   o  Authorizations: https://example.com/:accountID/:domainName

   o  Certificates: https://example.com/:accountID/:domainName

   Under that scheme, an attacker could probe for which domain names are
   associated with which accounts, which may allow correlation of
   ownership between domain names, if the CA does not otherwise permit
   it.
Top   ToC   Page 86
   To avoid leaking these correlations, CAs SHOULD assign URLs with an
   unpredictable component.  For example, a CA might assign URLs for
   each resource type from an independent namespace, using unpredictable
   IDs for each resource:

   o  Accounts: https://example.com/acct/:accountID

   o  Orders: https://example.com/order/:orderID

   o  Authorizations: https://example.com/authz/:authorizationID

   o  Certificates: https://example.com/cert/:certID

   Such a scheme would leak only the type of resource, hiding the
   additional correlations revealed in the example above.



(page 86 continued on part 6)

Next Section