On 06/03/2014 05:21 AM, Colm O hEigeartaigh wrote:
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...
Yes, a patch would be useful. Regarding API changes to JSR 105
(javax.xml.crypto and subpackages), you may have noticed that there have
never been any updates to 105 since the original JSR was finalized. This
is partially due to the fact that it is very expensive to produce a
maintenance release of JSR 105 which is a standalone JSR. Thus, going
forward, we have discontinued JSR 105 as a standalone JSR and will only
be evolving the API in Java SE. See the announcement on the JSR 105 page
for more information (scroll down to "2014.01.14"):
https://jcp.org/en/jsr/detail?id=105
What this means essentially is that API changes to JSR 105 (such as
adapting SignatureMethod to allow pluggable implementations), will only
be made in Java SE 9 and up. However, this does mean that we can now
more easily add several long-standing RFEs to the API.
Thanks,
Sean
Colm.
On Fri, May 30, 2014 at 11:15 PM, Frank Cornelis <[email protected]
<mailto:[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
