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

From: Stefan Santesson <[email-masked]>
Date: Mon, 19 Mar 2007 14:58:28 +0000

Paul,

I did not see any reply to this e-mail.

I spoke to Russ, and he suggested that apparently the whole approval process will be problematic if we define name forms as this on in UTF-8.
It trouble me, if we need to specify all name forms in ASCII from now on because I18N makes name forms too ambiguous to make a standardization effort reasonable.

I still think UTF-8 is the right thing to do, but might be willing to accept IA5 if this group will accept that as this apparently would make this document progress a lot easier.

So I either would like to have this group accept the choice of IA5 carrying punycode if necessary, or to present a definition of how to store names in UTF-8 in a way that would be acceptable to the IESG. I've tried as hard as I can but yet not succeeded.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Stefan Santesson
> Sent: den 2 februari 2007 11:14
> To: Paul Hoffman; [email-masked]
> Subject: RE: draft-ietf-pkix-srvsan-00
>
>
> Well,
>
> You could perhaps help straighten one thing out about coding decoding
> punycode.
>
> Let's say that I encounter a domain name in the form "xn--exmple-
> cua.com"
> This is the punycode equivalent of "exämple.com"
>
> Is there any way the parser can know with 100% certainty if this domain
> name was intended to be presented as "xn--exmple-cua.com" or as
> "exämple.com". Both are valid domain names.
> If the name is stored in UTF-8, no parser needs to wonder.
>
> I think your logic is halting in one important aspect. Assuming that
> UTF-8 to punycode conversion is simple, deterministic and straight
> forward, why would it then be confusing to implementers?
> If it is not simple, then the value of having the UTF-8 format is even
> bigger.
> If UTF-8 -> punycode is simple, deterministic and widely deployed,
> while punycode -> UTF-8 is somewhat more ambiguous, then there is an
> obvious advantage of storing the dns name part in UTF-8.
>
> Finally, I can't think of any situation where a certificate user would
> need to match the srvName from a certificate with a dns name of a
> certificate. They are not used for comparison with each other, but to
> be compared with a data external to the certificate according to local
> policy.
> But even if it was the case, I can't see the serious challenge of
> having one in punycode and the other in UTF-8. It really feels like a
> trivial problem not worth re-opening what was previously agreed.
>
>
>
> Stefan Santesson
> Senior Program Manager
> Windows Security, Standards
>
> > -----Original Message-----
> > From: Paul Hoffman [mailto:[email-masked]]
> > Sent: den 1 februari 2007 21:17
> > To: Stefan Santesson; [email-masked]
> > Subject: RE: draft-ietf-pkix-srvsan-00
> >
> > At 5:01 PM +0000 2/1/07, Stefan Santesson wrote:
> > >Different name forms are allowed to have different encoding, that is
> > >nothing new.
> > >So why do you come to the conclusion that the dNSName alt name must
> > >have the same format as a service name?
> > >You seem to state that this is an obvious requirement, but it is not
> > >obvious to me.
> >
> > It is obvious to me that having different encoding rules for domain
> > names is likely to confuse implementers. There is nothing in SRV
> > names that make them any different than "regular" domain names.
> >
> > >We discussed this in the WG and concluded that there are advantages
> > >in using UTF-8 encoding and storing the service name in a form where
> > >it can be printed and displayed. There must be a rationale why we
> > >should move away from this.
> >
> > I have given mine; you may or may not like it.
> >
> > --Paul Hoffman, Director
> > --VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 19 Mar 2007 19:12:36 +0100

>I did not see any reply to this e-mail.

I sent it to the mailing list over a month ago. Please see the WG 
archives: <http://www.imc.org/ietf-pkix/mail-archive/msg04411.html>.

--Paul Hoffman, Director
--VPN Consortium

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 19 Mar 2007 21:44:51 +0000

Paul,

I'm sorry I missed this e-mail from you.

> >Finally, I can't think of any situation where a certificate user
> >would need to match the srvName from a certificate with a dns name
> >of a certificate. They are not used for comparison with each other,
> >but to be compared with a data external to the certificate according
> >to local policy.
>
> ...and that data is in Punycode format if it comes from the DNS.

There seem to be a misconception that the srvname will be compared with any srv record.

The srv record accessed from DNS will be used to locate the service of a particular domain.
So both domain and service name is pre established knowledge. The configuration of domain and service may be locally stored in any character format, but it will be converted to punycode before querying the DNS.

Upon receiving the certificate of the host, the client will compare that its pre-configured requirement of service and domain is consistent with the srvsan in the certificate. It seems that this will be straightforward, even if that name is stored in UTF-8. If nothing else, the client can do a to-ascii conversion of the UTF-8 stored name in the certificate.

So clearly, both methods work and this should only be a matter of taste.
My and others prefer to move towards the format where the data is available in readable format without conversion. We will probably have to go there anyway for internationalized e-mail, so there will most likely not be a single character format for domain name parts of different name forms.

What I don't understand is why you feel that the current approach is so bad that it needs to block the document.
What is the problem being so severe that we have to change what was previously agreed?

Stefan Santesson
Senior Program Manager

> Sent: den 2 februari 2007 18:02
> At 10:13 AM +0000 2/2/07, Stefan Santesson wrote:
> >Is there any way the parser can know with 100% certainty if this
> >domain name was intended to be presented as "xn--exmple-cua.com" or
> >as "exämple.com".
>
> Yes. It is fully described in the IDNA document. Read the section on
> the ToUnicode function.
>
> >Both are valid domain names.
> Of course. This was discussed in detail in the preparation of IDNA.
> It is described in detail in the IDNA specification.
>
> If you think that having domain names in PKIX fields in two different
> formats will not cause any confusion, that's fine. Neither you nor I
> can prove our case. I simply think that one format is better than two.
>
> >Finally, I can't think of any situation where a certificate user
> >would need to match the srvName from a certificate with a dns name
> >of a certificate. They are not used for comparison with each other,
> >but to be compared with a data external to the certificate according
> >to local policy.
>
> ...and that data is in Punycode format if it comes from the DNS.
>
> --Paul Hoffman, Director
> --VPN Consortium