idnits 2.17.1 draft-ietf-acme-ip-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 01, 2019) is 1668 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-07) exists of draft-ietf-acme-tls-alpn-06 ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACME Working Group R. Shoemaker 3 Internet-Draft ISRG 4 Intended status: Standards Track October 01, 2019 5 Expires: April 3, 2020 7 ACME IP Identifier Validation Extension 8 draft-ietf-acme-ip-08 10 Abstract 12 This document specifies identifiers and challenges required to enable 13 the Automated Certificate Management Environment (ACME) to issue 14 certificates for IP addresses. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on April 3, 2020. 33 Copyright Notice 35 Copyright (c) 2019 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 52 3. IP Identifier . . . . . . . . . . . . . . . . . . . . . . . . 2 53 4. Identifier Validation Challenges . . . . . . . . . . . . . . 3 54 5. HTTP Challenge . . . . . . . . . . . . . . . . . . . . . . . 3 55 6. TLS with Application Level Protocol Negotiation (TLS ALPN) 56 Challenge . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 7. DNS Challenge . . . . . . . . . . . . . . . . . . . . . . . . 3 58 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 59 8.1. Identifier Types . . . . . . . . . . . . . . . . . . . . 3 60 8.2. Challenge Types . . . . . . . . . . . . . . . . . . . . . 4 61 9. Security Considerations . . . . . . . . . . . . . . . . . . . 4 62 9.1. CA Policy Considerations . . . . . . . . . . . . . . . . 4 63 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 64 11. Normative References . . . . . . . . . . . . . . . . . . . . 4 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 67 1. Introduction 69 The Automatic Certificate Management Environment (ACME) [RFC8555] 70 only defines challenges for validating control of DNS host name 71 identifiers, which limits its use to being used for issuing 72 certificates for DNS identifiers. In order to allow validation of 73 IPv4 and IPv6 identifiers for inclusion in X.509 certificates, this 74 document specifies how challenges defined in the original ACME 75 specification and the TLS-ALPN extension specification 76 [I-D.ietf-acme-tls-alpn] can be used to validate IP identifiers. 78 2. Terminology 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 82 "OPTIONAL" in this document are to be interpreted as described in BCP 83 14 [RFC2119] [RFC8174] when, and only when, they appear in all 84 capitals, as shown here. 86 3. IP Identifier 88 [RFC8555] only defines the identifier type "dns", which is used to 89 refer to fully qualified domain names. If an ACME server wishes to 90 request proof that a user controls a IPv4 or IPv6 address, it MUST 91 create an authorization with the identifier type "ip". The value 92 field of the identifier MUST contain the textual form of the address 93 as defined in [RFC1123] Section 2.1 for IPv4 and in [RFC5952] 94 Section 4 for IPv6. 96 An identifier for the IPv6 address 2001:db8::1 would be formatted 97 like so: 99 {"type": "ip", "value": "2001:db8::1"} 101 4. Identifier Validation Challenges 103 IP identifiers MAY be used with the existing "http-01" (see 104 Section 8.3 of [RFC8555]) and "tls-alpn-01" (see Section 3 of 105 [I-D.ietf-acme-tls-alpn]). To use IP identifiers with these 106 challenges, their initial DNS resolution step MUST be skipped, and 107 the IP address used for validation MUST be the value of the 108 identifier. 110 5. HTTP Challenge 112 For the "http-01" challenge, the Host header field MUST be set to the 113 IP address being used for validation per [RFC7230]. The textual form 114 of this address MUST be as defined in [RFC1123] Section 2.1 for IPv4 115 and in [RFC5952] Section 4 for IPv6. 117 6. TLS with Application Level Protocol Negotiation (TLS ALPN) Challenge 119 For the "tls-alpn-01" challenge, the subjectAltName extension in the 120 validation certificate MUST contain a single iPAddress that matches 121 the address being validated. As [RFC6066] does not permit IP 122 addresses to be used in the SNI extension HostName field, the server 123 MUST instead use the IN-ADDR.ARPA [RFC1034] or IP6.ARPA [RFC3596] 124 reverse mapping of the IP address as the HostName field value instead 125 of the IP address string representation itself. For example, if the 126 IP address being validated is 2001:db8::1, the SNI HostName field 127 should contain "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d 128 .0.1.0.0.2.ip6.arpa". 130 7. DNS Challenge 132 The existing "dns-01" challenge MUST NOT be used to validate IP 133 identifiers. 135 8. IANA Considerations 137 8.1. Identifier Types 139 Adds a new type to the "ACME Identifier Types" registry defined in 140 Section 9.7.7 of [RFC8555] with Label "ip" and Reference "I-D.ietf- 141 acme-ip". 143 8.2. Challenge Types 145 Adds two new entries to the "ACME Validation Methods" registry 146 defined in Section 9.7.8 of [RFC8555]. These entries are defined 147 below: 149 +-------------+-----------------+------+------------------+ 150 | Label | Identifier Type | ACME | Reference | 151 +-------------+-----------------+------+------------------+ 152 | http-01 | ip | Y | I-D.ietf-acme-ip | 153 | | | | | 154 | tls-alpn-01 | ip | Y | I-D.ietf-acme-ip | 155 +-------------+-----------------+------+------------------+ 157 9. Security Considerations 159 The extensions to ACME described in this document do not deviate from 160 the broader threat model described in [RFC8555] Section 10.1. 162 9.1. CA Policy Considerations 164 This document only specifies how a ACME server may validate that a 165 certificate applicant controls a IP identifier at the time of 166 validation. The CA may wish to perform additional checks not 167 specified in this document. For example, if the CA believes an IP 168 identifier belongs to a ISP or cloud service provider with short 169 delegation periods, they may wish to impose additional restrictions 170 on certificates requested for that identifier. 172 10. Acknowledgments 174 The author would like to thank those who contributed to this document 175 and offered editorial and technical input, especially Jacob Hoffman- 176 Andrews and Daniel McCarney. 178 11. Normative References 180 [I-D.ietf-acme-tls-alpn] 181 Shoemaker, R., "ACME TLS ALPN Challenge Extension", draft- 182 ietf-acme-tls-alpn-06 (work in progress), September 2019. 184 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 185 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 186 . 188 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 189 Application and Support", STD 3, RFC 1123, 190 DOI 10.17487/RFC1123, October 1989, 191 . 193 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 194 Requirement Levels", BCP 14, RFC 2119, 195 DOI 10.17487/RFC2119, March 1997, 196 . 198 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 199 "DNS Extensions to Support IP Version 6", STD 88, 200 RFC 3596, DOI 10.17487/RFC3596, October 2003, 201 . 203 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 204 Address Text Representation", RFC 5952, 205 DOI 10.17487/RFC5952, August 2010, 206 . 208 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 209 Extensions: Extension Definitions", RFC 6066, 210 DOI 10.17487/RFC6066, January 2011, 211 . 213 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 214 Protocol (HTTP/1.1): Message Syntax and Routing", 215 RFC 7230, DOI 10.17487/RFC7230, June 2014, 216 . 218 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 219 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 220 May 2017, . 222 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 223 Kasten, "Automatic Certificate Management Environment 224 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 225 . 227 Author's Address 229 Roland Bracewell Shoemaker 230 Internet Security Research Group 232 Email: roland@letsencrypt.org