draft-ietf-acme-ip-05.txt   draft-ietf-acme-ip-06.txt 
ACME Working Group R. Shoemaker ACME Working Group R. Shoemaker
Internet-Draft ISRG Internet-Draft ISRG
Intended status: Standards Track February 14, 2019 Intended status: Standards Track May 22, 2019
Expires: August 18, 2019 Expires: November 23, 2019
ACME IP Identifier Validation Extension ACME IP Identifier Validation Extension
draft-ietf-acme-ip-05 draft-ietf-acme-ip-06
Abstract Abstract
This document specifies identifiers and challenges required to enable This document specifies identifiers and challenges required to enable
the Automated Certificate Management Environment (ACME) to issue the Automated Certificate Management Environment (ACME) to issue
certificates for IP addresses. certificates for IP addresses.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 32 skipping to change at page 1, line 32
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 18, 2019. This Internet-Draft will expire on November 23, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. IP Identifier . . . . . . . . . . . . . . . . . . . . . . . . 2 3. IP Identifier . . . . . . . . . . . . . . . . . . . . . . . . 2
4. Identifier Validation Challenges . . . . . . . . . . . . . . 3 4. Identifier Validation Challenges . . . . . . . . . . . . . . 3
5. HTTP Challenge . . . . . . . . . . . . . . . . . . . . . . . 3 5. HTTP Challenge . . . . . . . . . . . . . . . . . . . . . . . 3
6. TLS with Application Level Protocol Negotiation (TLS ALPN) 6. TLS with Application Level Protocol Negotiation (TLS ALPN)
Challenge . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Challenge . . . . . . . . . . . . . . . . . . . . . . . . . . 3
7. DNS Challenge . . . . . . . . . . . . . . . . . . . . . . . . 3 7. DNS Challenge . . . . . . . . . . . . . . . . . . . . . . . . 3
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
8.1. Identifier Types . . . . . . . . . . . . . . . . . . . . 3 8.1. Identifier Types . . . . . . . . . . . . . . . . . . . . 3
8.2. Challenge Types . . . . . . . . . . . . . . . . . . . . . 3 8.2. Challenge Types . . . . . . . . . . . . . . . . . . . . . 4
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 9. Security Considerations . . . . . . . . . . . . . . . . . . . 4
10. Normative References . . . . . . . . . . . . . . . . . . . . 4 9.1. CA Policy Considerations . . . . . . . . . . . . . . . . 4
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4
11. Normative References . . . . . . . . . . . . . . . . . . . . 4
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction 1. Introduction
The Automatic Certificate Management Environment (ACME) The Automatic Certificate Management Environment (ACME) [RFC8555]
[I-D.ietf-acme-acme] only defines challenges for validating control only defines challenges for validating control of DNS host name
of DNS host name identifiers which limits its use to being used for identifiers which limits its use to being used for issuing
issuing certificates for DNS identifiers. In order to allow certificates for DNS identifiers. In order to allow validation of
validation of IPv4 and IPv6 identifiers for inclusion in X.509 IPv4 and IPv6 identifiers for inclusion in X.509 certificates this
certificates this document specifies how challenges defined in the document specifies how challenges defined in the original ACME
original ACME specification and the TLS-ALPN extension specification specification and the TLS-ALPN extension specification
[I-D.ietf-acme-tls-alpn] can be used to validate IP identifiers. [I-D.ietf-acme-tls-alpn] can be used to validate IP identifiers.
2. Terminology 2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in BCP 14, and "OPTIONAL" are to be interpreted as described in BCP 14,
[RFC2119]. [RFC2119].
3. IP Identifier 3. IP Identifier
[I-D.ietf-acme-acme] only defines the identifier type "dns" which is [RFC8555] only defines the identifier type "dns" which is used to
used to refer to fully qualified domain names. If a ACME server refer to fully qualified domain names. If a ACME server wishes to
wishes to request proof that a user controls a IPv4 or IPv6 address request proof that a user controls a IPv4 or IPv6 address it MUST
it MUST create an authorization with the identifier type "ip". The create an authorization with the identifier type "ip". The value
value field of the identifier MUST contain the textual form of the field of the identifier MUST contain the textual form of the address
address as defined in [RFC1123] Section 2.1 for IPv4 and in [RFC5952] as defined in [RFC1123] Section 2.1 for IPv4 and in [RFC5952]
Section 4 for IPv6. Section 4 for IPv6.
An identifier for the IPv6 address 2001:db8::1 would be formatted An identifier for the IPv6 address 2001:db8::1 would be formatted
like so: like so:
{"type": "ip", "value": "2001:db8::1"} {"type": "ip", "value": "2001:db8::1"}
4. Identifier Validation Challenges 4. Identifier Validation Challenges
IP identifiers MAY be used with the existing "http-01" and "tls-alpn- IP identifiers MAY be used with the existing "http-01" and "tls-alpn-
01" challenges from [I-D.ietf-acme-acme] Section 8.3 and 01" challenges from [RFC8555] Section 8.3 and
[I-D.ietf-acme-tls-alpn] Section 3 respectively. To use IP [I-D.ietf-acme-tls-alpn] Section 3 respectively. To use IP
identifiers with these challenges their initial DNS resolution step identifiers with these challenges their initial DNS resolution step
MUST be skipped and the IP address used for validation MUST be the MUST be skipped and the IP address used for validation MUST be the
value of the identifier. value of the identifier.
5. HTTP Challenge 5. HTTP Challenge
For the "http-01" challenge the Host header MUST be set to the IP For the "http-01" challenge the Host header MUST be set to the IP
address being used for validation per [RFC7230]. The textual form of address being used for validation per [RFC7230]. The textual form of
this address MUST be those defined in [RFC1123] Section 2.1 for IPv4 this address MUST be those defined in [RFC1123] Section 2.1 for IPv4
and in [RFC5952] Section 4 for IPv6. and in [RFC5952] Section 4 for IPv6.
6. TLS with Application Level Protocol Negotiation (TLS ALPN) Challenge 6. TLS with Application Level Protocol Negotiation (TLS ALPN) Challenge
For the "tls-alpn-01" challenge the subjectAltName extension in the For the "tls-alpn-01" challenge the subjectAltName extension in the
validation certificate MUST contain a single iPAddress which matches validation certificate MUST contain a single iPAddress which matches
the address being validated. As [RFC6066] does not permit IP the address being validated. As [RFC6066] does not permit IP
addresses to be used in the SNI extension HostName the server MUST addresses to be used in the SNI extension HostName field the server
instead use the IN-ADDR.ARPA [RFC1034] or IP6.ARPA [RFC3596] reverse MUST instead use the IN-ADDR.ARPA [RFC1034] or IP6.ARPA [RFC3596]
mapping of the IP address as the HostName value instead of the reverse mapping of the IP address as the HostName field value instead
literal IP address. For example if the IP address being validated is of the IP address string representation itself. For example if the
2001:db8::1 the SNI HostName should contain "1.0.0.0.0.0.0.0.0.0.0.0. IP address being validated is 2001:db8::1 the SNI HostName field
0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.". 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
.0.1.0.0.2.ip6.arpa.".
7. DNS Challenge 7. DNS Challenge
The existing "dns-01" challenge MUST NOT be used to validate IP The existing "dns-01" challenge MUST NOT be used to validate IP
identifiers. identifiers.
8. IANA Considerations 8. IANA Considerations
8.1. Identifier Types 8.1. Identifier Types
Adds a new type to the Identifier list defined in Section 9.7.7 of Adds a new type to the "ACME Identifier Types" registry defined in
[I-D.ietf-acme-acme] with the label "ip" and reference I-D.ietf-acme- Section 9.7.7 of [RFC8555] with Label "ip" and Reference "I-D.ietf-
ip. acme-ip".
8.2. Challenge Types 8.2. Challenge Types
Adds the value "ip" to the Identifier Type column in the Validation Adds two new entries to the "ACME Validation Methods" registry
Methods list defined in Section 9.7.8 of [I-D.ietf-acme-acme] for the defined in Section 9.7.8 of [RFC8555]. These entries are defined
"http-01" and "tls-alpn-01" challenges. below:
9. Acknowledgments +-------------+-----------------+------+------------------+
| Label | Identifier Type | ACME | Reference |
+-------------+-----------------+------+------------------+
| http-01 | ip | Y | I-D.ietf-acme-ip |
| | | | |
| tls-alpn-01 | ip | Y | I-D.ietf-acme-ip |
+-------------+-----------------+------+------------------+
9. Security Considerations
The extensions to ACME described in this document do not deviate from
the broader threat model described in [RFC8555] Section 10.1.
9.1. CA Policy Considerations
This document only specifies how a ACME server may validate that a
certificate applicant controls a IP identifier at the time of
validation. The CA may wish to perform additional checks not
specified in this document. For example if the CA believes an IP
identifier belongs to a ISP or cloud service provider with short
delegation periods they may wish to impose additional restrictions on
certificates requested for that identifier.
10. Acknowledgments
The author would like to thank those who contributed to this document The author would like to thank those who contributed to this document
and offered editorial and technical input, especially Jacob Hoffman- and offered editorial and technical input, especially Jacob Hoffman-
Andrews and Daniel McCarney. Andrews and Daniel McCarney.
10. Normative References 11. Normative References
[FIPS180-4]
Department of Commerce, National., "NIST FIPS 180-4,
Secure Hash Standard", March 2012,
<http://csrc.nist.gov/publications/fips/fips180-4/
fips-180-4.pdf>.
[I-D.ietf-acme-acme]
Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment
(ACME)", draft-ietf-acme-acme-18 (work in progress),
December 2018.
[I-D.ietf-acme-tls-alpn] [I-D.ietf-acme-tls-alpn]
Shoemaker, R., "ACME TLS ALPN Challenge Extension", draft- Shoemaker, R., "ACME TLS ALPN Challenge Extension", draft-
ietf-acme-tls-alpn-05 (work in progress), August 2018. ietf-acme-tls-alpn-05 (work in progress), August 2018.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
skipping to change at page 4, line 48 skipping to change at page 5, line 20
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", STD 88, "DNS Extensions to Support IP Version 6", STD 88,
RFC 3596, DOI 10.17487/RFC3596, October 2003, RFC 3596, DOI 10.17487/RFC3596, October 2003,
<https://www.rfc-editor.org/info/rfc3596>. <https://www.rfc-editor.org/info/rfc3596>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, Address Text Representation", RFC 5952,
DOI 10.17487/RFC5952, August 2010, DOI 10.17487/RFC5952, August 2010,
<https://www.rfc-editor.org/info/rfc5952>. <https://www.rfc-editor.org/info/rfc5952>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066, Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011, DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/info/rfc6066>. <https://www.rfc-editor.org/info/rfc6066>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>. <https://www.rfc-editor.org/info/rfc7230>.
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/info/rfc8555>.
Author's Address Author's Address
Roland Bracewell Shoemaker Roland Bracewell Shoemaker
Internet Security Research Group Internet Security Research Group
Email: roland@letsencrypt.org Email: roland@letsencrypt.org
 End of changes. 14 change blocks. 
55 lines changed or deleted 66 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/