idnits 2.17.1 draft-ietf-acme-ip-04.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 (July 27, 2018) is 2100 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 148, but no explicit reference was found in the text == Unused Reference: 'RFC4648' is defined on line 187, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS180-4' == Outdated reference: A later version (-18) exists of draft-ietf-acme-acme-13 == Outdated reference: A later version (-07) exists of draft-ietf-acme-tls-alpn-01 ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 1 error (**), 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 July 27, 2018 5 Expires: January 28, 2019 7 ACME IP Identifier Validation Extension 8 draft-ietf-acme-ip-04 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 January 28, 2019. 33 Copyright Notice 35 Copyright (c) 2018 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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 55 5.1. Identifier Types . . . . . . . . . . . . . . . . . . . . 3 56 5.2. Challenge Types . . . . . . . . . . . . . . . . . . . . . 3 57 6. Security Considerations . . . . . . . . . . . . . . . . . . . 3 58 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 59 8. Normative References . . . . . . . . . . . . . . . . . . . . 4 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 62 1. Introduction 64 The Automatic Certificate Management Environment (ACME) 65 [I-D.ietf-acme-acme] only defines challenges for validating control 66 of DNS host name identifiers which limits its use to being used for 67 issuing certificates for DNS identifiers. In order to allow 68 validation of IPv4 and IPv6 identifiers for inclusion in X.509 69 certificates this document specifies how challenges defined in the 70 original ACME specification and the TLS-ALPN extension specification 71 [I-D.ietf-acme-tls-alpn] can be used to validate IP identifiers. 73 2. Terminology 75 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 76 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 77 and "OPTIONAL" are to be interpreted as described in BCP 14, 78 [RFC2119]. 80 3. IP Identifier 82 [I-D.ietf-acme-acme] only defines the identifier type "dns" which is 83 used to refer to fully qualified domain names. If a ACME server 84 wishes to request proof that a user controls a IPv4 or IPv6 address 85 it MUST create an authorization with the identifier type "ip". The 86 value field of the identifier MUST contain the textual form of the 87 address as defined in [RFC1123] Section 2.1 for IPv4 and in [RFC4291] 88 Section 2.2 for IPv6. 90 An identifier for the IPv6 address 2001:db8::1 would be formatted 91 like so: 93 {"type": "ip", "value": "2001:db8::1"} 95 4. Identifier Validation Challenges 97 IP identifiers MAY be used with the existing "http-01" and "tls-alpn- 98 01" challenges from [I-D.ietf-acme-acme] Section 8.3 and 99 [I-D.ietf-acme-tls-alpn] Section 3 respectively. To use IP 100 identifiers with these challenges their initial DNS resolution step 101 MUST be skipped and the IP address used for validation MUST be the 102 value of the identifier. 104 For the "http-01" challenge the Host header MUST be set to the IP 105 address being used for validation per [RFC7230]. 107 For the "tls-alpn-01" the subjectAltName extension in the validation 108 certificate MUST contain a single iPAddress which matches the address 109 being validated. As [RFC6066] does not permit IP addresses to be 110 used in the SNI extension the server MUST instead use the IN- 111 ADDR.ARPA [RFC1034] or IP6.ARPA [RFC3596] reverse mapping of the IP 112 address as the SNI value instead of the literal IP address. 114 The existing "dns-01" challenge MUST NOT be used to validate IP 115 identifiers. 117 5. IANA Considerations 119 5.1. Identifier Types 121 Adds a new type to the Identifier list defined in Section 9.7.7 of 122 [I-D.ietf-acme-acme] with the label "ip" and reference I-D.ietf-acme- 123 ip. 125 5.2. Challenge Types 127 Adds the value "ip" to the Identifier Type column in the Validation 128 Methods list defined in Section 9.7.8 of [I-D.ietf-acme-acme] for the 129 "http-01" and "tls-alpn-01" challenges. 131 6. Security Considerations 133 Given the often short delegation periods for IP addresses provided by 134 various service providers CAs MAY want to impose shorter lifetimes 135 for certificates which contain IP identifiers. They MAY also impose 136 restrictions on IP identifiers which are in CIDRs known to be 137 assigned to service providers who dynamically assign addresses to 138 users for indeterminate periods of time. 140 7. Acknowledgments 142 The author would like to thank those who contributed to this document 143 and offered editorial and technical input, especially Jacob Hoffman- 144 Andrews and Daniel McCarney. 146 8. Normative References 148 [FIPS180-4] 149 Department of Commerce, National., "NIST FIPS 180-4, 150 Secure Hash Standard", March 2012, 151 . 154 [I-D.ietf-acme-acme] 155 Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 156 Kasten, "Automatic Certificate Management Environment 157 (ACME)", draft-ietf-acme-acme-13 (work in progress), July 158 2018. 160 [I-D.ietf-acme-tls-alpn] 161 Shoemaker, R., "ACME TLS ALPN Challenge Extension", draft- 162 ietf-acme-tls-alpn-01 (work in progress), May 2018. 164 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 165 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 166 . 168 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 169 Application and Support", STD 3, RFC 1123, 170 DOI 10.17487/RFC1123, October 1989, 171 . 173 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 174 Requirement Levels", BCP 14, RFC 2119, 175 DOI 10.17487/RFC2119, March 1997, 176 . 178 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 179 "DNS Extensions to Support IP Version 6", STD 88, 180 RFC 3596, DOI 10.17487/RFC3596, October 2003, 181 . 183 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 184 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 185 2006, . 187 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 188 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 189 . 191 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 192 Extensions: Extension Definitions", RFC 6066, 193 DOI 10.17487/RFC6066, January 2011, 194 . 196 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 197 Protocol (HTTP/1.1): Message Syntax and Routing", 198 RFC 7230, DOI 10.17487/RFC7230, June 2014, 199 . 201 Author's Address 203 Roland Bracewell Shoemaker 204 Internet Security Research Group 206 Email: roland@letsencrypt.org