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
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
