Return-Path: Delivered-To: apmail-xml-security-dev-archive@www.apache.org Received: (qmail 60223 invoked from network); 26 Jun 2006 15:06:12 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 26 Jun 2006 15:06:12 -0000 Received: (qmail 65647 invoked by uid 500); 26 Jun 2006 15:06:10 -0000 Delivered-To: apmail-xml-security-dev-archive@xml.apache.org Received: (qmail 65622 invoked by uid 500); 26 Jun 2006 15:06:10 -0000 Mailing-List: contact security-dev-help@xml.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: Reply-To: security-dev@xml.apache.org List-Id: Delivered-To: mailing list security-dev@xml.apache.org Received: (qmail 65611 invoked by uid 99); 26 Jun 2006 15:06:10 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 26 Jun 2006 08:06:10 -0700 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=DNS_FROM_RFC_ABUSE,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of raul.benito.garcia@gmail.com designates 64.233.184.233 as permitted sender) Received: from [64.233.184.233] (HELO wr-out-0506.google.com) (64.233.184.233) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 26 Jun 2006 08:06:07 -0700 Received: by wr-out-0506.google.com with SMTP id i31so20820wra for ; Mon, 26 Jun 2006 08:05:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=J5gdOkR6IXf/zeyvjIm/b62GHJNaJgfKnipAZtjDAalFt1dA8KPVdIi2qpISYnaT1P4Yl/X6ccSU+aHaNBqVdPCKJ4WZld3KRadQuvOK0wtAoZDxlJohoRZwam5w7RkWCr02HrxMG4w7x+0l8W7RqdJ6khOh5yJN14M/EJrgKSA= Received: by 10.65.251.1 with SMTP id d1mr6163200qbs; Mon, 26 Jun 2006 08:05:46 -0700 (PDT) Received: by 10.65.126.14 with HTTP; Mon, 26 Jun 2006 08:05:43 -0700 (PDT) Message-ID: <949ac9410606260805t59c7c876k761c460297797a7b@mail.gmail.com> Date: Mon, 26 Jun 2006 17:05:43 +0200 From: "Raul Benito" Sender: raul.benito.garcia@gmail.com To: security-dev@xml.apache.org Subject: Re: CanonicalizerSpi In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_51084_32484908.1151334343622" References: <449FEA9B.3020309@Sun.COM> X-Google-Sender-Auth: 47839c53b953f978 X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_51084_32484908.1151334343622 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 6/26/06, Michael McIntosh wrote: > > Sean.Mullan@Sun.COM wrote on 06/26/2006 10:09:31 AM: > > > Can you be more specific about what the problem is? > > The problem is that there is no equivalent to _transformObject in the > CanonicalizerSpi. An implementation of a Transform can include the > following code in order to access any parameter values encapsulated in th= e > Transform element: > > protected XMLSignatureInput enginePerformTransform > (XMLSignatureInput input) > { > org.w3c.dom.Element elemTransform =3D > this._transformObject.getElement(); > ... > } > > there is no way to access the current CanonicalizationMethod element from > within the implementation. Ohh, that=B4s so 1.3ies. In 1.4 the API has change a little not too much. T= he enginePerformTransform method accepts also a Tranform object argument. > Also, the next release of Apache XML Security (1.4) will include JSR 105 > > > (Java XML DSig API). The JSR 105 API allows you to implement your own > > Canonicalization (or Transform) algorithms (with support for input > > parameters) by subclassing the javax.xml.crypto.dsig.TransformService > > class. An initial beta of XMLSec 1.4 is now available for testing: > > http://xml.apache.org/security/dist/java-library/xmlsec-1.4.Beta0.jar > > How different is code written for 1.4 vs. 1.3? Are there easy to > understand porting guidelines available? The 1.4 is backward compatible from the client API point of view(if you implement new Transform or KeyResolver the api has change slightly, you can see the CVS Changelog). But it also includes a whole new API: the JSR105. This standard API that will be implemented by several vendors, while the old api was always proprietary of apache xmlsec API and a little leaky one by the way. So from now on we will maintain the two APIs. But I think the old one will be deprecated and go to the JSR105. Thanks, > Mike > > > --Sean > > --=20 http://r-bg.com ------=_Part_51084_32484908.1151334343622 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

On 6/26/06, Michael McIntosh <mike= mci@us.ibm.com> wrote:
Sean.Mullan@Sun.COM wrote on 06/= 26/2006 10:09:31 AM:

> Can you be more specific about what the pr= oblem is?

The problem is that there is no equivalent to _transformOb= ject in the
CanonicalizerSpi. An implementation of a Transform can include the
f= ollowing code in order to access any parameter values encapsulated in theTransform element:

protected XMLSignatureInput enginePerformTransf= orm
        (XMLSignatureInput inpu= t)
{
        org.w3c.dom.Elem= ent elemTransform =3D
this._transformObject.getElement();
  = ;      ...
}

there is no way to acc= ess the current CanonicalizationMethod element from
within the implementation.

Ohh, that=B4s so 1.3ies= . In 1.4 the API has change a little not too much. The enginePerformTransfo= rm method accepts also a Tranform object argument.


> Also, the next release of Apache XML Security (1.4) will include JSR 1= 05

> (Java XML DSig API). The JSR 105 API allows you to implement= your own
> Canonicalization (or Transform) algorithms (with support = for input
> parameters) by subclassing the javax.xml.crypto.dsig.TransformServ= ice
> class. An initial beta of XMLSec 1.4 is now available for testi= ng:
> http://xml.apache.org/security/dist/java-library/xmlsec-1.4.Beta0.jar
How different is code written for 1.4 vs. 1.3? Are there easy to
u= nderstand porting guidelines available?

The 1.4 is bac= kward compatible from the client API point of view(if you implement new Tra= nsform or KeyResolver the api has change slightly, you can see the CVS Chan= gelog).
But it also includes a whole new API: the JSR105. This standard API tha= t will be implemented by several vendors, while the old api was always prop= rietary of apache xmlsec API and a little leaky one by the way.
So from = now on we will maintain the two APIs. But I think the old one will be depre= cated and go to the JSR105.



Thanks,
Mike

> --Sean




--
http://r-bg.com ------=_Part_51084_32484908.1151334343622--