idnits 2.17.1 draft-ietf-acme-ip-05.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. 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 (February 14, 2019) is 1897 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) == Unused Reference: 'FIPS180-4' is defined on line 153, but no explicit reference was found in the text == Unused Reference: 'RFC4291' is defined on line 188, but no explicit reference was found in the text == Unused Reference: 'RFC4648' is defined on line 192, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS180-4' == 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: 2 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). 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 February 14, 2019 5 Expires: August 18, 2019 7 ACME IP Identifier Validation Extension 8 draft-ietf-acme-ip-05 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 August 18, 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 . . . . . . . . . . . . . . . . . . . . . 3 61 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 62 10. Normative References . . . . . . . . . . . . . . . . . . . . 4 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 65 1. Introduction 67 The Automatic Certificate Management Environment (ACME) 68 [I-D.ietf-acme-acme] only defines challenges for validating control 69 of DNS host name identifiers which limits its use to being used for 70 issuing certificates for DNS identifiers. In order to allow 71 validation of IPv4 and IPv6 identifiers for inclusion in X.509 72 certificates this document specifies how challenges defined in the 73 original ACME specification and the TLS-ALPN extension specification 74 [I-D.ietf-acme-tls-alpn] can be used to validate IP identifiers. 76 2. Terminology 78 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 79 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 80 and "OPTIONAL" are to be interpreted as described in BCP 14, 81 [RFC2119]. 83 3. IP Identifier 85 [I-D.ietf-acme-acme] only defines the identifier type "dns" which is 86 used to refer to fully qualified domain names. If a ACME server 87 wishes to request proof that a user controls a IPv4 or IPv6 address 88 it MUST create an authorization with the identifier type "ip". The 89 value field of the identifier MUST contain the textual form of the 90 address as defined in [RFC1123] Section 2.1 for IPv4 and in [RFC5952] 91 Section 4 for IPv6. 93 An identifier for the IPv6 address 2001:db8::1 would be formatted 94 like so: 96 {"type": "ip", "value": "2001:db8::1"} 98 4. Identifier Validation Challenges 100 IP identifiers MAY be used with the existing "http-01" and "tls-alpn- 101 01" challenges from [I-D.ietf-acme-acme] Section 8.3 and 102 [I-D.ietf-acme-tls-alpn] Section 3 respectively. To use IP 103 identifiers with these challenges their initial DNS resolution step 104 MUST be skipped and the IP address used for validation MUST be the 105 value of the identifier. 107 5. HTTP Challenge 109 For the "http-01" challenge the Host header MUST be set to the IP 110 address being used for validation per [RFC7230]. The textual form of 111 this address MUST be those defined in [RFC1123] Section 2.1 for IPv4 112 and in [RFC5952] Section 4 for IPv6. 114 6. TLS with Application Level Protocol Negotiation (TLS ALPN) Challenge 116 For the "tls-alpn-01" challenge the subjectAltName extension in the 117 validation certificate MUST contain a single iPAddress which matches 118 the address being validated. As [RFC6066] does not permit IP 119 addresses to be used in the SNI extension HostName the server MUST 120 instead use the IN-ADDR.ARPA [RFC1034] or IP6.ARPA [RFC3596] reverse 121 mapping of the IP address as the HostName value instead of the 122 literal IP address. For example if the IP address being validated is 123 2001:db8::1 the SNI HostName should contain "1.0.0.0.0.0.0.0.0.0.0.0. 124 0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.". 126 7. DNS Challenge 128 The existing "dns-01" challenge MUST NOT be used to validate IP 129 identifiers. 131 8. IANA Considerations 133 8.1. Identifier Types 135 Adds a new type to the Identifier list defined in Section 9.7.7 of 136 [I-D.ietf-acme-acme] with the label "ip" and reference I-D.ietf-acme- 137 ip. 139 8.2. Challenge Types 141 Adds the value "ip" to the Identifier Type column in the Validation 142 Methods list defined in Section 9.7.8 of [I-D.ietf-acme-acme] for the 143 "http-01" and "tls-alpn-01" challenges. 145 9. Acknowledgments 147 The author would like to thank those who contributed to this document 148 and offered editorial and technical input, especially Jacob Hoffman- 149 Andrews and Daniel McCarney. 151 10. Normative References 153 [FIPS180-4] 154 Department of Commerce, National., "NIST FIPS 180-4, 155 Secure Hash Standard", March 2012, 156 . 159 [I-D.ietf-acme-acme] 160 Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 161 Kasten, "Automatic Certificate Management Environment 162 (ACME)", draft-ietf-acme-acme-18 (work in progress), 163 December 2018. 165 [I-D.ietf-acme-tls-alpn] 166 Shoemaker, R., "ACME TLS ALPN Challenge Extension", draft- 167 ietf-acme-tls-alpn-05 (work in progress), August 2018. 169 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 170 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 171 . 173 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 174 Application and Support", STD 3, RFC 1123, 175 DOI 10.17487/RFC1123, October 1989, 176 . 178 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 179 Requirement Levels", BCP 14, RFC 2119, 180 DOI 10.17487/RFC2119, March 1997, 181 . 183 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 184 "DNS Extensions to Support IP Version 6", STD 88, 185 RFC 3596, DOI 10.17487/RFC3596, October 2003, 186 . 188 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 189 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 190 2006, . 192 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 193 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 194 . 196 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 197 Address Text Representation", RFC 5952, 198 DOI 10.17487/RFC5952, August 2010, 199 . 201 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 202 Extensions: Extension Definitions", RFC 6066, 203 DOI 10.17487/RFC6066, January 2011, 204 . 206 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 207 Protocol (HTTP/1.1): Message Syntax and Routing", 208 RFC 7230, DOI 10.17487/RFC7230, June 2014, 209 . 211 Author's Address 213 Roland Bracewell Shoemaker 214 Internet Security Research Group 216 Email: roland@letsencrypt.org