[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: draft-ietf-pkix-srvsan-00
At 10:13 AM +0000 2/2/07, Stefan Santesson wrote:
Let's say that I encounter a domain name in the form "xn--exmple-cua.com"
This is the punycode equivalent of "exämple.com"
Is there any way the parser can know with 100% certainty if this
domain name was intended to be presented as "xn--exmple-cua.com" or
as "exämple.com".
Yes. It is fully described in the IDNA document. Read the section on
the ToUnicode function.
Both are valid domain names.
If the name is stored in UTF-8, no parser needs to wonder.
Of course. This was discussed in detail in the preparation of IDNA.
It is described in detail in the IDNA specification.
I think your logic is halting in one important aspect. Assuming that
UTF-8 to punycode conversion is simple, deterministic and straight
forward, why would it then be confusing to implementers?
If it is not simple, then the value of having the UTF-8 format is even bigger.
If UTF-8 -> punycode is simple, deterministic and widely deployed,
while punycode -> UTF-8 is somewhat more ambiguous, then there is an
obvious advantage of storing the dns name part in UTF-8.
If you think that having domain names in PKIX fields in two different
formats will not cause any confusion, that's fine. Neither you nor I
can prove our case. I simply think that one format is better than two.
Finally, I can't think of any situation where a certificate user
would need to match the srvName from a certificate with a dns name
of a certificate. They are not used for comparison with each other,
but to be compared with a data external to the certificate according
to local policy.
...and that data is in Punycode format if it comes from the DNS.
--Paul Hoffman, Director
--VPN Consortium