At 8:57 PM -0400 7/17/10, John C Klensin wrote:
--On Saturday, July 17, 2010 08:42 -0700 Paul Hoffman
<paul(_dot_)hoffman(_at_)vpnc(_dot_)org> wrote:
...
(2) In Section 4.4.2, note that there are definitional and
procedural problems if one tries to talk about a single rule
for full domain names. It is possible, and has been the only
option until very recently, for a fully-qualified IDN to
contain both "traditional" and "internationalized" labels.
IDNA2008 avoided a number of definitional problems by being
defined strictly in terms of labels for just that reason.
In particular, conversion of an all-ASCII label to an A-label
is undefined and meaningless: such a label is not a U-label
and hence cannot be converted. One needs to parse the string
into labels, determine for each label whether it is
"traditional" or
"internationalized", and then apply the appropriate rule. I'd
recommend rewriting 4.4.1 and 4.4.2 in terms of labels, not
FQDNs.
Here we (may) disagree. 4.4.2 is already in terms of labels:
If the source domain of a reference identifier is an
internationalized domain name, then an implementation MUST
convert every label in the domain name to an A-label before
checking the domain name.
Are you saying that the correct wording should elide "If the
source domain of a reference identifier is an
internationalized domain name, then" and just start at "An
implementation MUST"? That would work for me.
That would probably be an improvement. But my problem was with
"every label" and a sticky detail of IDNA2008: the only things
that can be converted to A-labels are U-labels. One cannot
convert an LDH label to an A-label, nor can one convert
something that was already an A-label into an A-label. Those
operations are just not defined. So I think this should be
"every internationalized label" or (probably better) "every
non-traditional label" or something to that effect.
Sounds good to me. Suggested edit for Paul and John to sing kumbaya:
4.4.2. Checking of Internationalized Domain Names
The term "internationalized domain name" refers to a DNS domain name
that conforms to the overall form of a domain name (dot-separated
labels) but that can include Unicode code points outside the
traditional US-ASCII range, as explained by and [IDNA2008].
An implementation MUST convert every non-traditional label in the
domain name to an A-label before checking the domain name.
(3) Note that anything that requires that an application
program parse a FQDN that might be an IDN into labels should
probably have a Security Considerations note about the risks
if various dotoids leak into the relevant environment.
Errrr, why should this document be forced to have such a
warning when the IDNA2008 documents don't?
The IDNA2008 base document sort of dodge the problem by dealing
with labels, not FQDNs.
... fully dodge...
If I recall, you have some "beware of
leaks" language in Mapping, but I might be wrong.
We talk a bit about leaking into the app; this document is about certs and
identities, and those identities don't necessarily come from the apps.
In any event,
the reason it occurred to me as something that might be useful
to say here is that the functions of this document would be,
IMO, particularly sensitive to having someone want to store a
name with the local label separator convention and that would be
a problem. Possibly not more serious than other places, but
still possibly worth mentioning.
But this would cause a false negative, not a false positive. It seems to me to
be the same as many false negatives such as the app storing U+00B2 instead of
U+0032.
In any event, I consider the topic worth mentioning but
definitely not a showstopper.
Agree.
--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf