santuario-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Mullan <>
Subject Re: Extending XML signature algorithms list
Date Mon, 09 Apr 2012 13:19:46 GMT
On 04/08/2012 04:31 PM, Dmitriev Vadim wrote:
> Hi!
> I'm implementing web-service with non standard algorithm for message
> signature (GOST3410) [1]. My current problem is that DOMSignatureMethod
> contains hardcoded list of allowed algorithms and doesn't provide any
> way to externally extend it. Hardcoding is perfectly valid if algorithm
> has conventional URI, but in an ad-hoc case URIs even for the same algo
> can differ.
> I was looking for a way to add extensibility to the DOMSignatureMethod
> so new algorithms can be registered at runtime, but most of it and it's
> hierarchy is package-private, so user implementations are hardly an
> option (not taking into account that this class resides in an "internal"
> package).
> Maybe custom algorithms support is already there, but I totally missed
> it? Or maybe there is already enhancement request for this feature?

Yes: see
However, this would require API changes to JSR 105 (javax.xml.crypto) 
and a maintenance release of the JSR, which isn't planned right now.

We could potentially implement a non-standard (Santuario-specific) 
solution. At this time I don't expect to have the resources to do that, 
but would be willing to review any contributions to extend the internal 
API to do that.

> If it is not likely that the team will tackle with this issue in the
> near future, maybe someone can give me insight on how to approach
> extensibility in this part of the code?

Take a look at the javax.xml.crypto.dsig.TransformService API and the 
code to load TransformService implementations. You would want to 
implement a similar API/mechanism, say SignatureMethodService.


> Thanks.
> P.S. Colm O hEigeartaigh already provided invaluable help for me before,
> but it seems that WS-S technological stack just resists addition of new
> algorithms :)
> [1]

View raw message