At 8:57 PM -0400 7/17/10, John C Klensin wrote: >--On Saturday, July 17, 2010 08:42 -0700 Paul Hoffman ><paul.hoff...@vpnc.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@ietf.org https://www.ietf.org/mailman/listinfo/ietf
