Subject: srv based names

From: Love Hörnquist Åstrand <[email-masked]>
Date: Wed, 03 Aug 2005 10:51:54 +0200

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: Love Hörnquist Åstrand <[email-masked]>
Date: Wed, 03 Aug 2005 12:17:15 +0200

> service the certificate is allowed to serve.

to hopefully clarify,

If the service we want to bind the certificate have a uri defined. Example:
jabber:[node@]domain[/resource]. Then the step of its to bind the DNS
SRV-rr lookup to the service is not needed. Instead the client can bind the
thing that user entered (user@domain) to the certificate containing the uri
for the same service.

The only problem is that services need to specify uri for itself. That
might not be obvious when the protocol using DNS SRV-rr is written to
support certificates, for example, by using TLS.

Love

---

From: Russ Housley <[email-masked]>
Date: Wed, 03 Aug 2005 08:49:02 -0400

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

---

From: Stephen Kent <[email-masked]>
Date: Wed, 3 Aug 2005 09:38:07 -0400

>support certificates, for example, by using TLS.

The clarification is helpful, and it suggests 
that this solution works best if the application 
expresses the service name in a URI form. Many 
apps do that, but not all, as Russ noted.

Steve

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 03 Aug 2005 16:17:49 +0200

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. 

I don't view it as a mistake as most protocols which use SRV RRs
use them similar to how LDAP does.  I would have said the same
thing if he had used http, smtp, imap, etc..

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

So create more URI schemes.   Names of SRV RRs are not, IMO,
good service identifiers.  URIs, in particular, URLs, are.

I note that there are also services which don't have SRV support,
one could take the argument that since some services don't have
URIs and some services don't have SRV RRs specifications, we
should introduce yet another service identifier form for use
as alternative subject names in certificates.

We only need one general way of specify Internet services
as alternative subject names.  I think URLs is the best
general service identifier form available, certainly far
more general than the DNS name of an SRV RR.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 03 Aug 2005 16:24:28 +0200

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
>

---

From: Stephen Kent <[email-masked]>
Date: Wed, 3 Aug 2005 11:28:54 -0400

>service identifier is that they are totally alien to the

To the extent that a user (vs. an app developer) has to deal with the 
string, I agree that URIs are much less alien, but I don't think that 
we're discussing examples where a user will be dealing with these 
values.

>actually sees on a side of the bus and enters into their

"side of the bus?" A user enters a URI for web-based accesses, but 
not for all applications. Stefan's major motivation, as he noted 
later, is Kerberos, and I would not expect to see a URI used there.

>which don't understand the necessary alternative subject name)?

I don't think anyone is suggesting that a user will view a cert to 
perform the check. It should be automated, performed by software.  So 
the last argument above is not relevant.

---

From: David Chadwick <[email-masked]>
Date: Wed, 03 Aug 2005 17:28:28 +0100

Steve

as everyone at the meeting seemed to agree (I did not hear any dissent 
on this point), was that the SRV name was an attribute of the 
certificate holder.

The discussion then ranged over what is the best place to store this 
attribute in the certificate.

Dennis suggested the subjectDirectoryAttributes extension. You disagreed 
  and one of your reasons was that an OID would be needed for this. But 
an OID is also needed for the subjectAltName extension. So this cannot 
be a valid reason for discounting subjectDirectoryAttributes. You also 
said that the attribute may not be stored in a directory, but that also 
is not a valid reason for not using this extension. There are many 
attribute types defined in X.520 (and some RFCs) that are never actually 
stored in the directory :-)

I agree with Dennis for the following reasons.

i) using the subjectDirectoryAttributes extension allows you to define 
this attribute in a complete and compact way. This is what we actually 
want to do, regardless of whether it is stored in the directory or not. 
In particular, we need to specify the matching rules for the attribute 
value. How is the value stored in the DNS RR to be compared with the 
value stored in the cert. Bitstring comparison? Case ignore string 
comparison? Defining the attribute as a directory attribute will ensure 
that you cover this point properly. If you define it as a subjectAltName 
extension you will still need to specify the matching rules. Have you 
thought of that?

2) if the attribute is defined as a directory attribute, then we also 
have the option of storing it in the directory, and creating a virtuous 
circle as shown in the attached diagram. The DNS SRV RR points to a 
field in the cert, and this points to an attribute in the directory, and 
this directory entry can point to the DNS.

regards

David

-- 

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: [email-masked]
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://sec.cs.kent.ac.uk
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************

---

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

At 03:38 PM 8/3/2005, Stephen Kent wrote:

>The clarification is helpful, and it suggests that this solution works best if the application expresses the service name in a URI form. Many apps do that, but not all, as Russ noted.

The lack of sufficient URI schemes implies a need for
additional URI schemes, possibly a general service
URI scheme.

The lack of sufficient URI schemes does not imply that we
should use names of DNS SRVs RRs as general service identifiers.

-- Kurt

---

From: Stephen Kent <[email-masked]>
Date: Thu, 4 Aug 2005 03:25:12 -0400

At 5:28 PM +0100 8/3/05, David Chadwick wrote:
>Steve
>
>as everyone at the meeting seemed to agree (I did not hear any 
>dissent on this point), was that the SRV name was an attribute of 
>the certificate holder.
>
>Dennis suggested the subjectDirectoryAttributes extension. You 
>disagreed  and one of your reasons was that an OID would be needed 
>for this. But an OID is also needed for the subjectAltName 
>extension. So this cannot be a valid reason for discounting 
>subjectDirectoryAttributes. You also said that the attribute may not 
>be stored in a directory, but that also is not a valid reason for 
>not using this extension. There are many attribute types defined in 
>X.520 (and some RFCs) that are never actually stored in the 
>directory :-)

I suggested that storing a DNS-centric attribute in the X.500 
directory was anomalous, and merely noted that the lack of an 
existing OID for such an attribute was indicative of this being 
anomalous. Of course one can assign an OID for anything, but that 
does not make it appropriate :-).  Also, as Stefan noted in his 
reply, I'm not sure that this extension is widely used in any uniform 
fashion, since it is a catch-all that could contain a wide range of 
arbitrary data.

>i) using the subjectDirectoryAttributes extension allows you to 
>define this attribute in a complete and compact way. This is what we 
>actually want to do, regardless of whether it is stored in the 
>directory or not. In particular, we need to specify the matching 
>rules for the attribute value. How is the value stored in the DNS RR 
>to be compared with the value stored in the cert. Bitstring 
>comparison? Case ignore string comparison? Defining the attribute as 
>a directory attribute will ensure that you cover this point 
>properly. If you define it as a subjectAltName extension you will 
>still need to specify the matching rules. Have you thought of that?

I agree that we need to specify matching rules, but one need not make 
this string a directory attribute to specify matching rules. After 
all, the DNS has matching rules for its entries. Assigning an OID and 
using the existing subject directory attribute extension would be 
compact, but I'm not sure how much weight to give to that 
consideration.

>2) if the attribute is defined as a directory attribute, then we 
>also have the option of storing it in the directory, and creating a 
>virtuous circle as shown in the attached diagram. The DNS SRV RR 
>points to a field in the cert, and this points to an attribute in 
>the directory, and this directory entry can point to the DNS.

An interesting observation, but it would be more compelling if we had 
some text explaining how this cyclic linkage improves security, as 
opposed to opportunities for creating more things that have to be 
maintained in synch.

Steve