Recently I had an interesting issue come up. I needed to generate a
certificate with a specific OU= content that our openssl/python
code couldn't do, and I switched to nss's cert-util to generate
a cert of sets for a test.
Then I noticed something strange. Let's say you have the following
DN specified for certificate generation:
C=CZ, ST=Moravia, L=Brno, O=Test Example, OU="Global, Support,
Services", CN=server
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.
When reading https://tools.ietf.org/html/rfc5280#section-7.1 we see:
Two distinguished names DN1 and DN2 match if they
have the same number of RDNs, for each RDN in DN1 there is a matching
RDN in DN2, and the matching RDNs appear in the same order in both
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?
Now, I guess I can weasel myself out of here, by claiming that we are
not comparing two certificates. We just get one via CERT payload and
validate it, and _then_ compare its DN against our IKE ID (which is a
DN, sorta kinda). So perhaps I can say the IKE ID can take RDN's in
any order. As we are dealing with (private) CA's, we can probably be
ensured it would not create two certs that only differ in RDN ordering.
Interested in hearing what others think,
Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
