idnits 2.17.1 draft-ietf-acme-ip-02.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 18, 2018) is 2170 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 137, but no explicit reference was found in the text == Unused Reference: 'RFC1034' is defined on line 149, but no explicit reference was found in the text == Unused Reference: 'RFC3596' is defined on line 163, but no explicit reference was found in the text == Unused Reference: 'RFC4648' is defined on line 172, 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-12 ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 1 error (**), 0 flaws (~~), 7 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 May 18, 2018 5 Expires: November 19, 2018 7 ACME IP Identifier Validation Extension 8 draft-ietf-acme-ip-02 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 19, 2018. 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 . . . . . . . . . . . . . . . . . . . . . . . 3 59 8. Normative References . . . . . . . . . . . . . . . . . . . . 3 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 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 can be used to validate IP identifiers. 72 2. Terminology 74 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 75 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 76 and "OPTIONAL" are to be interpreted as described in BCP 14, 77 [RFC2119]. 79 3. IP Identifier 81 [I-D.ietf-acme-acme] only defines the identifier type "dns" which is 82 used to refer to fully qualified domain names. If a ACME server 83 wishes to request proof that a user controls a IPv4 or IPv6 address 84 it MUST create an authorization with the identifier type "ip". The 85 value field of the identifier MUST contain the textual form of the 86 address as defined in [RFC1123] Section 2.1 for IPv4 and in [RFC4291] 87 Section 2.2 for IPv6. 89 An identifier for the IPv6 address 2001:db8::1 would be formatted 90 like so: 92 {"type": "ip", "value": "2001:db8::1"} 94 4. Identifier Validation Challenges 96 IP identifiers MAY be used with the existing "http-01" and "tls-sni- 97 02" challenges from [I-D.ietf-acme-acme] Sections 8.3 and 8.4 98 respectively. To use IP identifiers with these challenges their 99 initial DNS resolution step MUST be skipped and the IP address used 100 for validation MUST be the value of the identifier. For the "http- 101 01" challenge the Host header MUST be set to the IP address being 102 used for validation per [RFC7230]. 104 The existing "dns-01" challenge MUST NOT be used to validate IP 105 identifiers. 107 5. IANA Considerations 109 5.1. Identifier Types 111 Adds a new type to the Identifier list defined in Section 9.7.5 of 112 [I-D.ietf-acme-acme] with the label "ip" and reference I-D.ietf-acme- 113 ip. 115 5.2. Challenge Types 117 Add the value "ip" to the identifier type column for the "http-01" 118 and "tls-sni-02" challenges. 120 6. Security Considerations 122 Given the often short delegation periods for IP addresses provided by 123 various service providers CAs MAY want to impose shorter lifetimes 124 for certificates which contain IP identifiers. They MAY also impose 125 restrictions on IP identifiers which are in CIDRs known to be 126 assigned to service providers who dynamically assign addresses to 127 users for indeterminate periods of time. 129 7. Acknowledgments 131 The author would like to thank those who contributed to this document 132 and offered editorial and technical input, especially Jacob Hoffman- 133 Andrews and Daniel McCarney. 135 8. Normative References 137 [FIPS180-4] 138 Department of Commerce, National., "NIST FIPS 180-4, 139 Secure Hash Standard", March 2012, 140 . 143 [I-D.ietf-acme-acme] 144 Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 145 Kasten, "Automatic Certificate Management Environment 146 (ACME)", draft-ietf-acme-acme-12 (work in progress), April 147 2018. 149 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 150 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 151 . 153 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 154 Application and Support", STD 3, RFC 1123, 155 DOI 10.17487/RFC1123, October 1989, 156 . 158 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 159 Requirement Levels", BCP 14, RFC 2119, 160 DOI 10.17487/RFC2119, March 1997, 161 . 163 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 164 "DNS Extensions to Support IP Version 6", STD 88, 165 RFC 3596, DOI 10.17487/RFC3596, October 2003, 166 . 168 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 169 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 170 2006, . 172 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 173 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 174 . 176 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 177 Protocol (HTTP/1.1): Message Syntax and Routing", 178 RFC 7230, DOI 10.17487/RFC7230, June 2014, 179 . 181 Author's Address 183 Roland Bracewell Shoemaker 184 Internet Security Research Group 186 Email: roland@letsencrypt.org