[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DN Encoding by UTF8String


Since this partly relates to OpenSSLs ASN1 handling I feel compelled to reply :-)

Richard Levitte - VMS Whacker wrote:

In message <200312151122.hBFBM9P15024@xxxxxxxxxxxxxxxxx> on Tue, 16 Dec 2003 00:22:09 +1300, pgut001@xxxxxxxxxxxxxxxxx (Peter Gutmann) said:

pgut001> Hmm, I don't know if it's a good idea to encourage this sort
pgut001> of behaviour (that is, apps that generate certs that require
pgut001> custom code in order to work).  Some years ago (after I
pgut001> snapped out of my X.520 delusion and switched to memcmp()) a
pgut001> vendor complained that cryptlib was failing to find a cert
pgut001> with a canonicalised name.  I told them to try the same thing
pgut001> with Netscape and MSIE, and fairly soon afterwards (within a
pgut001> matter of days, I think) they had a service release out that
pgut001> didn't try and modify names any more.

I just figured out a specific example where you might need to use
X.520 comparison rules (or at least the rules outlined by RFC3280).
At least with OpenSSL, it's possible to restrict what certificates
'openssl ca' can issue by configuring some parts of the requested
subject in the CSR match the same parts of the subject in the signing
CA certificate.  So to take Tim's example with 'C=MX' vs. 'C=mx', a CA
that is only allowed to issue certificates with C=MX, and does the
same kind of enforcement OpenSSL can do, it would have to be able to
match the country code regardless of case (and provided an encoding
where the case-insensitive matching rule applies).  I don't really see
a way out of the possibility of this happening.


Whilst that is true, OpenSSL's normal handling of DNs in the X509_NAME structure will preserve the original encoding. SSLeay did this also.

This effectively means that when a DN is copied when a certificate is issued the encoding is preserved between the CAs subject name and the issued certificates issuer name.

I've only ever come across two obscure certificates (other than in test suites) where two matching DNs did not have the same encoding.

IIRC one was a PrintableString case variation which would fit the RFC3280 comparison rules. The other changed the string type from PrintableString to T61 which would require the X520 comparison. Both were horribly broken in that they were supposed to be valid CA certificate but they didn't include a basicConstraints extension.

I'd be interested to know how common these (i.e. matching DNs with different encodings) are and how many people have come across them.

Steve.
--
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: shenson@xxxxxxxxxxxxxxxxxxxxx, PGP key: via homepage.