Comments inline: > On Dec 24, 2018, at 12:32 PM, Eric Rescorla <[email protected]> wrote: > > Rich version of this review at: > https://mozphab-ietf.devsvcdev.mozaws.net/D4180 > > > IMPORTANT > S 3. > > used to refer to fully qualified domain names. 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". The > > value field of the identifier MUST contain the textual form of the > > address as defined in [RFC1123] Section 2.1 for IPv4 and in [RFC4291] > > Section 2.2 for IPv6. > > Are all three variants here valid?
I think requiring the canonical representation defined in 5952 Section 4 to be supported makes sense, but would be in favor of also allowing supporting any of the other 4291 representations if the implementer wishes. > > > S 4. > > For the "tls-alpn-01" the subjectAltName extension in the validation > > certificate MUST contain a single iPAddress which matches the address > > being validated. As [RFC6066] does not permit IP addresses to be > > used in the SNI extension the server MUST instead use the IN- > > ADDR.ARPA [RFC1034] or IP6.ARPA [RFC3596] reverse mapping of the IP > > address as the SNI value instead of the literal IP address. > > What happens if an attacker forces an incorrect SNI on you here? I > don't see any security analysis below, but I suspect it's bad, > I’m not sure I understand how an attacker would force an incorrect SNI? tls-alpn-01 requires that the server verify that the SNI that it is provided matches what it expects. > > COMMENTS > S 6. > > > > 6. Security Considerations > > > > Given the often short delegation periods for IP addresses provided by > > various service providers CAs MAY want to impose shorter lifetimes > > for certificates which contain IP identifiers. They MAY also impose > > https://tools.ietf.org/rfcmarkup?doc=6919#section-6 > > If the WG thinks that providers ought to do this, then it should say > so. > I don’t think it makes sense for the document to mandate this as it’s not an implementation detail but a policy one which the relevant policy authorities (such as CABF) may dictate themselves in the future putting this document at odds with those requirements. _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
