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

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 23 Sep 2005 16:25:18 +0100

For this to work there has to be some coding conventions defined within
the DNS standards (how to code and decode the characters into and from
OCTET STRING) which would need to be applied to this draft.

I see many places where conversion would have to take place related to
UIs if the OCTET STRING format is selected, such as in the CA
administration UI and in any cert viewer UI.

My gut feeling is that it is a bit less painful to include code
conversion in all UI events than do the code conversion during the
authentication process. And in fact, there might not even be a code
conversion required during authentication.

I assume the client before doing the DNS RR query, knows/stores
knowledge of the service name and domain name as strings and not as
binary OCTET STRING, and the client would then convert anyway in its DNS
query and response process. 

During authentication, the client could use its already stored string
knowledge about service and domain to compare with the content of the
certificate.

I admit that I'm speculating, but UTF8String sure feels as the preferred
solution.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: den 23 september 2005 15:56
> To: Stefan Santesson
> Cc: [email-masked]
> Subject: RE: draft-ietf-pkix-srvsan-00
> 
> Stefan:
> 
> The point that I wanted to discuss was the use of OCTET STRING to
carry
> exactly the sequence of octets that would appear in the DNS (without
the
> protocol portion).
> 
> The display issue is exactly the same as displaying information that
is
> retrieved from the DNS.  No better, and no worse.
> 
> Russ
> 
> At 09:35 PM 9/22/2005, Stefan Santesson wrote:
> >In the choice between UTF8String and OCTET STRING I definitely prefer
> >UTF8String since it makes the information displayable. IF we choose
> >OCTET STRING we need to specify which encoding we carry inside the
OCTET
> >STRING anyway.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 23 Sep 2005 09:24:56 -0700

At 12:09 PM -0400 9/23/05, Russ Housley wrote:
>Somehow, I have been unable to make my point.  I'll try one more time...
>
>The use of UTF8String introduces the need for conversion.  OCTET 
>STRING does not have the same need.
>
>DNS is a binary protocol.  It delivers a sequence of octets.  By 
>convention, that sequence of octets have historically been ASCII 
>characters.  And, the recent work on internationalization have 
>maintained this convention.  The ToASCII and ToUnicode routines 
>defined in RFC 3490 are used to make the conversions for IDNs 
>(Internationalized Domain Names).
>
>Therefore, it seems to me that the OCTET STRING is the form that 
>matches the sequence of octets that will actually be provided by a 
>DNS query.  Then, the ToUnicode routine is used to convert for 
>display to a human.

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.

--Paul Hoffman, Director
--VPN Consortium

---

From: Russ Housley <[email-masked]>
Date: Fri, 23 Sep 2005 12:09:22 -0400

The use of UTF8String introduces the need for conversion.  OCTET STRING 
does not have the same need.

DNS is a binary protocol.  It delivers a sequence of octets.  By 
convention, that sequence of octets have historically been ASCII 
characters.  And, the recent work on internationalization have maintained 
this convention.  The ToASCII and ToUnicode routines defined in RFC 3490 
are used to make the conversions for IDNs (Internationalized Domain Names).

Therefore, it seems to me that the OCTET STRING is the form that matches 
the sequence of octets that will actually be provided by a DNS 
query.  Then, the ToUnicode routine is used to convert for display to a human.

Russ

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 23 Sep 2005 11:00:47 -0700

At 09:24 AM 9/23/2005, Paul Hoffman wrote:
>>Therefore, it seems to me that the OCTET STRING is the form that matches the sequence of octets that will actually be provided by a DNS query.  Then, the ToUnicode routine is used to convert for display to a human.
>
>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. 

wouldn't SEQUENCE OF OCTET STRING be more appropriate?

Kurt

---

From: Russ Housley <[email-masked]>
Date: Fri, 23 Sep 2005 14:15:14 -0400

Kurt:

Yes, if you want to allow the other name to represent more than one SRV 
record.  No, if you want to include a separate other name instance for each 
SRV record, which is more consistent with the way that tow URLs would be 
represented.

Russ

At 02:00 PM 9/23/2005, Kurt D. Zeilenga wrote:
> matches the sequence of octets that will actually be provided by a DNS 
> >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.
>

---

From: Peter Sylvester <[email-masked]>
Date: Sat, 24 Sep 2005 16:00:19 +0200

>
> 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,

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 24 Sep 2005 08:18:00 -0700

My point is that each DNS name is a sequence of DNS
labels, each label being an octet string.

Kurt

At 11:15 AM 9/23/2005, Russ Housley wrote:

>Kurt:
>
>Yes, if you want to allow the other name to represent more than one SRV record.  No, if you want to include a separate other name instance for each SRV record, which is more consistent with the way that tow URLs would be represented.
>
>Russ
>

---

From: Michael Ströder <[email-masked]>
Date: Sun, 25 Sep 2005 11:23:59 +0200

> binary transport, so OCTET STRING is the correct way to not lose data.

But the DNS name is a character string! So best is to either stuff
Punycode in IA5String etc. or use UTF8String. Otherwise implementors
will store into it whichever character set / code page they like.

Ciao, Michael.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 25 Sep 2005 08:43:44 -0700

At 11:23 AM +0200 9/25/05, Michael Ströder wrote:
>But the DNS name is a character string!

In most uses, that's true; it's not true for all DNS names. Notice 
that RFC 2782 (the definition of SRV records) never uses the word 
"character". That is on purpose.

If the PKIX WG says that the subjectAltName for SRV records can only 
be used for SRV records that are characters, then you can say that 
subjectAltName has a character type. You can also assume that 
implementers will probably screw up and try to write subjectAltName 
for non-character SRV records and it will fail in inexplicable ways.

