Re: [IPsec] Matching of IKE ID on certificate subject and RDN ordering

[Tobias Brunner <[e-mail]>]

Hi Paul,

> For openssl, when checking the subject of the cert, it matches in this
> order. but when I generated the same certificate with nss cert-util
> and re-read it back in openssl, it showed me:
> 
>  	CN=server, OU="Global, Support, Services", O=Test Example, L=Brno, ST=Moravia, C=CZ
> 
> Note that C= and CN= are swapped. These are differences in the binary data, not the presentation.

That's because, according to the documentation and examples, NSS
certutil follows RFC 1485 when it comes to string representations of
DNs, which states:

  The name is presented/input in a little-endian order (most significant
  component last).

The latest RFC that replaced it, RFC 4514, states it this way, which is
a bit clearer:

  Otherwise, the output consists of the string encodings of each
  RelativeDistinguishedName in the RDNSequence ..., starting with the
  last element of the sequence and moving backwards toward the first.

Why the last RDN first?  Could be to see the CN immediately, which
usually identifies the actual entity.

What you see in OpenSSL is the physical representation in the ASN.1
encoding of the certificate, i.e. the RDNs in their actual order in the
RDNSequence.  We follow the same principle in strongSwan when logging
and parsing DNs.

> So technically, when we expect one, receiving the other order would be
> wrong. So should we really do matching based on the same order of RDNs.
> What do other implementations do?

In strongSwan we have an option (charon.rdn_matching) that allows
changing how DNs in certificates are matched against configured IKE
identities.  It defaults to 'strict', which results in what RFC 5280
describes, i.e. all RDNs have to match in the same order (wildcards to
ignore the values of RDNs are always allowed).  With 'reordered', all
RDNs have to be there, but their order doesn't matter.  Finally, with
'relaxed', the certificate's DN may additionally contain RNDs that are
not configured, which are then treated like wildcards.  For example,
with 'relaxed' you could configure

  CN=server

which would be the same as configuring

  C=*, ST=*, L=*, O=*, OU=*, CN=server

which matched both certificates with 'relaxed' and 'reordered' but only
one with 'strict'.

Using 'reordered' and 'relaxed' causes some overhead (memory and
runtime) so 'strict' continues to be the default.

Regards,
Tobias