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

From: Paul Hoffman <[email-masked]>
Date: Thu, 29 Sep 2005 21:07:09 -0700

At 11:24 AM +1000 9/30/05, Manger, James H wrote:
>  > DNS names are binary blobs. Most of them have the semantics of ASCII
>>  characters, but not all of them. 'Twas ever thus. This rule is for
>>  all DNS records, not just SRV records.
>
>Every (internet) protocol is a "binary blob" -- computers only 
>exchange bits & bytes.  When the semantics are characters a charset 
>needs to be selected.

Note that you are saying that the SRV records we care about have the 
semantics of characters. The SRV spec does not say that, but the PKIX 
WG can (I believe) say that we are limiting our focus to just 
character-based labels.

>Today, everyone knows there are lots of different charsets (eg Java 
>1.5 supports 148 charsets) and (hopefully) we are careful to 
>explicitly state the charset when required.  Historically, there are 
>various situations were the charset is undefined.  Names in DNS seem 
>to fit this last category [it was 1987, an obvious candidate like 
>UTF-8 didn't exist].

...but US-ASCII did. The DNS community explicitly chose to not make 
DNS labels characters, but instead binary. That is a mostly-forgotten 
decision, because nearly everyone thinks of DNS labels as characters.

>The DNS spec explicitly says storing domain names in 7-bit ASCII 
>"should be avoided"

...because they are not characters.

>My vote: UTF8String (without any punycode encoding)

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.

--Paul Hoffman, Director
--VPN Consortium