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 "Colm O hEigeartaigh (JIRA)" <ji...@apache.org> on 2008/12/22 17:22:44 UTC
[jira] Resolved: (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:all-tabpanel ]
Colm O hEigeartaigh resolved WSS-86.
------------------------------------
Resolution: Fixed
> 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
> Affects Versions: 1.5.4
> Reporter: Christof Soehngen
> Assignee: Colm O hEigeartaigh
> Priority: Minor
> Fix For: 1.5.5
>
> Attachments: crypto.properties, DNTestCase.java, myKeystore.jks, name_tests.patch, remove_extra_escaping.patch, use_x500princ_for_names.patch
>
>
> 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