A bug was introduced in WSS4J 1.5.4 where #x509v1 was used for a v.1 cert, and #x509v3 for a v3 cert. This was fixed in WSS4J 1.5.6:
https://issues.apache.org/jira/browse/WSS-105 The history behind this is that v1 certs were added as a type in the X509 1.1 profile. However, the WSS X.509 v1.1 errata spec removes a x509v1 cert from the list of supported types: http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-errata-os-x509TokenProfile.pdf Therefore the current (post 1.5.6) implementation is correct in that the #X509v1 ValueType is not allowed, WSS4J will throw an exception on receiving a token with this ValueType. However, it does not enforce that the actual certificate is a v3 cert afaik, for backwards compatibility reasons. Colm. -----Original Message----- From: Andrea Poli [mailto:[email protected]] Sent: 16 April 2010 13:18 To: [email protected] Subject: Certificate X509v3 vs X509v1 Using an X509v1 or X509v3 certificate with the following WSSignature settings: <parameter name="action" value="Signature" /> <parameter name="signatureKeyIdentifier" value="DirectReference" /> <parameter name="signatureParts" value="{Content}{http://schemas.xmlsoap.org/soap/envelope/}Body;"; /> I noted different behaviors depending on the version of the Wss4j library, about the value of attribute "ValueType" generated inside BinarySecurityToken and SecurityTokenReference. -------- wss4j-1.5.3.jar --------- In both cases of cert X509v1 and cert X509v3, attribute ValueType will be set to: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3 --------- wss4j-1.5.4.jar ----------- In the case of cert X509v1, attribute ValueType will be set to: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v1 In the case of cert X509v3, attribute ValueType will be set to: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3 -------- wss4j-1.5.7 / wss4j-1.5.8.jar ----------- In both cases of cert X509v1 and cert X509v3, attribute ValueType will be set to: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3 "Web Services Security 3 X.509 Certificate Token Profile 1.1" specification document of 2006 shows at page 8 two different values for attribute ValueType. Conversely, the older specification "Web Services Security 3 X.509 Certificate Token Profile 1.0" at the same page 8, shows the only "X509v3" as possible value of ValueType, but the Errata Section gives a correction adding the value "X509v1" to the table. A strict adherence to the specification indicates the WSS4J v1.5.4 behavior as the right one. Could you tell me why the newer versions of wss4j than 1.5.4 reintroduce such unconformity of the specification documents? The compliant behavior can actually lead to some interoperability problem (due to wrong implementations of some vendor), like these: -http://blog.redstream.nl/2009/01/16/testing-soap-encrypting-and-decrypting-with-soapui/ -http://www.eviware.com/forums/index.php?topic=1086.0 If it's a bug relate to newer version than 1.5.4, could you give me a patch? In such event, wouldn't be the case to introduce a new property to enforce the value of ValueType to #X509v3, resolving interoperability problems with wrong implementations of some vendors? Andrea Poli --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
