RE: draft-ietf-pkix-srvsan-00

[Stefan Santesson <stefans@xxxxxxxxxxxxx>]

Well,

You could perhaps help straighten one thing out about coding decoding punycode.

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". Both are valid domain names.
If the name is stored in UTF-8, no parser needs to wonder.

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.

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.
But even if it was the case, I can't see the serious challenge of having one in punycode and the other in UTF-8. It really feels like a trivial problem not worth re-opening what was previously agreed.



Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: Paul Hoffman [mailto:paul.hoffman@xxxxxxxx]
> Sent: den 1 februari 2007 21:17
> To: Stefan Santesson; ietf-pkix@xxxxxxx
> Subject: RE: draft-ietf-pkix-srvsan-00
>
> At 5:01 PM +0000 2/1/07, Stefan Santesson wrote:
> >Different name forms are allowed to have different encoding, that is
> >nothing new.
> >So why do you come to the conclusion that the dNSName alt name must
> >have the same format as a service name?
> >You seem to state that this is an obvious requirement, but it is not
> >obvious to me.
>
> It is obvious to me that having different encoding rules for domain
> names is likely to confuse implementers. There is nothing in SRV
> names that make them any different than "regular" domain names.
>
> >We discussed this in the WG and concluded that there are advantages
> >in using UTF-8 encoding and storing the service name in a form where
> >it can be printed and displayed. There must be a rationale why we
> >should move away from this.
>
> I have given mine; you may or may not like it.
>
> --Paul Hoffman, Director
> --VPN Consortium