ietf
[Top] [All Lists]

Re: Last Call: draft-saintandre-tls-server-id-check (Representation and Verification of Domain-Based Application Service Identity in Certificates Used with Transport Layer Security) to Proposed Standard

2010-07-17 10:42:47
At 5:22 AM -0400 7/17/10, John C Klensin wrote:
(1) In Section 4.4.1, the reference should be to the IDNA2008
discussion.  The explanations are a little better vis-a-vis the
DNS specs and it is a bad idea to reference an obsolete spec.

+1. I accept blame on this one, since I was tasked on an earlier version to 
bring the IDNA discussion up to date.

(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 anme.
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.

(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?

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf