Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-03

From: =JeffH <[email-masked]>
Date: Wed, 12 May 2010 13:29:51 -0700

> Is this text more accurate?
 >
 >    The subject field of a PKIX certificate is defined as a X.501 type
 >    Name and known as a Distinguished Name (DN) -- see [X.501] and
 >    [PKIX].  A DN is an ordered sequence of Relative Distinguished Name
 >    (RDNs), where an RDN is a set (i.e., an unordered group) of type-and-
 >    value pairs [LDAP-DN], each of which asserts some attribute about the
 >    subject of the certificate.

yes, IMV.

 > BTW I don't see any evidence for the following claim in RFC 4514:
 >
 >    The RDNs are ordered in the DN sequence from
 >    most general to most specific.

It is in X.501 (V3 (4th edition) section 9.7)..

   The distinguished name of a given object is defined as that name which
   consists of the sequence of the RDNs of the entry which represents the
   object and those of all of its superior entries (in descending order).

However, various (many? most?) CAs don't have an actual X.500 / LDAP directory 
with actual entries for the subjects of the certs they issue, and so concoct 
their subjectName DNs outta thin air (more or less) and so the notion that the 
RDNs in such DNs are ordered from most general to most specific doesn't 
necessarily hold (from what I understand).

So I'm not sure right now what to say about that. I suspect we can still 
stipulate that the only RDN having attr type of CN that we'll pay attention to 
is the one at the far end of the RDN sequence comprising the DN.

=JeffH

---

From: Sean Turner <[email-masked]>
Date: Wed, 12 May 2010 17:36:20 -0400

=JeffH wrote:
> However, various (many? most?) CAs don't have an actual X.500 / LDAP 
> directory with actual entries for the subjects of the certs they issue, 
> and so concoct their subjectName DNs outta thin air (more or less) and 
> so the notion that the RDNs in such DNs are ordered from most general to 
> most specific doesn't necessarily hold (from what I understand).
> 
> stipulate that the only RDN having attr type of CN that we'll pay 
> attention to is the one at the far end of the RDN sequence comprising 
> the DN.

I think a lot of DNs got concocted because X.500 implementers assumed 
the examples in X.501 were normative.  That is c=, o=, (4) ou=, cn=. 
But, you're might be right about no descending ordering can be 
assumed.  If you look at the subjectName in the datatracker 
certificate it's:

CN = *.ietf.org
OU = Terms of use at www.verisign.com/rpa (c)05
OU = Internet Engineering Task Force
O = IETF Trust
L = Reston
ST = Virginia
C = US

Is an organization more or less specific than a location?

spt

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 12 May 2010 16:36:48 -0600

On 5/12/10 3:36 PM, Sean Turner wrote:

> But, you're might be right about no descending ordering can be assumed. 
> If you look at the subjectName in the datatracker certificate it's:
> 
> CN = *.ietf.org

The Internet encompasses all locations, so in this case C = US is much
more specific than OU = Internet Engineering Task Force. ;)

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 12 May 2010 16:37:59 -0600

>>    subject of the certificate.

Good.

> attention to is the one at the far end of the RDN sequence comprising

We can stipulate that, but is it realistic?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Wed, 12 May 2010 15:58:23 -0700

> We can stipulate that, but is it realistic?

Yes, since that's what RFC 2818 said.

Love

---

From: ArkanoiD <[email-masked]>
Date: Thu, 13 May 2010 03:02:38 +0400

It does not really answer the question, we should analyse certificates seen
"in the wild" ;-)

---

From: Martin Rex <[email-masked]>
Date: Thu, 13 May 2010 01:22:04 +0200 (MEST)

> OU = Internet Engineering Task Force

When I received a request for help ~2 years ago doing a more complex
processing/mapping/evaluation of Subject(Alt)Names and IssuerNames
from X.509 certificates during logon at the application level,
we created an additional intermediate format between
ASN.1 DER and string representation.  It consists of a
(pre-sorted by OID) linked list of entries where each of
the list entries carries the attribute (or sAN) OID and
an UTF8 representation of the attribute value.
(plus side info, like the original position in
 the ASN.1 DER encoding, whether it was the first
 element of an RDName set, and some other stuff).

