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

From: "Stefan Santesson" <[email-masked]>
Date: Mon, 26 Sep 2005 01:08:53 +0100

Peter,

Thanks for this input.

As I understand it (correct me if I'm wrong), one of the issues with punycode is that it efficiently translates an I18n domain name (IDNA) into a valid ASCII encoded domain name. Looking only at the punycode encoded domain name it might be hard to know whether the ASCII characters represents the domain name in the form it was intended to be displayed or if it is a punycoded IDNA.

This is why UTF8String provide better functionality for UI design, because if you have the domain name in UTF8, you know if this is an IDNA and thus can easily display it correctly in certificate management UIs.

If, as you say, the binary data sent to the DNS contains 7-bit ASCII encoded characters, I think this is yet another reason why OCTET STRING for this new name form seems like a less attractive solution. 

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: Peter Sylvester [mailto:[email-masked]]
> Sent: den 24 september 2005 16:00
> To: Paul Hoffman
> Cc: Russ Housley; Stefan Santesson; [email-masked]
> Subject: Re: draft-ietf-pkix-srvsan-00
> 
> 
> 
> >
> > Russ is completely correct: don't convert if you don't have to, DNS is
> > a binary transport, so OCTET STRING is the correct way to not lose data.
> 
> BER, DER, PER are binary encoding rules, but you still carry textual data.
> The DNS doesn't carry uninterpreted OCTETS, it carry labels and encoded
> form
> of labels. And currently we only have ASCII labels.
> 
> (I think Karl had in mind to code each label in an octet string).
> 
> 2.3.3. Character Case
> 
> For all parts of the DNS that are part of the official protocol, all
> comparisons between character strings (e.g., labels, domain names, etc.)
> are done in a case-insensitive manner.  At present, this rule is in
> force throughout the domain system without exception.  However, future
> additions beyond current usage may need to use the full binary octet
> capabilities in names, so attempts to store domain names in 7-bit ASCII
> or use of special bytes to terminate labels, etc., should be avoided.
> 
> 
> I "like" the 'however", in particular the relation between
> case sensitivity.
> After 18 years, I still haven't seen future additions. Even
> I18n avoided UTF8. Of course, one could ask that the binary
> capabilities are reserved for non textual application?
> The quote above does not indicate whether it is intended
> to encode non textual labels like pictograms using 8 bits
> or whether the DNS is reserved for text.
> 
> I don't buy the need for 8bits for the proposed rfc.
> The service names are textual labels as any other.
> 
> Since the dNSAltname has IA5ext, I don't see why one
> needs anything different. where is the urgent need.
> If there is more need for 8 bits, one can make the
> dNSAltName a choice of IA5Text and whatever else
> would be a useful way to encode a sequence of
> pictures to use flags as an alternate non textual
> representation of some top level domains.
> (com=the logo of the "world company") :-)
> 
> I'd like to the certification software developpers to make
> code for octet strings: You need at least modes, in one you
> code the full octet string with double 0 at the end etc, and
> in another way, you code just text.
> Explain to someone that a subjectAltname dNSName has a textual
> interface (which may or may not be I18N capable), and
> in the serviceName you need some other things because
> it is an octet strings,
> 
> >
> > --Paul Hoffman, Director
> > --VPN Consortium
> >
> >
> >
> 
> 
> --
> To verify the signature, see http://edelpki.edelweb.fr/
> Cela vous permet de charger le certificat de l'autorité;
> die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.