Created attachment 20038 [details]
Patch to the ECDSA signature algoithm implementation.

Created attachment 20039 [details]
A sample signature from the suatrin citizen card.

For me is ok to add this to 1.4.1 release, what other people think?

Applying this patch for 1.4.1 would be a great favor to me.

TIA, Wolfgang

Can you recreate the patch with svn diff, or eclipse patch. It is the only thing
left for the release.

Regards,

Raul

My original patch appiels well againt the current svn tree using 'patch -p0 xx' 
from the project's root diretory (the directory where build.xml resides...)

However, I will attach the output of 'svn diff' of the current svn with my 
patch applied

Created attachment 20087 [details]
output of svn diff for my proposed patch.

Thanks last patch works. One last think can you send a junit test case that
stress the new code. If you don't do this I don't know how long it will keep
working.

Regards,

Raul

The problem with generating a junit test is, that the signature attached to 
this issuse uses complex xpointer references with namespaces.

URI="#xmlns(etsi=http://uri.etsi.org/01903/v1.1.1%23)%20xpointer(<some_xpath_expression>)"

I've implemented an xpointer resolver, which is capable of resolving such 
things, but this resolver relies on java 1.5's XPath API plus schema 
validation, which makes the thing not suitable for a junit test (schema lookup 
through http, test woll only run in java-1.5...).

The only thing I can do is to generate a signature with xmlsec in a way, that 
it maybe resolved by the austrian security layer implementation. I've already 
contacted the guys a IAIK.at for receiving an official testvector, but the 
staff hasn't been very cooperative at this point.

Created attachment 20117 [details]
patch for making ECDSA aware of varaible keylengths.

This patch make the new ECDSA signaturevalue conversion aware of multiple
keylength as discovered by the junit test, which will follow.

Created attachment 20118 [details]
JUnit tests for ECDSA.

These junit tests test the interopaerability of the ECDSA signature with a
testvector from the austrian security card from www.buergerkarte.at as well as
the consistency of the ECDSA implementation.

Please note, that the third test fails with bouncycastle 129. I had to upgrade
to the current bouncycastle (136) in order to get the interoperability test
working.

I just recognized, that the variable keylength patch as well as the junit tets
has not yet been checkinto the svn tree of the xml security project.

Raul, would it be possible to do so ?

TIA, Wolfgang

I've tried the xpointer resolver for generating signatures for the german
banking interface EBICS which uses #xpointer(//*[@authenticate='true']) to sign
all elements with this attribute. Unfortunately, signing fails because
CanonicalizerBase.canonicalizeXPathNodeSet strips away subnodes because
isVisibleDO returns 0 for subnodes of nodes in the xpathnodeset.

Well, how is the XPointer resolver related to this issue ?
Supposedly you should post XPointer issues to

http://issues.apache.org/bugzilla/show_bug.cgi?id=42599

Regards,

  Wolfgang

I gzuess you are right that it fits better into issue 42599. 
The reason I posted it here was that this is where you published the resolver
that triggered this bug. I will add a comment to 42599.

Thanks
Christian

Wolfgang,

I'm working on integrating this patch. I have an issue with the test. I'd rather
it didn't depend on the BouncyCastle APIs to generate a certificate and EC
keypair. This seems easy to workaround, instead you can read them from a
keystore file which will contain the private key and X.509 certificate. Is this
something you can change for me?

Thanks,
Sean

Created attachment 23914 [details]
A patch (zip file) for this issue


See the attached patch which we can apply to close this issue. It's a reworked version of the previous attachment "20118 - JUnit tests for ECDSA". Instead of explicitly using BouncyCastle API's to create an ECDSA keypair each time the test is run, I used the code to write the keypair out to a keystore, and then commented the BouncyCastle code out.

The test tries to load the BouncyCastle provider via reflection, if it fails then the tests just return without an error, as to run the tests we need to have BouncyCastle installed to provide ECDSA support.

The patch is a zip file consisting of the actual patch, and the keystore which should be placed in data\org\apache\xml\security\samples\input.

Note that this patch also needs attachment number "20117 - patch for making ECDSA aware of varaible keylengths" that is attached to this issue but was never applied.

Sean, can you take a look at the license at the top of the ResourceResolver implementation in the patch to make sure it's ok?

Colm.

(In reply to comment #17)

> Sean, can you take a look at the license at the top of the ResourceResolver
> implementation in the patch to make sure it's ok?

Are you referring to this? :

+/***********************************************************
+ * $Id: XPointerResourceResolver.java 52 2007-04-07 19:45:06Z wglas $
+ *
+ * Tapestry support for the austrian security card layer.
+ *
+ * Copyright (C) 2007 ev-i Informationstechnologie GmbH
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ *     http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ *
+ * Created: Apr 6, 2007
+ *
+ * Author: wglas
+ *
+ ***********************************************************/

I don't think this is acceptable. See http://www.apache.org/legal/src-headers.html#headers for more information. It specifically states:

"Each source file should include the following license header -- note that there should be no copyright notice in the header"

First the standard disclaimer : IANAL.
I think the easiest thing to do is ask Wolfgang whether he really needs to include their own copyright (implying ownership) of this code. If they do, then I think we need to have a CLA in place.

In any case, I think this copyright issue will delay getting this fix into 1.4.3.

Hi all,

  The header of the mentioned file was incidentially generated from another project. (tapestry integration of austrian secutiy card layer.)

  The code is under the apache license 2.0 and I'm happy if the code will be integrated into xmlsec-1.4.3 ;-)

  Feel free to drop the copyright and adapt the header to the requirements of http://www.apache.org/legal/src-headers.html#headers

  Thanks for working with my code,

    Wolfgang

(In reply to comment #19)
> Hi all,
> 
>   The header of the mentioned file was incidentially generated from another
> project. (tapestry integration of austrian secutiy card layer.)
> 
>   The code is under the apache license 2.0 and I'm happy if the code will be
> integrated into xmlsec-1.4.3 ;-)
> 
>   Feel free to drop the copyright and adapt the header to the requirements of
> http://www.apache.org/legal/src-headers.html#headers
> 
>   Thanks for working with my code,
> 
>     Wolfgang

Thanks for the quick reply Wolfgang. I read this to mean that you aren't claiming ownership of the code (no copyright), is that right? If so, Colm, I think this means we can keep the 2.0 notice, and just replace the copyright with the ASF copyright and not the notice in http://www.apache.org/legal/src-headers.html#headers.

Note: it may be the case the the existing copyright is ok and doesn't require a CLA because it is specified within an Apache 2.0 license. However, I'm not really sure and would want to check with legal first. So if we can just remove the non-Apache copyright and replace it with an Apache copyright that seems like the quickest solution.

Thanks,
Sean

Patch applied.

Colm.