idnits 2.17.1 draft-ietf-acme-ip-06.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (May 22, 2019) is 1793 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-05 ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 1 error (**), 0 flaws (~~), 3 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 May 22, 2019 5 Expires: November 23, 2019 7 ACME IP Identifier Validation Extension 8 draft-ietf-acme-ip-06 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 November 23, 2019. 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 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 81 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 82 and "OPTIONAL" are to be interpreted as described in BCP 14, 83 [RFC2119]. 85 3. IP Identifier 87 [RFC8555] only defines the identifier type "dns" which is used to 88 refer to fully qualified domain names. If a ACME server wishes to 89 request proof that a user controls a IPv4 or IPv6 address it MUST 90 create an authorization with the identifier type "ip". The value 91 field of the identifier MUST contain the textual form of the address 92 as defined in [RFC1123] Section 2.1 for IPv4 and in [RFC5952] 93 Section 4 for IPv6. 95 An identifier for the IPv6 address 2001:db8::1 would be formatted 96 like so: 98 {"type": "ip", "value": "2001:db8::1"} 100 4. Identifier Validation Challenges 102 IP identifiers MAY be used with the existing "http-01" and "tls-alpn- 103 01" challenges from [RFC8555] Section 8.3 and 104 [I-D.ietf-acme-tls-alpn] Section 3 respectively. To use IP 105 identifiers with these challenges their initial DNS resolution step 106 MUST be skipped and the IP address used for validation MUST be the 107 value of the identifier. 109 5. HTTP Challenge 111 For the "http-01" challenge the Host header MUST be set to the IP 112 address being used for validation per [RFC7230]. The textual form of 113 this address MUST be those defined in [RFC1123] Section 2.1 for IPv4 114 and in [RFC5952] Section 4 for IPv6. 116 6. TLS with Application Level Protocol Negotiation (TLS ALPN) Challenge 118 For the "tls-alpn-01" challenge the subjectAltName extension in the 119 validation certificate MUST contain a single iPAddress which matches 120 the address being validated. As [RFC6066] does not permit IP 121 addresses to be used in the SNI extension HostName field the server 122 MUST instead use the IN-ADDR.ARPA [RFC1034] or IP6.ARPA [RFC3596] 123 reverse mapping of the IP address as the HostName field value instead 124 of the IP address string representation itself. For example if the 125 IP address being validated is 2001:db8::1 the SNI HostName field 126 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 127 .0.1.0.0.2.ip6.arpa.". 129 7. DNS Challenge 131 The existing "dns-01" challenge MUST NOT be used to validate IP 132 identifiers. 134 8. IANA Considerations 136 8.1. Identifier Types 138 Adds a new type to the "ACME Identifier Types" registry defined in 139 Section 9.7.7 of [RFC8555] with Label "ip" and Reference "I-D.ietf- 140 acme-ip". 142 8.2. Challenge Types 144 Adds two new entries to the "ACME Validation Methods" registry 145 defined in Section 9.7.8 of [RFC8555]. These entries are defined 146 below: 148 +-------------+-----------------+------+------------------+ 149 | Label | Identifier Type | ACME | Reference | 150 +-------------+-----------------+------+------------------+ 151 | http-01 | ip | Y | I-D.ietf-acme-ip | 152 | | | | | 153 | tls-alpn-01 | ip | Y | I-D.ietf-acme-ip | 154 +-------------+-----------------+------+------------------+ 156 9. Security Considerations 158 The extensions to ACME described in this document do not deviate from 159 the broader threat model described in [RFC8555] Section 10.1. 161 9.1. CA Policy Considerations 163 This document only specifies how a ACME server may validate that a 164 certificate applicant controls a IP identifier at the time of 165 validation. The CA may wish to perform additional checks not 166 specified in this document. For example if the CA believes an IP 167 identifier belongs to a ISP or cloud service provider with short 168 delegation periods they may wish to impose additional restrictions on 169 certificates requested for that identifier. 171 10. Acknowledgments 173 The author would like to thank those who contributed to this document 174 and offered editorial and technical input, especially Jacob Hoffman- 175 Andrews and Daniel McCarney. 177 11. Normative References 179 [I-D.ietf-acme-tls-alpn] 180 Shoemaker, R., "ACME TLS ALPN Challenge Extension", draft- 181 ietf-acme-tls-alpn-05 (work in progress), August 2018. 183 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 184 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 185 . 187 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 188 Application and Support", STD 3, RFC 1123, 189 DOI 10.17487/RFC1123, October 1989, 190 . 192 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 193 Requirement Levels", BCP 14, RFC 2119, 194 DOI 10.17487/RFC2119, March 1997, 195 . 197 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 198 "DNS Extensions to Support IP Version 6", STD 88, 199 RFC 3596, DOI 10.17487/RFC3596, October 2003, 200 . 202 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 203 Address Text Representation", RFC 5952, 204 DOI 10.17487/RFC5952, August 2010, 205 . 207 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 208 Extensions: Extension Definitions", RFC 6066, 209 DOI 10.17487/RFC6066, January 2011, 210 . 212 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 213 Protocol (HTTP/1.1): Message Syntax and Routing", 214 RFC 7230, DOI 10.17487/RFC7230, June 2014, 215 . 217 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 218 Kasten, "Automatic Certificate Management Environment 219 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 220 . 222 Author's Address 224 Roland Bracewell Shoemaker 225 Internet Security Research Group 227 Email: roland@letsencrypt.org