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

[Martin Rex <[e-mail]>]

Sean Turner wrote:
> 
> > 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.
> 
> 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

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