Subject: RE: srv based names

From: "Stefan Santesson" <[email-masked]>
Date: Wed, 3 Aug 2005 18:16:47 +0100

Manual validation by users is hardly the target here.
It rather a way for a client application to determine that it has reached a host that is authorized to deliver the service it searched for.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Kurt D. Zeilenga
> Sent: den 3 augusti 2005 07:24
> To: Russ Housley
> Cc: [email-masked]
> Subject: Re: srv based names
> 
> 
> Another problem with using the DNS name of a SRV RR as a
> service identifier is that they are totally alien to the
> user community.
> 
> URIs are not alien.  In fact, its a URI which the user
> actually sees on a side of the bus and enters into their
> user agent
> 
> What do you want your users' certificate view to see when
> manually checking the validity of a certificate (in clients
> which don't understand the necessary alternative subject
> name)?
> 
> Kurt
> 
> At 02:49 PM 8/3/2005, Russ Housley wrote:
> 
> >Thanks for following up; however, I do not think that Kurt's observation
> matters in many important contexts.  Stefan made a mistake by using a
> collection of LDAP servers as an example in his slides.  There are other
> services that do not have URLs.  As the discussion in the meeting showed,
> there are services for which we do not have URIs.  Kerberos KDC is one
> important example.  KRB-WG is specifying the use of certificates in their
> PK-INIT document, and the Kerberos KDC will be the subject of the
> certificate.
> >
> >Russ
> >
> >At 04:51 AM 8/3/2005, Love Hörnquist Åstrand wrote:
> >>I talked to Kurt Zeilenga after the meeting, and then understood what he
> >>was talking about. The uniformResourceIdentifier part of GeneralName
> (and
> >>this SubjectAltName) can be used instead of srv based names to limit
> what
> >>service the certificate is allowed to serve.
> >>
> >>Love

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 04 Aug 2005 02:17:34 +0200

>It rather a way for a client application to determine that it has reached a host that is authorized to deliver the service it searched for.

I see no reason why uniformResourceIdentifier cannot be used
for this excepting for the point that the current set of
URI schemes is insufficient.

I think it for more appropriate to engineer additional
URI schemes where needed than to use the strings intended
to be used to locate DNS SRV RR records as a more general
service identifier than they were intended to be.

It was noted your proposal was intended for use with
Kerberos.  I find this quite problematic given that
"EXAMPLE.COM" and "example.com" are two different
realms but one domain.  That is, the string
_kerberos._tcp.example.com is ambiguous.

Consider a realm called "REALM.TLD" (picking TLD for some
reason other than it being a valid TLD) operating using
non DNS SRV based location services and a client attempting
to verify that the server it contacted has an appropriate
issued certificate.  That client is not only configured
with knowledge of the CA which issued the certificate
for this service, but a collection of other trusted CAs.
An attacker can register REALM.TLD and then get one
of the other trusted CAs to issue a certificate to a
rough service.

Now, it might be argued that this example is a bit
contrived, however I think it illustrates a class of
problems one will find using names of DNS RRs as
alt subjects.

>If you approach a service knowing its SRV service name then binding to that SRV name is most appropriate and functional.

To know the name of the SRV RR implies knowledge of
service-specific service information, such as a realm in
the Kerberos case and an ability to map this
information to a (purported) name of a DNS SRV RR.
Just because one can map a realm to a (purported) name
of a DNS SRV RR does mean it is appropriate to use the
result of this mapping as a subject identifier in a
certificate.  In the case of Kerberos, I think it
can be argued that the (purported) name of a DNS
SRV RR should not be used, or only used when the
service location policy for that realm is DNS SRV.
If the service location policy was to use a configured
location, use of the (purported) name would be
inappropriate.

I argue it is far more appropriate to use the
service-specific information in the subject identifier.
That is, use the Kerberos realm as the subject identifier.
Why wouldn't a Kerberos realm URI scheme met your needs
in this case? 

Kurt