Automated Certificate Management Environment (ACME) IP Identifier Validation Extension
RFC 8738

Note: This ballot was opened for revision 06 and is now closed.

Benjamin Kaduk Yes

Comment (2019-09-30 for -07)
Section 7

There's perhaps some "action at a distance" going on here, in that we
try to apply normative requirements on unrelated things.  Perhaps it's
safer to just say "this document does not define any usage of the
'dns-01' challenge to validate IP addresses.  But if we can definitively
rule out any future use, then it doesn't really matter.

Section 9

Is there anything to say about issuing certificates for
non-publicly-routable IP addresses in terms of ensuring that the ACME
server and client are in the same administrative domain [and enforcing
that by network topology]?

Roman Danyliw Yes

Alvaro Retana No Objection

Comment (2019-09-27 for -07)
For completion, this document should be tagged as replacing draft-shoemaker-acme-ip.

Martin Vigoureux No Objection

Warren Kumari (was Discuss) No Objection

Comment (2019-10-01)
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...

Éric Vyncke No Objection

Comment (2019-09-30 for -07)
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

(Adam Roach; former steering group member) Yes

Yes (2019-09-30 for -07)
Thanks for the work you put into specifying this mechanism. The only
comments I have are editorial.

---------------------------------------------------------------------------

§1:

>  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
>  [I-D.ietf-acme-tls-alpn] can be used to validate IP identifiers.`


Nit: "...certificates, this..."

---------------------------------------------------------------------------

§3:

>  If a ACME server wishes to
>  request proof that a user controls a IPv4 or IPv6 address it MUST
>  create an authorization with the identifier type "ip".

Nit: "...an ACME..."

Nit: "...address, it..."

---------------------------------------------------------------------------

§4:

>  To use IP identifiers with these
>  challenges their initial DNS resolution step MUST be skipped and the
>  IP address used for validation MUST be the value of the identifier.

Nit: "...challenges, their..."

Nit: "...skipped, and..."

---------------------------------------------------------------------------

§5:

>  For the "http-01" challenge the Host header MUST be set to the IP
>  address being used for validation per [RFC7230].

Nit: "...challenge, the..."

Nit: "...Host header field..."

---------------------------------------------------------------------------

§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.

Nit: "...challenge, the subjectAltName..."

>  As [RFC6066] does not permit IP
>  addresses to be used in the SNI extension HostName field the server

Nit: "...HostName field, the server...."

>  For example if the
>  IP address being validated is 2001:db8::1 the SNI HostName field

Nit: "For example, if the..."

Nit: "...2001:db8::1, the SNI..."

---------------------------------------------------------------------------

§9.1:

>  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.

Nit: "For example, if the CA..."

Nit: "...delegation periods, they may..."

(Alexey Melnikov; former steering group member) (was Discuss) No Objection

No Objection (2019-10-01 for -07)
No email
send info
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?

(Alissa Cooper; former steering group member) No Objection

No Objection ()
No email
send info

(Barry Leiba; former steering group member) No Objection

No Objection (2019-09-26 for -06)
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.

(Deborah Brungard; former steering group member) No Objection

No Objection ()
No email
send info

(Magnus Westerlund; former steering group member) No Objection

No Objection ( for -07)
No email
send info

(Suresh Krishnan; former steering group member) No Objection

No Objection ( for -07)
No email
send info