[JIRA] Created: (JXT-81) InlineX509DataProvider should handle X.500 DN string parsing failures more gracefully

[Kaspar Brand (JIRA)]

InlineX509DataProvider should handle X.500 DN string parsing failures more gracefully
-------------------------------------------------------------------------------------

                 Key: JXT-81
                 URL: https://issues.shibboleth.net/jira/browse/JXT-81
             Project: XMLTooling - Java
          Issue Type: Improvement
          Components: Security
    Affects Versions: 1.3.2
            Reporter: Kaspar Brand
            Assignee: Chad La Joie
            Priority: Minor


findCertFromSubjectNames() in InlineX509DataProvider currently has this code:

        for (X509SubjectName subjectName : names) {
            if (! DatatypeHelper.isEmpty(subjectName.getValue())) {
                X500Principal subjectX500Principal = x500DNHandler.parse(subjectName.getValue());
                for (X509Certificate cert : certs) {
                    if (cert.getSubjectX500Principal().equals(subjectX500Principal)) {
                        return cert;
                    }
                }
            }
        }

[http://svn.shibboleth.net/view/java-xmltooling/branches/REL_1/src/main/java/org/opensaml/xml/security/keyinfo/provider/InlineX509DataProvider.java?revision=729&view=markup#l275]

x500DNHandler.parse() possibly throws an exception - e.g. when the DN string can't be parsed by the X500Principal constructor. One case where this can happen is when the DN includes an attribute name which is not supported by the default set of the X500Principal's constructor. To quote http://download.oracle.com/javase/6/docs/api/javax/security/auth/x500/X500Principal.html#X500Principal%28java.lang.String%29:

"This constructor recognizes the attribute type keywords defined in RFC 1779 and RFC 2253 (and listed in getName(String format)), as well as the T, DNQ or DNQUALIFIER, SURNAME, GIVENNAME, INITIALS, GENERATION, EMAILADDRESS, and SERIALNUMBER keywords whose OIDs are defined in RFC 2459 and its successor. Any other attribute type must be specified as an OID."

A subject DN from an EV SSL certificate e.g. will sometimes include "businessCategory=...", and such a DN can be present in the Signature element of an AttributeQuery, e.g.

Looking at findEntityCert() in InlineX509DataProvider (http://svn.shibboleth.net/view/java-xmltooling/branches/REL_1/src/main/java/org/opensaml/xml/security/keyinfo/provider/InlineX509DataProvider.java?revision=729&view=markup#l208), it seems to me that a failure in findCertFromSubjectNames() should be treated as non-fatal, so that the code simply continues with findCertFromIssuerSerials() and findCertFromSubjectKeyIdentifier().

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira