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

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

Yes, your scenario is valid. But I think there are other valid scenarios
as well where no OCTET STRING may be created.

The system start with the client knowing which service in which domain
it wants to connect. This is the initial knowledge and it is probably
stored in a string format at the client (not as binary data).

Then it MAY contact a DNS to lookup the host name in that domain. But it
may also have done it recently and cached the host name (skipping the
query - It will authenticate the host anyway), it may obtain the host
name by some other means (directory, database, mapping table, protocol
exchange using protocol X...) (just speculating but one of the points
with the changed structure is that use of DNS RR is optional and only
happens when appropriate)

When authenticating the server in the final step, it maps the
certificate service information to its initial knowledge which I assumed
was stored in string format.

It may sound that I'm dead locked on UTF8, but I'm not. I'm totally
open. I just think this is worth viewing from all angles before making
the call.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: den 23 september 2005 20:04
> To: Stefan Santesson
> Cc: [email-masked]; [email-masked]
> Subject: RE: draft-ietf-pkix-srvsan-00
> 
> Stefan:
> 
> Let's look at the whole system.  First, you query the DNS for the
service
> that you want, and then you contact that service, which provides its
> certificate.  The otherName is compared to the service that you want,
> which
> better match the string that was sent to the DNS in the beginning
(without
> the protocol part).  So, ultimately, you are comparing it to a string
that
> you also send to the DNS.
> 
> Russ
> 
> 
> At 01:33 PM 9/23/2005, Stefan Santesson wrote:
> >I actually understood :)
> >
> >I feel that I have not managed to explain myself.
> >
> >I don't compare the name in the cert with the content of any DNS RR
and
> >I don't include it into a DNS query.
> >
> >What I do is that I compare the service name in the certificate with
the
> >parameters that was preconfigured in my client.
> >
> >Does this change anything or do you still think OCTET STRING is
better.
> >
> >It seems that the string to binary conversion must be specified in
any
> >case.
> >
> >If you and WG consensus still think OCTET STRING is the best choice
for
> >this name form, then I'll change it.
> >
> >
> >Stefan Santesson
> >Program Manager, Standards Liaison
> >Windows Security
> >
> >
> > > -----Original Message-----
> > > From: Paul Hoffman [mailto:[email-masked]]
> > > Sent: den 23 september 2005 18:25
> > > To: Russ Housley; Stefan Santesson
> > > Cc: [email-masked]
> > > Subject: RE: draft-ietf-pkix-srvsan-00
> > >
> > > 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