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
<[email protected]> 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:[email protected]]
Sent: Monday, December 26, 2022 9:53 PM
To: Valery Smyslov
Cc: [email protected]; ; [email protected]; 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
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
