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 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 and 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" 1. On the Web example: > Consider a simple website at 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. > 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/ 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?) 1. 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 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 ) "]" There is also the case of 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?) On Wed, Aug 2, 2023 at 7:25 AM Eric Vyncke (evyncke) <evyn...@cisco.com> wrote: > Thank you, Rich, for the prompt action > > -éric > > On 02/08/2023, 15:59, "Salz, Rich" <rs...@akamai.com <mailto: > rs...@akamai.com>> wrote: > > > Thanks for the feedback. > > > The SVCB issue is recorded in > https://github.com/richsalz/draft-ietf-uta-rfc6125bis/issues/98 < > https://github.com/richsalz/draft-ietf-uta-rfc6125bis/issues/98> > > > The other minor comments are recorded in > https://github.com/richsalz/draft-ietf-uta-rfc6125bis/issues/99 < > https://github.com/richsalz/draft-ietf-uta-rfc6125bis/issues/99> > > > > > >
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
