Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 8555

Automatic Certificate Management Environment (ACME)

Pages: 95
Proposed Standard
Part 6 of 6 – Pages 86 to 95
First   Prev   None

Top   ToC   RFC8555 - Page 86   prevText

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. See the subsections below for examples.

11.1. Key Selection

ACME relies on two different classes of key pair: o Account key pairs, which are used to authenticate account holders o Certificate key pairs, which are used to sign and verify CSRs (and whose public keys are included in certificates) Compromise of the private key of an account key pair has more serious consequences than compromise of a private key corresponding to a certificate. While the compromise of a certificate key pair allows the attacker to impersonate the entities named in the certificate for the lifetime of the certificate, the compromise of an account key pair allows the attacker to take full control of the victim's ACME account and take any action that the legitimate account holder could take within the scope of ACME: 1. Issuing certificates using existing authorizations 2. Revoking existing certificates 3. Accessing and changing account information (e.g., contacts) 4. Changing the account key pair for the account, locking out the legitimate account holder
Top   ToC   RFC8555 - Page 87
   For this reason, it is RECOMMENDED that each account key pair be used
   only for authentication of a single ACME account.  For example, the
   public key of an account key pair MUST NOT be included in a
   certificate.  If an ACME client receives a request from a user for
   account creation or key rollover using an account key that the client
   knows to be used elsewhere, then the client MUST return an error.
   Clients MUST generate a fresh account key for every account creation
   or rollover operation.  Note that given the requirements of
   Section 7.3.1, servers will not create accounts with reused keys

   ACME clients and servers MUST verify that a CSR submitted in a
   finalize request does not contain a public key for any known account
   key pair.  In particular, when a server receives a finalize request,
   it MUST verify that the public key in a CSR is not the same as the
   public key of the account key pair used to authenticate that request.
   This assures that vulnerabilities in the protocols with which the
   certificate is used (e.g., signing oracles in TLS [JSS15]) do not
   result in compromise of the ACME account.  Because ACME accounts are
   uniquely identified by their account key pair (see Section 7.3.1),
   the server MUST not allow account key pair reuse across multiple

11.2. DNS Security

As noted above, DNS forgery attacks against the ACME server can result in the server making incorrect decisions about domain control and thus mis-issuing certificates. Servers SHOULD perform DNS queries over TCP, which provides better resistance to some forgery attacks than DNS over UDP. An ACME-based CA will often need to make DNS queries, e.g., to validate control of DNS names. Because the security of such validations ultimately depends on the authenticity of DNS data, every possible precaution should be taken to secure DNS queries done by the CA. Therefore, it is RECOMMENDED that ACME-based CAs make all DNS queries via DNSSEC-validating stub or recursive resolvers. This provides additional protection to domains that choose to make use of DNSSEC. An ACME-based CA must only use a resolver if it trusts the resolver and every component of the network route by which it is accessed. Therefore, it is RECOMMENDED that ACME-based CAs operate their own DNSSEC-validating resolvers within their trusted network and use these resolvers both for CAA record lookups and all record lookups in furtherance of a challenge scheme (A, AAAA, TXT, etc.).
Top   ToC   RFC8555 - Page 88

11.3. Token Entropy

The http-01 and dns-01 validation methods mandate the use of a random token value to uniquely identify the challenge. The value of the token is required to contain at least 128 bits of entropy for the following security properties. First, the ACME client should not be able to influence the ACME server's choice of token as this may allow an attacker to reuse a domain owner's previous challenge responses for a new validation request. Second, the entropy requirement makes it more difficult for ACME clients to implement a "naive" validation server that automatically replies to challenges without being configured per challenge.

11.4. Malformed Certificate Chains

ACME provides certificate chains in the widely used format known colloquially as PEM (though it may diverge from the actual Privacy Enhanced Mail specification [RFC1421], as noted in [RFC7468]). Some current software will allow the configuration of a private key and a certificate in one PEM file by concatenating the textual encodings of the two objects. In the context of ACME, such software might be vulnerable to key replacement attacks. A malicious ACME server could cause a client to use a private key of its choosing by including the key in the PEM file returned in response to a query for a certificate URL. When processing a file of type "application/pem-certificate-chain", a client SHOULD verify that the file contains only encoded certificates. If anything other than a certificate is found (i.e., if the string "-----BEGIN" is ever followed by anything other than "CERTIFICATE"), then the client MUST reject the file as invalid.

12. References

12.1. Normative References

