Re: [Uta] Unofficial I18ndir review of draft-ietf-uta-rfc6125bis

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

Hi John,

Thanks for taking the time to provide feedback and my apologies for the 
delayed reply. Comments inline.

On 12/27/22 8:21 AM, John C Klensin wrote:
> Valery,
> 
> Thanks.  In skimming back through this, I noticed several typos
> and evidence of editorial carelessness.  The ones that might be
> unclear are:
> 
> * In (3) "other local deviations and (claimed) translation
> strategies" should have been "other local deviations and
> (claimed) transition strategies"
> 
> * In (6) "IPvN, N > 6, out there, basing..." should have been
> "IPvN, N > 6, out there, making..." or "IPvN, N > 6, out there,
> defining...".

ACK

> In addition, my note assumed, I hope correctly, that WG
> participants who are working with this document understand that
> an arbitrary string of Unicode code points does not qualify as a
> U-label.  The latter requires all of the processing and validity
> checking specified in the IDNA2008 documents.   If anyone did
> not understand that, it was the reason for the "unrestricted
> Unicode strings, or even U-labels" distinction in (8)... and you
> do now.

Much appreciated.

> --On Tuesday, December 27, 2022 15:31 +0300 Valery Smyslov
> <[e-mail]> wrote:
> 
>> Hi,
>>
>> below is an unofficial I18NDIR review of the draft,
>> performed by John Klensin (forwarded here with his permission).
>> Thanks to John for doing this review.
>>
>> Regards,
>> Valery.
>>
>> -----Original Message-----
>> From: John C Klensin [mailto:[e-mail]]
>> Sent: Monday, December 26, 2022 9:53 PM
>> To: Valery Smyslov
>> Cc: [e-mail]; 	; [e-mail]; Barry Leiba
>> Subject: Re: [I18ndir] I18NDIR active?
>>
>>   (1) Given the importance of anyone intending to use a
>> certificate being absolutely certain that the certificate that
>> should apply is actually the certificate in hand, it seems to
>> me desirable that Section 4.1 more carefully examine anything
>> identified as "SHOULD" and comment on the circumstances in
>> which following that rule would be inappropriate and/or the
>> possible consequences of not applying it.

Taken literally, §4.1 does not mandate including *any* identifier in a 
certificate because all ID types are "SHOULD". We might consider saying 
"MUST include at least one identifier" because otherwise there's nothing 
to match against (although it seems unlikely that any real-world CA 
would issue such a certificate).

Point 1 states that the DNS-ID type is a baseline for interoperability, 
but even that can't be REQUIRED because it's legitimate for a 
certificate to be scoped to a particular application type via the SRV-ID 
or URI-ID type. We could qualify this SHOULD to reflect this reasoning.

Points 2 (SRV-ID) and 3 (URI-ID) are relevant only for application 
protocols that specify the use of these types. Often these types would 
supplement the DNS-ID, unless the certificate is meant to be scoped to 
only the protocol in question (which is not something that the CA might 
know).

Point 4 is discussed more fully in §7.4, which also points to RFC 9325 
regarding security concerns and mitigations. (We might want to point 
more specifically to §3.8 and §3.9 of RFC 9325.)

Point 5 opens the door to "other application-specific identifiers". In 
RFC 6125 we stated more specifically that such identifiers were types 
defined before publication of RFC 4985. The example we used in RFC 6125 
was XmppAddr, but that has since been deprecated. It's unclear to me how 
many such application-specific identifiers are still (or were ever) in 
use. We might want to further qualify the text here and bring back the 
further context about RFC 4985.

>> (2) The document makes several references to URIs, but only RFC
>> 3986 appears to be referenced.  In the real world in which
>> certificates are established and used and in which differences
>> in specifications and practices often provide opportunities for
>> exploitation by would-be evildoers, there are at least two,
>> probably three, URI specifications (IETF/RFC3896, WHATWG, and
>> maybe W3C).  Each is treated as authoritative by some Internet
>> actors and they are not consistent with each other.  That
>> situation and its implications should be pointed out, at least
>> as a Security Consideration.

Hmm.

There's likely value in pointing out the existence of the URL 
specification maintained by the WHATWG at 
<https://url.spec.whatwg.org/>. However, providing a detailed analysis 
of the differences between RFC 3986 and that "living standard" (which 
would be necessary in order to fully document the implications of such 
differences) seems out of scope for a specification about certificates. 
Nevertheless Rich and I will take a closer look at what might be 
involved and report back to the UTA WG in this thread.

As to "maybe W3C", there's a plethora of pages about URLs and URIs on 
the W3C website, but most of them seem to point to either RFC 3986 or 
(eventually).

>> (3) Similarly, there are, in practice, at least two different
>> specifications for IDNs.  While the IETF considers it obsolete,
>> IDNA2003 is still referenced periodically and might constitute
>> another.  One of those, obviously, is as specified by RFC
>> 5890ff.  Another is specified, with the claim that it is a
>> transition strategy but that has shown no signs in recent years
>> of being used that way rather than as an alternate spec, by the
>> Unicode Consortium as UTS#46 [4].  These specifications, and
>> other local deviations and (claimed) translation strategies,
>> are in wide use in different communities.  In particular, while
>> ICANN --and hence what is nominally permitted to be registered
>> in the DNS near the root of tree-- at least nominally conforms
>> to IDNA2008 (but has been unable to prevent some TLDs from
>> registering emoji as second-level domains), WHATWG (and hence
>> most or all browser vendors and implementers) have
>> specification written in terms of UTS#46. The same
>> considerations as in (2) above apply, only the
>> incompatibilities among the specs are much greater with emoji
>> in domain names being a striking difference although there are
>> many more subtle cases.  And, as in (2) this issue should at
>> least be a Security Consideration.

