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

[Wu, Jiaxin]

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




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#49442): https://edk2.groups.io/g/devel/message/49442
Mute This Topic: https://groups.io/mt/34551672/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-