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

From: Paul Hoffman <[email-masked]>
Date: Fri, 12 Jan 2007 15:06:49 -0800

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