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.
- Defining a new SignatureMethod Frank Cornelis
-
