Thanks for your responses.
- When you say OpenSSL 0.9.9, do you mean sources available from the cvs - http://cvs.openssl.org/dir?d=openssl? I will certainly try this. > Such CAs do violate RFC5280 anyway see section 8: > > CAs MUST encode the distinguished name in the subject field of a CA > certificate identically to the distinguished name in the issuer field > in certificates issued by that CA. If CAs use different encodings, > implementations might fail to recognize name chains for paths that > include this certificate. As a consequence, valid paths could be > rejected. - I don't think problem is due to this issue in my case (issuer field in issued certificate has different encoding than subject field in CA certificate). The problem was that binary search failed since the sorted list is incorrect. OpenSSL code is unable to sort correctly if there are CA certificates with different encoding in the same list. In fact the particular issued certificate that failed for me was in PRINTABLE encoding and the CA was also in PRINTABLE encoding but still it couldn't find the CA certificate in the cert store. I dumped the stack of x509 certs and the CA cert did exist. If I remove the CA certs with non-printable encoding then it starts to work. -Dm > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Dr. Stephen Henson > Sent: Thursday, August 14, 2008 2:53 AM > To: [email protected] > Subject: Re: x509_name_cmp for different encodings > > On Wed, Aug 13, 2008, Mohan, Dharmendra wrote: > > > Hi, > > > > > > > > I had a list of CA certificates, a few with different encoding than > > PRINTABLE encoding like T61 and UTF8. I am running into the problem of > > not able to verify some of the certificates issued by CA certificates in > > cert store despite the fact that they do exist in the store. > > > > > > > > Deep analysis of the code revealed that the problem is with sorting and > > searching. The sorted list is not correct and hence the binary search > > fails. The root cause of the problem turned out to be the function - > > X509_NAME_cmp. It appears that it doesn't implement the comparisons as > > specified in RFC5280 which refers to RFC4518 for rules to do comparison > > for Internationalized Names in Distinguished Names. To quote from > > RFC4518 - > > > > The lack of precise specification for character string > > matching has > > led to significant interoperability problems. When used in > > certificate chain validation, security vulnerabilities can > > arise. To > > address these problems, this document defines precise > > algorithms for > > preparing character strings for matching. > > > > Is there a plan to implement RFC4518 for comparison rules? Or are they > > being implemented currently? > > > > Is their a workaround to support a list of CA certificates with mixed > > encoding in the meantime? > > > > OpenSSL does not currently support the RFC5280 comparison algorithm. > > Such CAs do violate RFC5280 anyway see section 8: > > CAs MUST encode the distinguished name in the subject field of a CA > certificate identically to the distinguished name in the issuer field > in certificates issued by that CA. If CAs use different encodings, > implementations might fail to recognize name chains for paths that > include this certificate. As a consequence, valid paths could be > rejected. > > OpenSSL 0.9.9 has a more efficient name comparison algorithm which should > be a > proper metric. I'd suggest you try that and see if it works for you. > > It could be backported to 0.9.8. > > Steve. > -- > Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage > OpenSSL project core developer and freelance consultant. > Homepage: http://www.drh-consultancy.demon.co.uk > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List [email protected] > Automated List Manager [EMAIL PROTECTED] ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [EMAIL PROTECTED]
