Re: [edk2-devel] [RFC v1 5/4] CryptoPkg/TlsLib: accept peer certs via both DNS names and IP addresses

["Wu, Jiaxin" <jiaxin.wu@intel.com>]

> 
> However. When I wanted to include a reference to RFC6125, I looked more
> closely at the section that Jiaxin quoted. More specifically, the
> surroundings of that section.
> 
> It turns out that the quoted section "3.1. Server Identity" is actually
> part of Appendix B.2 ("HTTP (2000)"):
> 
>   https://tools.ietf.org/html/rfc6125#appendix-B.2
> 
> which is further part of Appendix B ("Prior Art"):
> 
>   https://tools.ietf.org/html/rfc6125#appendix-B
> 
> Appendix B starts with the statement
> 
> > (This section is non-normative.)
> 
> and Appendix B.2 starts with
> 
> >    In 2000, [HTTP-TLS] specified the following text regarding
> >    application service identity verification in HTTP:
> 
> Thus, Appendix B of RFC6125 doesn't require us to do anything! (Other
> specs may still require us, of course.)
> 
> Now, does RFC6125 say anything about IP addresses? Yes, it does, in
> section 1.7.2, "Out of Scope":
> 
> https://tools.ietf.org/html/rfc6125#section-1.7.2
> 
> >    o  Identifiers other than fully qualified DNS domain names.
> >
> >       Some certification authorities issue server certificates based on
> >       IP addresses, but preliminary evidence indicates that such
> >       certificates are a very small percentage (less than 1%) of issued
> >       certificates.  Furthermore, IP addresses are not necessarily
> >       reliable identifiers for application services because of the
> >       existence of private internets [PRIVATE], host mobility, multiple
> >       interfaces on a given host, Network Address Translators (NATs)
> >       resulting in different addresses for a host from different
> >       locations on the network, the practice of grouping many hosts
> >       together behind a single IP address, etc.  Most fundamentally,
> >       most users find DNS domain names much easier to work with than IP
> >       addresses, which is why the domain name system was designed in the
> >       first place.  We prefer to define best practices for the much more
> >       common use case and not to complicate the rules in this
> >       specification.
> >
> >       Furthermore, we focus here on application service identities, not
> >       specific resources located at such services.  Therefore this
> >       document discusses Uniform Resource Identifiers [URI] only as a
> >       way to communicate a DNS domain name (via the URI "host"
> component
> >       or its equivalent), not as a way to communicate other aspects of a
> >       service such as a specific resource (via the URI "path" component)
> >       or parameters (via the URI "query" component).
> >
> >       We also do not discuss attributes unrelated to DNS domain names,
> >       such as those defined in [X.520] and other such specifications
> >       (e.g., organizational attributes, geographical attributes, company
> >       logos, and the like).
> 
> So... I think we can (and should) proceed just the same, but we should
> reference:
> 
>   https://tools.ietf.org/html/rfc2818#section-3.1
> 
> rather than RFC6125.
> 
> Accordingly, I've filed the curl report with reference to RFC-2818:
> 
>   https://hackerone.com/reports/715413
> 
> [...]
> 

Yeah, agree, Good Catch! Thanks.