[
https://issues.apache.org/jira/browse/WSS-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13071440#comment-13071440
]
Linton Miller commented on WSS-300:
-----------------------------------
Sorry. Should have included this in the original report.
I'm still working with Axis 1, so this test example may have syntax or config
options specific to that. I've attached client.wsdd with is the Axis config I'm
using for my invocation which encrypts a message using the public key in the
rsa2048.jks keystore (pointed to through test.crypto.properties).
Also attached are incorrect XML from the existing library (broken.xml), and
corrected XML generated using my patch (correct.xml). You'll see the difference
is in the <wsse:KeyIdentifier> which is "XFHevNgcrUZHs16vJbyDftWt+uY=" for the
existing library, when it should be "tgkZUMZ461ZSA1nZkBu6E5GDxLM=".
It also came to my attention today that Java 1.4 uses the string "X509" rather
than "X.509" as Java 5+ and Bouncy Castle use when identifying the format of
PublicKey encoding. That causes an exception in my X509SubjectPublicKeyInfo
class, which specifically tests only for "X.509". While that's perhaps not
directly an issue given Java 1.4 is no longer support on the 1.6 release, I
don't think it hurts to try and be accommodating in general, so I suggest the
addition of a one line modification to my X509SubjectPublicKeyInfo class:
@@ -27,7 +27,8 @@
*/
public X509SubjectPublicKeyInfo(PublicKey key) throws WSSecurityException {
super(key.getEncoded());
- if (!"X.509".equalsIgnoreCase(key.getFormat())) {
+ if (!("X.509".equalsIgnoreCase(key.getFormat()) ||
+ "X509".equalsIgnoreCase(key.getFormat()))) {
throw new
WSSecurityException(WSSecurityException.UNSUPPORTED_SECURITY_TOKEN,
"noSKIHandling",
new Object[] { "Support for X.509-encoded
public keys only" });
> SubjectKeyIidentifier (SKI) incorrectly calculated for 2048-bit RSA key
> -----------------------------------------------------------------------
>
> Key: WSS-300
> URL: https://issues.apache.org/jira/browse/WSS-300
> Project: WSS4J
> Issue Type: Bug
> Components: WSS4J Core
> Affects Versions: 1.5.11, 1.6.1
> Environment: Tomcat 5, Solaris 10, Java 1.4 and Tomcat 6, Win XP,
> Java 6
> Reporter: Linton Miller
> Assignee: Colm O hEigeartaigh
> Attachments: CryptoBase.java.patch, DERDecoder.java,
> X509SubjectPublicKeyInfo.java
>
>
> The crypto function to get the SubjectKeyIdentifier from an X509Certificate
> has incorrect hard-coded assumptions about the size of the encoded
> information, meaning the calculation of the SKI from a 2048-bit RSA key is
> incorrect.
> The method
> org.apache.ws.security.components.crypto.CryptoBase.getSKIBytesFromCert does
> not parse the DER encoding of information, but just tries to pick out the
> piece of the byte array that corresponds to the content of interest. However,
> that approach fails because the DER encoding is variable length, depending on
> the size of the data being encoded. e.g. a 1024-bit key in a DER BIT STRING
> takes 4 bytes header + 140 bytes data to encode, whereas a 2048-bit key
> takes 5 bytes header + 270 bytes data; the header is one byte longer for the
> larger key, so the data starts at a different point in the array.
> To fix this, the DER data structures should be properly processed, reading
> the DER header bytes to determine the length of each data element (that also
> allows the generalization of handling any X.509 encoded public key, rather
> than just RSA keys as currently coded).
> Attached is a suggested patch (against WSS4J 1.6.1) that implements this
> idea: it processes the SubjectPublicKeyInfo and SubjectKeyIdentifier
> DER-encoded byte arrays according to their ASN.1 definitions from RFC
> 3280/5280 to pick out the desired data bytes.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org
