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

   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

   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

              National Institute of Standards and Technology (NIST),
              "Secure Hash Standard (SHS)", FIPS PUB 180-4,
              DOI 10.6028/NIST.FIPS.180-4, August 2015,
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

              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.

              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


   Jacob Hoffman-Andrews


   Daniel McCarney
   Let's Encrypt


   James Kasten
   University of Michigan