Mailing-List: contact dev-help@santuario.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@santuario.apache.org
Received-SPF: pass (athena.apache.org: domain of sean.mullan@oracle.com
 designates 148.87.113.117 as permitted sender)
Message-ID: <4F82E1F2.4060906@oracle.com>
Date: Mon, 09 Apr 2012 09:19:46 -0400
From: Sean Mullan <sean.mullan@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
 rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: dev@santuario.apache.org
CC: Dmitriev Vadim <dmgloss@mail.ru>
Subject: Re: Extending XML signature algorithms list
References: <4F81F596.5030709@mail.ru>
In-Reply-To: <4F81F596.5030709@mail.ru>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6566047
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.

--Sean


>
> 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]
> http://cxf.547215.n5.nabble.com/WS-with-non-standard-algorithm-for-signature-computation-td5163324.html
>