Subject: RE: Where to story srv based names

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

I don't want to see this in subjectDirectoryAttributes.

A major reason is that many implementations (ours included) doesn't
parse that extension at all since it is practically not utilized.

But even despite that, I don't think this is a directory attribute and I
don't foresee it used as such. In my mind it fits much better within the
same extension as is used for URI, dnsName, IP address etc.

The matching is not dramatic. It is practically a case ignore exact
match. But you are right that we probably need to address it.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of David Chadwick
> Sent: den 3 augusti 2005 09:28
> To: Stephen Kent
> Cc: Kurt D. Zeilenga; Russ Housley; [email-masked]
> Subject: Where to story srv based names
> 
> 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: Russ Housley <[email-masked]>
Date: Thu, 04 Aug 2005 04:54:15 -0400

[ Speaking as a PKIX WG member and document author. ]

I do not want to see names appear in subjectDirectoryAttributes.  Not 
everything that can be done should be done.  If we agree that a standard is 
appropriate at all, I strongly prefer subjectAltName.