RE: draft-ietf-pkix-srvsan-00

[Stefan Santesson <stefans@xxxxxxxxxxxxx>]

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: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-
> pkix@xxxxxxxxxxxx] On Behalf Of Paul Hoffman
> Sent: den 13 januari 2007 00:07
> To: ietf-pkix@xxxxxxx
> 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