Subject: RE: srv based names

From: "Stefan Santesson" <[email-masked]>
Date: Thu, 4 Aug 2005 06:56:36 +0100

The mechanism of SRV RR corresponds to domain names so names are not
ambiguous.

The SRV RR is interesting as a way to approach a domain searching for
appropriate recourses/services on that domain. That service may or may
not correspond to a URI scheme, but it will always correspond to a
specific SRV tag (or you could not search for it).

What do you gain by preventing me from binding to that service name in a
cert?

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:[email-masked]]
> Sent: den 4 augusti 2005 02:18
> To: Stefan Santesson
> Cc: Russ Housley; [email-masked]
> Subject: RE: srv based names
> 
> At 07:16 PM 8/3/2005, Stefan Santesson wrote:
> 
> >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.
> 
> 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

---

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

I note that the IESG is considering:
http://www.ietf.org/internet-drafts/draft-josefsson-dns-url-12.txt

Given the ability to write this service identification
information as the URL:
        dns:///_kerberos._tcp.example.com?class=IN;type=SRV

in a certificate, why we need another way express this
service identification information in a certificate.

Kurt