Re: [Uta] Éric Vyncke's No Objection on draft-ietf-uta-rfc6125bis-14: (with COMMENT)

[Peter Saint-Andre <[e-mail]>]

Although it would have been nice to receive this feedback during one of 
the two WGLCs or during IETF LC, see my comments below. IMHO these are 
mostly small tweaks that we can fix in parallel with IESG feedback.

On 8/2/23 2:26 PM, Erik Nygren wrote:
> In going through the draft to look at it from a SVCB perspective, a few 
> things jumped out at me, most of which are minor.
> This is past LC so perhaps too late, but sending here as well in-case 
> the WG or others think any need addressing.
> (I opened 
> https://github.com/richsalz/draft-ietf-uta-rfc6125bis/issues/101 
> <https://github.com/richsalz/draft-ietf-uta-rfc6125bis/issues/101> to 
> track but realize it may be too late.)
> 
>  1. On DNS names starting with Labels:
> 
>      > historically this rule was also intended to apply to all labels
>     in a domain name (see Section 2.3.1
>     <https://rfc-editor.org/rfc/rfc1035#section-2.3.1> of [DNS-NAMES
>     <https://www.rfc-editor.org/rfc/rfc1035>]), although that is not
>     always the case in practice.
> 
> This should probably be more clear that domain names are explicitly 
> allowed to start with digits. As per 
> https://datatracker.ietf.org/doc/html/rfc1123#section-2.1 
> <https://datatracker.ietf.org/doc/html/rfc1123#section-2.1> and 
> https://datatracker.ietf.org/doc/html/rfc2181#section-11 
> <https://datatracker.ietf.org/doc/html/rfc2181#section-11> clearly 
> update this. For example from the former clearly states:
> "One aspect of host name syntax is hereby changed: the restriction on 
> the first character is relaxed to allow either a letter or a digit. Host 
> software MUST support this more liberal syntax"

It's not clear to me how the text should be improved. Suggestions welcome.

>  2. On the Web example:
> 
>      > Consider a simple website at www.example.com
>     <http://www.example.com>, which is not discoverable via DNS SRV
>     lookups. Because HTTP does not specify the use of URIs in server
>     certificates, a certificate for this service might include only a
>     DNS-ID of www.example.com <http://www.example.com>.
>      > Consider the same website, which is reachable by a fixed IP
>     address of 2001:db8::5c. The certificate might include this value in
>     an IP-ID to allow clients to use the fixed IP address as a reference
>     identity.
> 
> This would not be the same "website". In particular, the web origin 
> (rfc6454) is the tuple of scheme, authority, and port. Since the 
> authority is different (ie, the IP vs the hostname) they would be 
> distinct. If we're going to include this example, we should be clear 
> that https://www.example.com/ <https://www.example.com/> and 
> https://[2001:db8::5c]/ might be multi-tenant on the same server but are 
> different web origins (ie, different "websites")examples so we always 
> have both?)

Indeed it might be more accurate to say "website service".

>  3.
> 
>     Clarification on IP address matching
> 
>      > For an IP address that appears in a URI-ID, the "host" component
>     of both the reference identity and the presented identifier must
>     match. These are parsed as either an "IP-literal" (following [IPv6
>     <https://www.rfc-editor.org/rfc/rfc4291>]) or an "IPv4address"
>     (following [IPv4 <https://www.rfc-editor.org/rfc/rfc791>]). If the
>     resulting octets are equal, the IP address matches.
> 
> In the IPv6 case, it may be better to reference 
> https://datatracker.ietf.org/doc/html/rfc3986 
> <https://datatracker.ietf.org/doc/html/rfc3986> section 3.2.2 since what 
> is being matched isn't "IP-literal" (which is in square brackets) per 
> the below ABNF but the address inside those brackets:
> 
> |IP-literal = "[" ( IPv6address / IPvFuture ) "]" |

Good catch, we'll wordsmith that.

> There is also the case of https://www.rfc-editor.org/rfc/rfc6874 
> <https://www.rfc-editor.org/rfc/rfc6874> (which allows zoneids) but 
> since the zoneid has host scope it makes no sense for it to be included 
> in how certs are verified. (But perhaps there should be a requirement 
> that the IPv6 IP-ID address NOT be LinkLocal?)

I'm not sure that's necessary.

Peter