<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" number="8738"
     docName="draft-ietf-acme-ip-08" consensus="true" category="std" obsoletes="" updates=""
     submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true"
     symRefs="true" version="3"> 

  <front>
    <title abbrev="ACME-IP">Automated Certificate Management Environment (ACME) IP Identifier Validation Extension</title>

    <seriesInfo name="RFC" value="8738" />
    <author initials="R.B." surname="Shoemaker" fullname="Roland Bracewell Shoemaker">
      <organization abbrev="ISRG">Internet Security Research Group</organization>
      <address>
        <email>roland@letsencrypt.org</email>
      </address>
    </author>
    <date month="February" year="2020"/>
    <area>Security</area>
    <workgroup>ACME Working Group</workgroup>

<keyword>acme</keyword>
<keyword>pki</keyword>

    <abstract>
      <t>This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for IP addresses.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>The Automatic Certificate Management Environment (ACME) <xref target="RFC8555" format="default"/> only defines challenges for validating control of DNS host name identifiers, which limits its use to being used for issuing certificates for DNS identifiers. In order to allow validation of IPv4 and IPv6 identifiers for inclusion in X.509 certificates, this document specifies how challenges defined in the original ACME specification and the TLS-ALPN extension specification <xref target="RFC8737" format="default"/> can be used to validate IP identifiers.</t>
    </section>
    <section anchor="terminology" numbered="true" toc="default">
      <name>Terminology</name>

        <t>
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
    <xref target="RFC8174"/> when, and only when, they appear in all capitals,
    as shown here.
        </t>

    </section>
    <section anchor="ip-identifier" numbered="true" toc="default">
      <name>IP Identifier</name>
      <t><xref target="RFC8555" format="default"/> only defines the identifier
      type "dns", which is used to refer to fully qualified domain names. If
      an ACME server wishes to request proof that a user controls an IPv4 or
      IPv6 address, it <bcp14>MUST</bcp14> create an authorization with the
      identifier type "ip". The value field of the identifier
      <bcp14>MUST</bcp14> contain the textual form of the address as defined
      in <xref target="RFC1123" sectionFormat="of" section="2.1"/> for IPv4 and in
      <xref target="RFC5952" sectionFormat="of" section="4"/> for IPv6.</t>
      <t>An identifier for the IPv6 address 2001:db8::1 would be formatted
      like so:</t>


<sourcecode type="json"><![CDATA[
{"type": "ip", "value": "2001:db8::1"}
]]></sourcecode>

    </section>
    <section anchor="identifier-validation-challenges" numbered="true" toc="default">
      <name>Identifier Validation Challenges</name>
      <t>IP identifiers <bcp14>MAY</bcp14> be used with the existing "http-01"
      (see <xref target="RFC8555" sectionFormat="of" section="8.3"/>) and
      "tls-alpn-01" (see <xref target="RFC8737"
      sectionFormat="of" section="3"/>). To use IP identifiers with these challenges, their
      initial DNS resolution step <bcp14>MUST</bcp14> be skipped, and the IP
      address used for validation <bcp14>MUST</bcp14> be the value of the
      identifier.</t> 
    </section>
    <section anchor="http-challenge" numbered="true" toc="default">
      <name>HTTP Challenge</name>
      <t>For the "http-01" challenge, the Host header field
      <bcp14>MUST</bcp14> be set to the IP address being used for validation
      per <xref target="RFC7230" format="default"/>. The textual form of this
      address <bcp14>MUST</bcp14> be as defined in <xref target="RFC1123"
      sectionFormat="of" section="2.1"/> for IPv4 and in <xref target="RFC5952"
      sectionFormat="of" section="4"/> for IPv6.</t> 
    </section>
    <section anchor="tls-with-application-level-protocol-negotiation-tls-alpn-challenge" numbered="true" toc="default">
      <name>TLS with Application-Layer Protocol Negotiation (TLS ALPN) Challenge</name>
      <t>For the "tls-alpn-01" challenge, the subjectAltName extension in the
      validation certificate <bcp14>MUST</bcp14> contain a single iPAddress
      that matches the address being validated. As <xref target="RFC6066"
      format="default"/> does not permit IP addresses to be used in the Server
      Name Indication (SNI) extension HostName field, the server
      <bcp14>MUST</bcp14> instead use the IN-ADDR.ARPA <xref target="RFC1034"
      format="default"/> or IP6.ARPA <xref target="RFC3596" format="default"/>
      reverse mapping of the IP address as the HostName field value instead of
      the IP address string representation itself. For example, if the IP
      address being validated is 2001:db8::1, the SNI HostName field 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".</t>

    </section>
    <section anchor="dns-challenge" numbered="true" toc="default">
      <name>DNS Challenge</name>
      <t>The existing "dns-01" challenge <bcp14>MUST NOT</bcp14> be used to validate IP identifiers.</t>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section anchor="identifier-types" numbered="true" toc="default">
        <name>Identifier Types</name>
        <t>Per this document, a new type has been added to the "ACME Identifier Types"
	registry defined in <xref target="RFC8555"
	sectionFormat="of" section="9.7.7"/> with Label "ip" and Reference
	"RFC 8738".</t> 
      </section>
      <section anchor="challenge-types" numbered="true" toc="default">
        <name>Challenge Types</name>
        <t>Per this document, two new entries have been added to the "ACME Validation Methods"
	registry defined in <xref target="RFC8555"
	sectionFormat="of" section="9.7.8"/>. These entries are defined below:</t> 
        <table align="center"> 
          <thead>
            <tr>
              <th align="left">Label</th>
              <th align="left">Identifier Type</th>
              <th align="left">ACME</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">http-01</td>
              <td align="left">ip</td>
              <td align="left">Y</td>
              <td align="left">RFC 8738</td>
            </tr>
            <tr>
              <td align="left">tls-alpn-01</td>
              <td align="left">ip</td>
              <td align="left">Y</td>
              <td align="left">RFC 8738</td>
            </tr>
          </tbody>
        </table>
      </section>
    </section>
    <section anchor="security-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>The extensions to ACME described in this document do not deviate from
      the broader threat model described in <xref target="RFC8555"
      sectionFormat="of" section="10.1"/>.</t> 
      <section anchor="ca-policy-considerations" numbered="true" toc="default">

        <name>Certification Authority (CA) Policy Considerations</name>
        <t>This document only specifies how an ACME server may validate that a
	certificate applicant controls an 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 an ISP or cloud service provider with short delegation
	periods, they may wish to impose additional restrictions on
	certificates requested for that identifier.</t> 
      </section>
    </section>

  </middle>
  <back>
    <references>
      <name>Normative References</name>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1123.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3596.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5952.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6066.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7230.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8555.xml"/>

<!-- companion document:  draft-ietf-acme-tls-alpn (RFC-to-be 8737)-->

<reference anchor="RFC8737" target="https://www.rfc-editor.org/info/rfc8737">
<front>
<title>Automated Certificate Management Environment (ACME) TLS
Application-Layer Protocol Negotiation (ALPN) Challenge Extension</title>
<author initials='R.B.' surname='Shoemaker' fullname='Roland Bracewell Shoemaker'>
  <organization/>
</author>
<date month='February' year='2020'/>
</front>
<seriesInfo name="RFC" value="8737"/>
<seriesInfo name="DOI" value="10.17487/RFC8737"/>
</reference>

    </references>

    <section anchor="acknowledgments" numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>The author would like to thank those who contributed to this document
      and offered editorial and technical input, especially 
<contact fullname="Jacob Hoffman-Andrews" /> and <contact fullname="Daniel McCarney"/>.</t>
    </section>
  </back>

</rfc>
