Hi Frank, Would you be interested in contributing a patch to make this more flexible? So long as it's compatible with the existing API that is...
Colm. On Fri, May 30, 2014 at 11:15 PM, Frank Cornelis <[email protected]> wrote: > 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. > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
