RFC 8738

Automated Certificate Management Environment (ACME) IP Identifier Validation Extension

📅 published February 2020, from ietf

💖 RFC 8738: ACME IP Identifier Validation Extension 💖

Bestie, this one is SO iconic. ✨ It's a Standards Track doc from February 2020 by R.B. Shoemaker at ISRG (Roland Bracewell Shoemaker, roland@letsencrypt.org), and it doesn't obsolete or update anything. 🎀 It's an Internet Standards Track document, which means it went through public review and got approved by the IESG. 💅

The whole point? ACME was originally only built to issue certs for DNS names, and this doc is the glow-up that lets it issue certs for IPv4 and IPv6 addresses too. 🦋 Copyright is IETF Trust, 2020, all rights reserved. 🌸

1. Introduction ✨

Okay so, the Automatic Certificate Management Environment (ACME) [RFC8555] only defines challenges for proving you control DNS host names, which means it can only issue certificates for DNS identifiers. 🙈 Kind of a bummer, right? This document fixes that by explaining how the challenges from original ACME and the TLS-ALPN extension [RFC8737] can be used to validate IP identifiers, so the certs can cover IPv4 and IPv6 addresses. 💜

2. Terminology 🎀

Here's the vibe check on the key words: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are only to be read as described in BCP 14 [RFC2119] [RFC8174] when they show up in ALL CAPS, exactly like that. 🫶

3. IP Identifier 🌈

[RFC8555] only defines the identifier type "dns", which is for fully qualified domain names. 💀 So if an ACME server wants proof that a user controls an IPv4 or IPv6 address, it MUST create an authorization with the identifier type "ip". 👑 The value field MUST hold the textual form of the address: as defined in Section 2.1 of [RFC1123] for IPv4, and in Section 4 of [RFC5952] for IPv6. 🔥

Here's what an identifier for the IPv6 address 2001:db8::1 looks like:

{"type": "ip", "value": "2001:db8::1"}

4. Identifier Validation Challenges 🦋

IP identifiers MAY be used with the existing "http-01" (see Section 8.3 of [RFC8555]) and "tls-alpn-01" (see Section 3 of [RFC8737]) challenges. 🧚 To use IP identifiers with these, their initial DNS resolution step MUST be skipped, and the IP address used for validation MUST be the value of the identifier. 💅

5. HTTP Challenge 🌸

For the "http-01" challenge, the Host header field MUST be set to the IP address being validated, per [RFC7230]. 🍓 The textual form of that address MUST be as defined in Section 2.1 of [RFC1123] for IPv4 and in Section 4 of [RFC5952] for IPv6. ✨

6. TLS with Application-Layer Protocol Negotiation (TLS ALPN) Challenge 💜

For the "tls-alpn-01" challenge, the subjectAltName extension in the validation certificate MUST contain a single iPAddress that matches the address being validated. 🫶 But here's the twist: [RFC6066] doesn't allow IP addresses in the Server Name Indication (SNI) extension HostName field. 🙈 So the server MUST instead use the IN-ADDR.ARPA [RFC1034] or IP6.ARPA [RFC3596] reverse mapping of the IP address as the HostName field value, rather than the IP address string itself. 🔥 For example, if the IP address being validated is 2001:db8::1, the SNI HostName field should contain the following (the trailing period is on its own line in the original, shown here as written):

"1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa"
.

7. DNS Challenge 👑

The existing "dns-01" challenge MUST NOT be used to validate IP identifiers. 🚫 Absolutely not, no cap. 💀

8. IANA Considerations 🎀

8.1. Identifier Types 🌈

Per this document, a new type has been added to the "ACME Identifier Types" registry defined in Section 9.7.7 of [RFC8555], with Label "ip" and Reference "RFC 8738". 💖

8.2. Challenge Types 🦋

Per this document, two new entries have been added to the "ACME Validation Methods" registry defined in Section 9.7.8 of [RFC8555]. 💅 They look like this:

+-------------+-----------------+------+-----------+
| Label       | Identifier Type | ACME | Reference |
+=============+=================+======+===========+
| http-01     | ip              | Y    | RFC 8738  |
+-------------+-----------------+------+-----------+
| tls-alpn-01 | ip              | Y    | RFC 8738  |
+-------------+-----------------+------+-----------+

                     Table 1

9. Security Considerations 🔥

Okay, bestie, this part is SERIOUS, so read it carefully. 😭 The extensions to ACME described in this document do not deviate from the broader threat model described in Section 10.1 of [RFC8555]. 🛡️

9.1. Certification Authority (CA) Policy Considerations 👑

This document only specifies how an ACME server may validate that a certificate applicant controls an IP identifier at the time of validation. ✨ The CA may wish to perform additional checks that aren't specified here. 🙈 For example, if the CA believes an IP identifier belongs to an ISP or cloud service provider with short delegation periods, they may wish to impose additional restrictions on certificates requested for that identifier. 🌸

10. Normative References 💜

Acknowledgments 🫶

The author would like to thank everyone who contributed to this document and offered editorial and technical input, especially Jacob Hoffman-Andrews and Daniel McCarney. 💖

Author's Address 🎀

Roland Bracewell Shoemaker Internet Security Research Group

Email: roland@letsencrypt.org 💌

📦 where this page comes from