You are viewing a plain text version of this content. The canonical link for it is here.
Posted to wss4j-dev@ws.apache.org by "Marcel Ammerlaan (JIRA)" <ji...@apache.org> on 2007/11/27 18:03:43 UTC
[jira] Commented: (WSS-86) CryptoBase.splitAndTrim does not take
into account the format of a DN constructed by different providers
[ https://issues.apache.org/jira/browse/WSS-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545915 ]
Marcel Ammerlaan commented on WSS-86:
-------------------------------------
This issue is real when communicating with .Net: the keystore in .Net maps the State attribute to an S= attribute, whereas Java maps it to ST=.'
I'm not sure at this moment how to handle it (WS-I refers to the LDAP 2309 spec which states ST= is correct) and arbitrarily adding mappings seems to be a bad idea. Is there a more definitve fix suggested?
> 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: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org