I fear you're right, and I also fear the scope of the work involved. As 
with (2) we'll need to take a closer look and report back.

>> (4) Section 6.3 strongly implies that there are two types of
>> domain names: the traditional, all-ASCII, variety known as the
>> "preferred name syntax"  in RFC 1034 Section 3.5 and IDNs.  But
>> it does not say that but, instead, points to RFC 1034 as a
>> whole.  RFC 1034 imposes no restrictions on what can be in a
>> the octets that make up a label (see, e.g., Section 11 of RFC
>> 2181). If you mean that the labels of the domain names you are
>> considering must be IDNs, all-ASCII, or "preferred syntax" (the
>> last two are different), figure out a way to say that
>> explicitly.

I believe that RFC 6125 and now 6125bis have had in mind "preferred name 
syntax", not all-ASCII (whatever the latter might mean in practice since 
it is much less restrictive). Pointing specifically to §3.5 of RFC 1034 
should help. (And of course as you note in (3) IDN is, in practice, not 
a unitary construct either.)

>> (5) AFAICT, the third paragraph of Section 6.3, describing IDN
>> matching, is correct.  You might want to say "before checking
>> the domain name or comparing it with others" but that is a nit.

Noted.

>> (6) Under 6.4, the draft says "The iPAddress field does not
>> include the IP version, so IPv4 addresses are distinguish from
>> IPv6 addresses only by their length (4 as opposed to 16
>> bytes)". I don't know if that can be fixed or if this document
>> would be the appropriate place to fix it, but, as long is
>> there are people, companies, governments, or other entities
>> out there with bright ideas about IPvN, N > 6, out there,
>> basing operations on this field conditional on a heuristic
>> that depends on length does not seem like a good idea. 

As a general rule that's true, although here we are talking (somewhat 
informally, I might add) about a heuristic only for IPv4 vs. IPv6, not 
any arbitrary IPvN where N > 6 (or N != 4 or 6).

To be slightly more careful, we could say something like this:

   The iPAddress field does not include the IP version, so a
   helpful heuristic for implementors is to distinguish IPv4
   addresses from IPv6 addresses by their length.

>> And,
>> btw, the preferred term is usually "octets" rather than
>> "bytes".

True.

>> (7) Editorial nit: the first sentence of the penultimate
>> paragraph of 6.4 isn't one.

Yes, someone else already noted that, and we realized it should read:

   For an IP address that appears in a URI-ID, the "host" component
   of both the reference identity and the presented identifier must
   match.

>> (8)  If all of your processing (not just comparisons) and what
>> you allow to store in certificates is based on A-labels, then
>> I'm not sure what Section 7.2 means.  If you allow unrestricted
>> Unicode strings, or even U-labels,

§6.3 does say:

    If the DNS domain name portion of a reference identifier is an
    internationalized domain name, then the client MUST convert any
    U-labels [IDNA-DEFS] in the domain name to A-labels before checking
    the domain name.  In accordance with [IDNA-PROTO], A-labels MUST be
    compared as case-insensitive ASCII.  Each label MUST match in order
    for the domain names to be considered to match, except as
    supplemented by the rule about checking of wildcard labels given
    below.

This seemed the safest bet, since I am not sure if we can outlaw 
U-labels in certificates.

>> in labels in certificates,
>> then visual confusion by users is only one of many problems you
>> invite. 

Indeed.

>> And, even then, note, e.g., that
>>      trøll ( \u0074\u0072\u00F8\u006C\u006C )
>> and the identical-appearing
>>      \u0074\u0072\u006F\u0078\u006C\u006C
>> generate different A-labels and are not a "visual confusion"
>> problem as described in the cited portions of RFC 5890.  UTR#36
>> (which you reference) and  UTS#39 [5], especially Section 4
>> (which the document does not reference and probably should)

Good point.

>> are
>> better in some ways, but basically point to the problems and
>> possible approaches.  In particular, implementing even the
>> "whole script" algorithm of UTS#39 Section 4.1 (and then 5.1)
>> require fairly deep understanding of whatever scripts might
>> appear in the characters of any particular DNS label.   That
>> does not quite rise to "impossible" but is certainly well in
>> the "infeasible" range, even for single-script labels, when all
>> possible IDN labels are considered.

Moreover, it seems highly unlikely that we could mandate such careful 
handling in relation to the toolchains and workflows for requesting, 
creating, and issuing certificates. And even if we could, the last line 
of defence would need to be the client software that tries to match the 
presented identifier(s) against the reference identifier(s).

>> Again, the above is based on a very superficial reading of the
>> document.  It is not an official review, is not a substitute
>> for one, and is almost certainly not complete.

Thanks very much for providing this feedback. Once we can figure out how 
to address some of it, I'm sure the document will be much improved.

Peter