Basically the divide-and-conquer approach.  split one problem
into two smaller problems that are easier to solve.

So when looking for a CN in subject, the app requests the
subject name from a given cert an searches the resulting
list for all occurences of the 2.5.4.cn(3) OID aka {3, "\x55\x04\x03" }

Similarly, when looking for a server endpoint sAN match, the app requests
the subjectaltname from a given cert and searches the resulting list
for all occurrences of the dNSName pseudo-OID {4, "\x55\x1D\x11\x02" }
and iPAddress pseudo-OID {4, "\x55\x1D\x11\x07" } as described in rfc2818.

Concerning the list of sANs in the -04 draft, I came across
these two Microsoft "other" sANs while implementing this:

   "msUPN"  {10, "\x2B\x06\x01\x04\x01\x82\x37\x14\x02\x03"}
   "msGUID" { 9, "\x2B\x06\x01\x04\x01\x82\x37\x19\x01"    }

   "msUPN"  = 1.3.6.1.4.1.311.20.2.3
   "msGUID" = 1.3.6.1.4.1.311.25.1

Which is also mention at the bottom of this page
  http://technet.microsoft.com/en-us/library/cc736326%28WS.10,printer%29.aspx

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 13 May 2010 01:29:19 +0200 (MEST)

> We can stipulate that, but is it realistic?

An X.509 cert may contain several CN= components,
although this is much less common that multiple OU= components.

My own server endpoint identification code (including the original
string-representation-based) has always been checking all CN=
components of a DName and no matter where within the dinstinguished
name they are, but I noticed that Firefox and IE seem to check
only one of them.

-Martin

---

From: Joe Orton <[email-masked]>
Date: Thu, 13 May 2010 08:20:13 +0100

> Yes, since that's what RFC 2818 said.

RFC 2818 says that you use the most specific CN RDN.  Not the most 
specific RDN, iff it is a CN.  That is completely different.

The stats I ran said that maybe 10/20% of existing certs place the CN 
somewhere other than the most specific field.  Who out there is going to 
change their software to implement a CN matching algorithm which breaks 
interop with 10/20% of SSL servers?

Regards, Joe

---

From: Kaspar Brand <[email-masked]>
Date: Thu, 13 May 2010 09:40:12 +0200

> It does not really answer the question, we should analyse certificates seen

Here's some data. It's from a sample of about 90,000 non self-issued
certs (from commercial CAs, most likely reflecting shares like those in
http://news.netcraft.com/SSL-survey). The data are from the beginning
of 2009, but I don't think the situation has considerably changed
in between.

The second colum shows the RDNs in the order they have in the
ASN.1 subject SEQUENCE, while the first colum gives the number of
occurences of such a cert (only the "top 15" are shown).

  19464 C, O, OU, OU, OU, CN
  15657 C, ST, L, O, OU, CN
   6859 O, OU, CN
   5603 C, ST, L, O, OU, OU, CN
   4983 C, ST, L, O, OU, OU, OU, OU, CN
   4813 C, ST, L, O, CN
   4746 O, OU, OU, OU, CN
   3915 C, postalCode, ST, L, streetAddress, O, OU, OU, OU, CN
   3884 C, postalCode, ST, L, streetAddress, O, OU, OU, CN
   2820 O, CN, OU
   2726 C, ST, L, O, OU, CN, emailAddress
   1565 C, OU, O, CN
   1401 OU, OU, CN
   1311 C, postalCode, ST, L, streetAddress, O, OU, CN
   1212 C, ST, L, O, OU, OU, OU, CN
  [...]

>>> We can stipulate that, but is it realistic?

Note that "the one at the far end of the RDN sequence" should not imply
that the CN should necessarily be the very last element of the subject.
Looking at cases like

   2820 O, CN, OU
   2726 C, ST, L, O, OU, CN, emailAddress

I would only stipulate that if multiple CNs occur in the subject
(and they can be found in that sample, btw), only the last one
is taken into account.

Kaspar