--Paul Hoffman, Director
--VPN Consortium

---

From: Tom Gindin <[email-masked]>
Date: Sun, 25 Sep 2005 11:09:18 -0400

Kurt:

        Stefan's point about name constraints argues relatively strongly 
in favor of a string-based matching rule, which suggests a string 
encoding.  In particular, the existing URI or DNS name constraint rules 
could appropriately be applied to this OTHER-NAME form - if a CA may only 
certify URI's within a given set of domains, I can't see why it should be 
allowed to certify a user with this name form outside those domains. 
Either of those matches are obviously character string matches, and they 
don't make sense as pure binary ones given the distinction between periods 
and all other characters - although you could implement a pure binary 
trailing substring match if the constraint string started with a period.

                Tom Gindin

"Kurt D. Zeilenga" <[email-masked]>
Sent by: [email-masked]
09/24/2005 11:18 AM
 
        To:     Russ Housley <[email-masked]>
        cc:     "Stefan Santesson" <[email-masked]>, Paul Hoffman 
<[email-masked]>, [email-masked]
        Subject:        RE: draft-ietf-pkix-srvsan-00

Kurt

>Yes, if you want to allow the other name to represent more than one SRV 
record.  No, if you want to include a separate other name instance for 
each SRV record, which is more consistent with the way that tow URLs would 
be represented.
matches the sequence of octets that will actually be provided by a DNS 
query.  Then, the ToUnicode routine is used to convert for display to a 
human.

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 29 Sep 2005 13:52:05 +0200

> "character". That is on purpose.

Could you give an example of such a null terminated label.

The RFC is composed of characters. Without any other interpretation
the statement below means to me that _lpad._tcp.example.com
are characters

If a SRV-cognizant LDAP client wants to discover a LDAP server that
   supports TCP protocol and provides LDAP service for the domain
   example.com., it does a lookup of

      _ldap._tcp.example.com

   as described in [ARM]. 

Ooups a reference to "work in progress".

Everything in this text is character based except for example this
paragraph and its wonderful last sentence. 

   Priority
        The priority of this target host.  A client MUST attempt to
        contact the target host with the lowest-numbered priority it can
        reach; target hosts with the same priority SHOULD be tried in an
        order defined by the weight field.  The range is 0-65535.  This
        is a 16 bit unsigned integer in network byte order.

Anyway there are dots as separators, and not nuls, etc.  

> for non-character SRV records and it will fail in inexplicable ways.

I can assume that such an SRV record sepc  would need to define a textual representation 
following the spec

    _Service._Proto.Name TTL Class SRV Priority Weight Port Target

and this textual representation needs to be done in such a way that it
doesn't collide with the ASCII subset etc etc. 

IMO he question is whether the textual representation "Name" is ASCII, 
UTF8 or ISO-latin1, or.

The text of this RFC is ASCII, there is no indication whether the example
in the text is in another character set.

---

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

>Could you give an example of such a null terminated label.

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.

>in the text is in another character set.

The character set of the RFC is irrelevant.

--Paul Hoffman, Director
--VPN Consortium

---

From: Tom Gindin <[email-masked]>
Date: Fri, 30 Sep 2005 00:18:24 -0400

Paul:

        The character set of the RFC is irrelevant, but the character set 
of DNS, RFC 822, and URI name constraints is not irrelevant.  These fields 
do contain DNS names, they are formatted as character strings, and their 
primary use is to be compared to certificate fields which are then 
compared to DNS names.  If one cannot compare the dNSName member of 
GeneralName (currently an IA5String) to a DNS name, what good is that 
member?

Tom Gindin

Paul Hoffman <[email-masked]>
Sent by: [email-masked]
09/29/2005 10:11 AM
 
        To:     Peter Sylvester <[email-masked]>
        cc:     [email-masked]
        Subject:        Re: draft-ietf-pkix-srvsan-00

--Paul Hoffman, Director
--VPN Consortium

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 30 Sep 2005 12:34:57 +0200

> characters, but not all of them. 'Twas ever thus. This rule is for all 
> DNS records, not just SRV records.

DNS names are not binary blobs, they are null terminated labels for 
which at least a subset
of 7bit ascii is defined as characters AND in practice, you cannot have 
labels that have
dots in it etc. and you have ACE for domain names etc.

It is indeed true that the specification allows for 8 bits (255 combination)
without saying what they mean.

But I have aked you to give an example of an actual documented and 
specified use
that uses 8 bits where the data are not en encoding of some string.

> The character set of the RFC is irrelevant.

That's what I say, since it uses only ASCII, and nothing else
about the examples and specs, in particular nothing that
would allow to use iso-latin1 or utf8 in the examples,

RFC 3490 says:

   If a signaling system which makes negotiation possible between old
   and new DNS clients and servers is standardized in the future, the
   encoding of the query in the DNS protocol itself can be changed from
   ACE to something else, such as UTF-8.  The question whether or not
   this should be used is, however, a separate problem and is not
   discussed in this memo.

This means IMO that the labels are not binary blobs but encoded
characters depending on a possibly negotiatable encoding
rule. Thus the raw encoding in the request cannot be interpreted
without knowledge of the encoding types. "This octet string contains
an ACE encoded domain name / it encodes an UTF8 encoded name."

IMO this gives sufficient arguments not to use an uninterpretable
OCTET STRING encoding, but rather to use a string type.

UTF8 vs IA5text. I don't care too much because contrary to the
content in the DNS we have a tag  indicating the type

If compatiblity with the dNSName subjectAltname is an issue then
I think IA5 may be simpler.

We probably will see ACE encoded names inside UTF8.

Peter