Hi,

the API I want to use is also available in Java 6 (see
http://docs.oracle.com/javase/6/docs/technotes/guides/security/xmldsig/overview.html).

I had a look at the project camel-xmlsecurity. The XML signature
feature will fit well into this project.

The XML en/decryption feature is implemented as DataFormat. I would
prefer to implement the XML signature feature as camel component with
two endpoints one for signing and one for verifying. The component
implementation has the following advantages in comparison to the
DataFormat implementation:
- The signer and verifier endpoint can have different parameters
whereas the marshal and unmarshal method of the data formater have the
same parameters.  For XML signature, the signer endpoint will have
more complex parameters than the verifier endpoint. For example, for
signing you can specify transformations like xslt(s) or xpath(s) which
must be executed before signing, whereas for verifying these
transformations are contained in the XML signature and must not be
specified during configuration time.
- The DataFormatClause contained in the core project will have
dependencies to the data format implementation. Whenever the data
format api is changed you have to adapt the DataFormatClause.

What's your opinion on that?

Regards Franz


> On Tue, Mar 12, 2013 at 12:317 PM, Claus Ibson
> <claus.ib...@gmail.com> wrote:
> Hi
>
> Welcome to the community.
>
> Mind that Apache Camel supports JDK6+ so we cannot have components
> currently that require JDK7+.
> In case that API you wanna use is only avail in JDK7 onwards.
>
> We have 2 crypto components
>
> http://camel.apache.org/crypto
> http://camel.apache.org/xmlsecurity-dataformat.html
>
> Isn't your component more alike the existing xmlsecurity component from Camel?
> Maybe that's the place where it fits the best?
>
> I suggest to take a second look
>
>
> On Tue, Mar 12, 2013 at 7:33 AM, Franz Paul Forsthofer
> <emc2...@googlemail.com> wrote:
>> Hello,
>>
>> I want to contribute a new component for XML Digital Signature. There
>> shall be two endpoints; the signer endpoint shall sign the body of the
>> in-message and create an XML digital signature in the out-message, the
>> verifier endpoint shall verify the XML signature contained in the body
>> of the in-message and return the signed content in the body of the
>> out-message.
>>
>> The implementation shall be based on the JRE API for XML Digital
>> Signature 
>> (http://docs.oracle.com/javase/7/docs/technotes/guides/security/xmldsig/overview.html)
>> which fulfills the requirements of the XML signature specification
>> (http://www.w3.org/TR/xmldsig-core/).
>>
>> The first version shall support
>>
>> ·   RSA and DSA keys
>> ·   enveloping signatures
>> ·   X509Certificate element as children of the KeyInfo element
>> ·   the canonicalization algorithms
>>             o   http://www.w3.org/TR/2001/REC-xml-c14n-20010315
>>             o   http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments
>>             o   http://www.w3.org/2001/10/xml-exc-c14n#"; (needs
>> inclusive namespace prefix list, we should not support this algorithm
>> in the first implementation)
>>             o   http://www.w3.org/2001/10/xml-exc-c14n#WithComments
>> ·   the transform algorithms
>>             o      <all cononicalization algorithms>
>>             o     http://www.w3.org/2000/09/xmldsig#base64
>>
>> I have a few questions about the contribution:
>> ·   Schall I add the new code to the maven project with
>> <groupId>org.apache.camel</groupId> and
>> <artifactId>camel-crypto</artifactId>?
>> ·   There is already a crypto component for signing and verifying
>> non-XML messages
>> (http://camel.apache.org/crypto-digital-signatures.html).
>>           o   Shall I add the new endpoints to this component, like
>>                   §  crypto:signxml://<name>?<parameters>
>>                   §  crypto:verfyxml://<name>?<parameters>
>>           o   or shall I create a new component “cryptoxml”?
>> ·   Shall I add the classes to the package org.apache.camel.component.crypto 
>> ?
>>
>> Regards Franz
>
>
>
> --
> Claus Ibsen
> -----------------
> Red Hat, Inc.
> FuseSource is now part of Red Hat
> Email: cib...@redhat.com
> Web: http://fusesource.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
>
>

Reply via email to