[
https://issues.apache.org/jira/browse/WSS-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12576836#action_12576836
]
Robert Egglestone commented on WSS-86:
--------------------------------------
I think the name handling needs to be more generalised than even this, for
extensions such as email address, I've seen WebLogic sending it in encoded
form, for example:
1.2.840.113549.1.9.1=#16197072656d69756d2d736572766572407468617774652e636f6d,CN=Thawte
Premium Server CA,OU=Certification Services Division,O=Thawte Consulting
cc,L=Cape Town,ST=Western Cape,C=ZA
Java contains a class javax.security.auth.x500.X500Principal which seems to do
the right thing with regards to flexible name handling:
-----
This class represents an X.500 Principal. X500Principals are represented by
distinguished names such as "CN=Duke, OU=JavaSoft, O=Sun Microsystems, C=US".
This class can be instantiated by using a string representation of the
distinguished name, or by using the ASN.1 DER encoded byte representation of
the distinguished name. The current specification for the string representation
of a distinguished name is defined in RFC 2253. This class, however, accepts
string formats from both RFC 2253 and RFC 1779, and also recognizes attribute
type keywords whose OIDs (Object Identifiers) are defined in RFC 2459.
-----
I think the best approach would be to convert any of these names into
X500Principal, and use .equals instead of strings.
> CryptoBase.splitAndTrim does not take into account the format of a DN
> constructed by different providers
> --------------------------------------------------------------------------------------------------------
>
> Key: WSS-86
> URL: https://issues.apache.org/jira/browse/WSS-86
> Project: WSS4J
> Issue Type: Bug
> Reporter: Christof Soehngen
> Priority: Minor
> Attachments: crypto.properties, DNTestCase.java, myKeystore.jks
>
>
> On some systems, different security providers are used to create the x509
> certificate instances for the certificate in the soap message and for the
> certificates from the keystore.
> Example would be one system where SOAP certificate is loaded with SUN
> provider, keystore with BC provider (although I have now idea how this is
> possible, given the fact that BC is not able to load JKS ...). This was
> checked at runtime/debug.
> Merlin uses a splitAndTrim-Method to compare DNsin order to find certificates
> by issuer name.
> If two different security provider are used the same certificates, they may
> result in different DNs:
> org.bouncycastle.jce.provider.X509CertificateObject:
> C=...,ST=...,L=...,O=...,OU=...,CN=...,E=...
> sun.security.x509.X509CertImpl:
> EMAILADDRESS=..., CN=..., OU=..., O=..., L=..., ST=..., C=...
> Therefore, Merlin would treat theses certificates as different, even if the
> ... are equal.
> A fix for this behaviour would be a modification of the splitAndTrim Method,
> replacing problematic attribute names like EMAILADDRESS
> Something like:
> protected Vector splitAndTrim(String inString)
> {
> X509NameTokenizer nmTokens = new X509NameTokenizer(inString);
> Vector vr = new Vector();
> while (nmTokens.hasMoreTokens())
> {
> String tokenString = nmTokens.nextToken();
>
> // Try to split name/value pairs
> int positionOfEquals = tokenString.indexOf("=");
> if (positionOfEquals >= 0)
> {
> String name = tokenString.substring(0, positionOfEquals);
> String value = tokenString.substring(positionOfEquals + 1);
>
> // Not mandatory, but may be possible problems, too
> name = name.trim();
> name = name.toUpperCase();
>
> // Fix certain deviations from standard names
> if (name.equals("EMAILADDRESS"))
> {
> name = "E";
> }
>
> StringBuffer stringBuffer = new StringBuffer();
> stringBuffer.append(name);
> stringBuffer.append("=");
> stringBuffer.append(value);
>
> tokenString = stringBuffer.toString();
> }
> else
> {
> // Ignore the token, if not parseable
> }
>
> vr.add(tokenString);
> }
>
> java.util.Collections.sort(vr);
>
> return vr;
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
