Subject: RE: draft-ietf-pkix-srvsan-00

From: Stefan Santesson <[email-masked]>
Date: Thu, 1 Feb 2007 17:01:19 +0000

Paul,

The format of DNS names in the dNSName Alt name is limited to ASCII. So there is no choice other than using the punycode format of an IDN.

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.

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.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Paul Hoffman
> Sent: den 13 januari 2007 00:07
> To: [email-masked]
> Subject: RE: draft-ietf-pkix-srvsan-00
>
>
> Greetings again. This document has just gone through IESG review and
> has garnered a bunch of DISCUSS comments. Some of them relate to the
> way that this document handles IDNs.
>
> Earlier on this list, I said:
>
> At 9:07 PM -0700 9/29/05, Paul Hoffman wrote:
> >If you restrict the SRV labels we are interested in to character
> >strings, that is a reasonable choice, but so is the on-the-wire
> >encoding, namely punycode. Using UTF-8 makes the string more
> >readable and editable in cert handling, using punycode means no
> >conversion between DNS queries and responses and the cert. Both have
> >merits and problems.
>
> While what I said was true, it was far from complete. For that I
> apologize. I should have added "but this is all moot because these
> domain names should be like all other domain names in the
> certificate, and 3280bis tell us exactly how to do that in section
> 7.2".
>
> The use of IDNs in this document should, of course, line up with
> 3280bis; it does not.
>
> draft-ietf-pkix-srvsan-04.txt:
>
>     Example: The "mail" service at na<LATIN SMALL LETTER I WITH
>     DIAERESIS>ve.net (an IDN, which becomes xn--nave-6pa.net when
> encoded
>     as an IDNA) would use the following 15-character SRVName value:
>
>         _mail.na<LATIN SMALL LETTER I WITH DIAERESIS>ve.net
>
>     Its 16-byte UTF-8 encoding is (in hex):
>
>         5F 6D 61 69 6C 2E 6E 61 C3 AF 76 65 2E 6E 65 74
>
> rfc3280bis, section 7.2:
>     To accommodate
>     internationalized domain names in the current structure, conforming
>     implementations MUST convert internationalized domain names to the
>     ASCII Compatible Encoding (ACE) format as specified in section 4 of
>     RFC 3490 before storage in the dNSName field.
>
> In short, srvsan says "put the DNS name in the certificate in UTF-8",
> while rfc3280bis says "put it in ASCII as Punycode". As some IESG
> members pointed out, that needs to be fixed.
>
> --Paul Hoffman, Director
> --VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 1 Feb 2007 12:17:08 -0800

>You seem to state that this is an obvious requirement, but it is not 

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

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 2 Feb 2007 10:13:43 +0000

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

> From: Paul Hoffman [mailto:[email-masked]]
> Sent: den 1 februari 2007 21:17
> To: Stefan Santesson; [email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 2 Feb 2007 09:02:00 -0800

At 10:13 AM +0000 2/2/07, Stefan Santesson wrote:
>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.

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