Automated Certificate Management Environment (ACME) IP Identifier Validation Extension
draft-ietf-acme-ip-08

I had initially balloted DISCUSS, and, after discussions with the authors / WG am changing to No Objection.

I must admit I have a visceral dislike of this - making IP address certificates faster / easier / more automated to obtain them **feels**  like a bad outcome -- intellectually I understand that IP address certs already exist, and that standardizing the protocol is likely a good thing -- but it still makes me uncomfortable. 

"This makes me twitch" is, however, not a reasonable criteria for a DISCUSS or blocking a document, and so I'm balloting No Objection. 

I'd spent a while writing up an "Abstain" position (in the "I oppose this document but understand that others differ and am not going to stand in the way of the others." sense), but that simply felt like a non-blocking, passive-aggressive version of DISCUSS, so am settling on NoObjection...

Short and useful document: thank you for writing it.

No need to reply to my two questions, but, I would appreciate your answers:
1) why using a tag "ip" rather than "address" ?
2) unsure whether it is doable, but, why only allowing /32 or /128 addresses? A server can listen to a /64 (for some specific applications), so, requesting a /64 via ACME would be useful (challenge could be done via a random address out of this /64 for example)

Regards

-éric

The author acknowledged that the following change will be done, so I cleared my DISCUSS:

Section 3 of RFC 6066 says:
   "HostName" contains the fully qualified DNS hostname of the server,
   as understood by the client.  The hostname is represented as a byte
   string using ASCII encoding without a trailing dot.

However your example shows in Section 6:

   For the "tls-alpn-01" challenge the subjectAltName extension in the
   validation certificate MUST contain a single iPAddress that matches
   the address being validated.  As [RFC6066] does not permit IP
   addresses to be used in the SNI extension HostName field the server
   MUST instead use the IN-ADDR.ARPA [RFC1034] or IP6.ARPA [RFC3596]
   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.".

I.e. there is a trailing dot after “arpa”. Is the example wrong or am I missing something?

For completion, this document should be tagged as replacing draft-shoemaker-acme-ip.

I have only editorial comments below.  No response is needed — please just consider incorporating these, as I think they’ll help make the document clearer.

— Introduction —

   The Automatic Certificate Management Environment (ACME) [RFC8555]
   only defines challenges for validating control of DNS host name
   identifiers which limits its use to being used for issuing
   certificates for DNS identifiers.

This needs a comma before “which”.

— Section 2 —
Please use the new BCP 14 boilerplate and references (see RFC 8174).

— Section 3 —

   [RFC8555] only defines the identifier type "dns" which is used to
   refer to fully qualified domain names.

Similarly: needs a comma before “which”.

— Section 4 —

   IP identifiers MAY be used with the existing "http-01" and "tls-alpn-
   01" challenges from [RFC8555] Section 8.3 and
   [I-D.ietf-acme-tls-alpn] Section 3 respectively.

This is OK as it is, so take this or leave it as you will, but to my eyes the citations are needlessly separated from their anchors.  I would re-order it this way:

NEW
   IP identifiers MAY be used with the existing challenges
   "http-01" (see Section 8.3 of [RFC8555]) and "tls-alpn-01"
   (see Section 3 of [I-D.ietf-acme-tls-alpn]).
END

— Section 5 —

   The textual form of
   this address MUST be those defined in [RFC1123] Section 2.1 for IPv4
   and in [RFC5952] Section 4 for IPv6.

The subject is singular, so “those” doesn’t work.  An easy fix is to use “as defined”.

— Section 6 —

   For the "tls-alpn-01" challenge the subjectAltName extension in the
   validation certificate MUST contain a single iPAddress which matches
   the address being validated.

This needs “which” changed to “that”, to make it a restrictive clause.