[FIPS180-4] National Institute of Standards and Technology (NIST), "Secure Hash Standard (SHS)", FIPS PUB 180-4, DOI 10.6028/NIST.FIPS.180-4, August 2015, < fips-180-4.pdf>.
Top   ToC   RFC8555 - Page 89
   [JSS15]    Somorovsky, J., Schwenk, J., and J. Somorovsky, "On the
              Security of TLS 1.3 and QUIC Against Weaknesses in PKCS#1
              v1.5 Encryption", CSS '15 Proceedings of the 22nd ACM
              SIGSAC Conference on Computer and Communications
              Security Pages 1185-1196, DOI 10.1145/2810103.2813657,

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

   [RFC2585]  Housley, R. and P. Hoffman, "Internet X.509 Public Key
              Infrastructure Operational Protocols: FTP and HTTP",
              RFC 2585, DOI 10.17487/RFC2585, May 1999,

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818,
              DOI 10.17487/RFC2818, May 2000,

   [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,

   [RFC2986]  Nystrom, M. and B. Kaliski, "PKCS #10: Certification
              Request Syntax Specification Version 1.7", RFC 2986,
              DOI 10.17487/RFC2986, November 2000,

   [RFC3339]  Klyne, G. and C. Newman, "Date and Time on the Internet:
              Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
              2003, <>.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,

   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", BCP 106, RFC 4086,
              DOI 10.17487/RFC4086, June 2005,
Top   ToC   RFC8555 - Page 90
   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,

   [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,

   [RFC5751]  Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
              Mail Extensions (S/MIME) Version 3.2 Message
              Specification", RFC 5751, DOI 10.17487/RFC5751, January
              2010, <>.

   [RFC5890]  Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Definitions and Document Framework",
              RFC 5890, DOI 10.17487/RFC5890, August 2010,

   [RFC6068]  Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'
              URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010,

   [RFC6570]  Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
              and D. Orchard, "URI Template", RFC 6570,
              DOI 10.17487/RFC6570, March 2012,

   [RFC6844]  Hallam-Baker, P. and R. Stradling, "DNS Certification
              Authority Authorization (CAA) Resource Record", RFC 6844,
              DOI 10.17487/RFC6844, January 2013,

   [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
              DOI 10.17487/RFC7231, June 2014,

   [RFC7468]  Josefsson, S. and S. Leonard, "Textual Encodings of PKIX,
              PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468,
              April 2015, <>.
Top   ToC   RFC8555 - Page 91
   [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
              Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
              2015, <>.

   [RFC7518]  Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
              DOI 10.17487/RFC7518, May 2015,

   [RFC7638]  Jones, M. and N. Sakimura, "JSON Web Key (JWK)
              Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September
              2015, <>.

   [RFC7797]  Jones, M., "JSON Web Signature (JWS) Unencoded Payload
              Option", RFC 7797, DOI 10.17487/RFC7797, February 2016,

   [RFC7807]  Nottingham, M. and E. Wilde, "Problem Details for HTTP
              APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016,

   [RFC8037]  Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH)
              and Signatures in JSON Object Signing and Encryption
              (JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017,

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <>.

   [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", STD 90, RFC 8259,
              DOI 10.17487/RFC8259, December 2017,

   [RFC8288]  Nottingham, M., "Web Linking", RFC 8288,
              DOI 10.17487/RFC8288, October 2017,

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
Top   ToC   RFC8555 - Page 92

12.2. Informative References

[ACME-CAA] Landau, H., "CAA Record Extensions for Account URI and ACME Method Binding", Work in Progress, draft-ietf-acme- caa-06, January 2019. [ACME-IP] Shoemaker, R., "ACME IP Identifier Validation Extension", Work in Progress, draft-ietf-acme-ip-05, February 2019. [ACME-TELEPHONE] Peterson, J. and R. Barnes, "ACME Identifiers and Challenges for Telephone Numbers", Work in Progress, draft-ietf-acme-telephone-01, October 2017. [CABFBR] CA/Browser Forum, "CA/Browser Forum Baseline Requirements", September 2018, <>. [DNS0x20] Vixie, P. and D. Dagon, "Use of Bit 0x20 in DNS Labels to Improve Transaction Identity", Work in Progress, draft-vixie-dnsext-dns0x20-00, March 2008. [RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures", RFC 1421, DOI 10.17487/RFC1421, February 1993, <>. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, <>. [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June 2003, <>. [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, DOI 10.17487/RFC5785, April 2010, <>. [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, DOI 10.17487/RFC6960, June 2013, <>.
Top   ToC   RFC8555 - Page 93
   [RFC7132]  Kent, S. and A. Chi, "Threat Model for BGP Path Security",
              RFC 7132, DOI 10.17487/RFC7132, February 2014,

   [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
              "Recommendations for Secure Use of Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
              2015, <>.

              Kesteren, A., Ed., "Cross-Origin Resource Sharing", W3C
              Recommendation REC-cors-20140116, January 2014,
Top   ToC   RFC8555 - Page 94


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 Andrew Ayer, SSLMate o Karthik Bhargavan, INRIA o Peter Eckersley, EFF o Alex Halderman, University of Michigan o Sophie Herold, Hemio o Tim Hollebeek, DigiCert o Eric Rescorla, Mozilla o Seth Schoen, EFF o Roland Shoemaker, Let's Encrypt o Rob Stradling, Sectigo 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.
Top   ToC   RFC8555 - Page 95

Authors' Addresses

Richard Barnes Cisco Email: Jacob Hoffman-Andrews EFF Email: Daniel McCarney Let's Encrypt Email: James Kasten University of Michigan Email: