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

From: "Manger, James H" <[email-masked]>
Date: Fri, 30 Sep 2005 11:24:17 +1000

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

SRV names (& DNS names) are obviously character strings: they are meant to be human-readable; the specification only uses characters (never hex digits, for instance) in its examples; comparisons are case-insensitive (bytes don't have a case); "." is the separator; the DNS spec says "...character strings (e.g., labels, domain names, etc.)" [RFC 1035, section 2.3.3] etc.

The charset for character strings in DNS is not explicitly defined.  It is implied that bytes values 0x00 to 0x7F map to characters as in the US-ASCII charset.  The DNS spec [RFC1035] recognizes that "future additions" may need more than this -- "to use the full binary octet capabilities in names".  Paul Hoffman & Russ Housley seem to assume this means (in future) an arbitrary byte array might be a valid SRV name.  I assume it means (in future) characters outside US-ASCII might be valid in an SRV name, which might require bytes values outside 0x00-0x7F to encode.  Under my assumption an SRV name is always a character string so a string type (eg UTF8String) is appropriate.

The DNS spec explicitly says storing domain names in 7-bit ASCII "should be avoided" so IA5String should be avoided (and should not have been used for rfc822Name, dnsName or uri alternative names).

Russ Housley's argument in favour of OCTET STRING said "first, you query the DNS for the service you want".  This is actually the second step.  First, you (the human user) state the service name you want (either typing it into a GUI or setting it in a configuration file).  This first human step should use human-friendly characters, not computer-friendly bytes.  The second step is forming a binary DNS query.  The crucial security step is comparing the service name in the certificate to the service name the user wanted: a character string comparison.

My vote: UTF8String (without any punycode encoding)

--
Charset = rules for encoding characters as bytes and vice versa