santuario-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frank Cornelis <i...@e-contract.be>
Subject Defining a new SignatureMethod
Date Fri, 30 May 2014 22:15:04 GMT
Hi,


For one of my projects requiring an audit trail, I've extended the 
XMLSignatureFactory with a new SignatureMethod, capable of doing 
"urn:ietf:rfc:3161" signatures, thus actually XML signatures where the 
signature is a timestamp.

At the JCA level I was perfectly capable of defining a "Timestamp" 
KeyStore, corresponding PrivateKey, and a Signature supporting 
"SHA1withRFC3161".

Unfortunately at the XML Signature level, the flexibility of the JCA is 
not fully utilized. Besides TransformService and KeyInfoFactory, you 
basically have to redefine the entire XMLSignatureFactory just to 
introduce a new SignatureMethod. For the XML timestamp signature 
creation this was rather painful, but technically possible. As 
DOMSignatureMethod is package protected, I had to do a 
TimestampSignatureMethod within a org.apache.jcp.xml.dsig.internal.dom 
split package construct. After some fighting with the JBoss EAP 6 module 
classloading, I got things working as expected.

Unfortunately for the XML timestamp signature verification, the 
DOMXMLSignatureFactory unmarshalling is not walking over 
newSignatureMethod but is completely hardcoded towards 
DOMSignatureMethod.unmarshal. This method is doing a large if-else and 
finally throws an exception because of the alien algorithm.

It's rather sad to see that, while JCA gives opportunities to add 
sufficient flexibility to be able to extend the Java security layer, 
that this is not used at its full potential.

Are there any plans to work in this area, or did I overlook a magic 
feature somewhere?


Kind Regards,
Frank.

Mime
View raw message