Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8555

Automatic Certificate Management Environment (ACME)

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

Top   ToC   RFC8555 - 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   RFC8555 - 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   RFC8555 - 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   RFC8555 - 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   RFC8555 - 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   RFC8555 - 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   RFC8555 - 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   RFC8555 - 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   RFC8555 - 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   RFC8555 - 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   RFC8555 - 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   RFC8555 - 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   RFC8555 - 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   RFC8555 - 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   RFC8555 - 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   RFC8555 - 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   RFC8555 - 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   RFC8555 - 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   RFC8555 - 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