Bug 42239 - ECDSA signature value interoperability patch.
ECDSA signature value interoperability patch.
Status: RESOLVED FIXED
Product: Security - Now in JIRA
Classification: Unclassified
Component: Signature
Java 1.4.1
Other Windows XP
: P2 normal
: ---
Assigned To: XML Security Developers Mailing List
: RFC
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2007-04-25 06:27 UTC by Wolfgang Glas
Modified: 2009-07-14 04:38 UTC (History)
2 users (show)



Attachments
Patch to the ECDSA signature algoithm implementation. (4.85 KB, patch)
2007-04-25 06:28 UTC, Wolfgang Glas
Details | Diff
A sample signature from the suatrin citizen card. (6.03 KB, text/plain)
2007-04-25 06:31 UTC, Wolfgang Glas
Details
output of svn diff for my proposed patch. (4.95 KB, patch)
2007-05-02 04:05 UTC, Wolfgang Glas
Details | Diff
patch for making ECDSA aware of varaible keylengths. (2.82 KB, patch)
2007-05-03 05:34 UTC, Wolfgang Glas
Details | Diff
JUnit tests for ECDSA. (8.79 KB, application/x-tgz)
2007-05-03 05:37 UTC, Wolfgang Glas
Details
A patch (zip file) for this issue (10.46 KB, patch)
2009-06-30 08:17 UTC, coheigea
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Wolfgang Glas 2007-04-25 06:27:37 UTC
I've recently tried to verify a signature from the austrian citizen
security card (www.buergerkarte.at), which uses ECDSA-singatures.

  Unfortunately, the code in SignatureECDSA.java passes the
SignatureValue directly to the JCE-provider. However, the ECDSA
xml-security spec at ftp://ftp.rfc-editor.org/in-notes/rfc4050.txt
states, that the ECDSA SignatureValue is a concatenation of the raw
BigIntegers. This is in line with the semantics of SignatureValue for
conventional DSA signatures (SignatureDSA.java), where the
SignatureValue is converted to the ASN1 representation used by the JCE
provider.

  The attached patch adopts the procedure of converting the
SignatureValue to ASN.1 for the ECDSA algorithm. With this patch
applied to xmlsec-1.4.0 I can verify the signatures of my austrian card.
(An example is attached)

  Regards,

    Wolfgang
Comment 1 Wolfgang Glas 2007-04-25 06:28:40 UTC
Created attachment 20038 [details]
Patch to the ECDSA signature algoithm implementation.
Comment 2 Wolfgang Glas 2007-04-25 06:31:40 UTC
Created attachment 20039 [details]
A sample signature from the suatrin citizen card.
Comment 3 Raul Benito 2007-04-25 06:56:19 UTC
For me is ok to add this to 1.4.1 release, what other people think?
Comment 4 Wolfgang Glas 2007-04-25 12:54:18 UTC
Applying this patch for 1.4.1 would be a great favor to me.

TIA, Wolfgang
Comment 5 Raul Benito 2007-05-02 03:10:22 UTC
Can you recreate the patch with svn diff, or eclipse patch. It is the only thing
left for the release.

Regards,

Raul
Comment 6 Wolfgang Glas 2007-05-02 04:03:43 UTC
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
Comment 7 Wolfgang Glas 2007-05-02 04:05:10 UTC
Created attachment 20087 [details]
output of svn diff for my proposed patch.
Comment 8 Raul Benito 2007-05-02 05:16:50 UTC
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
Comment 9 Wolfgang Glas 2007-05-02 11:36:50 UTC
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.
Comment 10 Wolfgang Glas 2007-05-03 05:34:44 UTC
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.
Comment 11 Wolfgang Glas 2007-05-03 05:37:24 UTC
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.
Comment 12 Wolfgang Glas 2007-06-06 14:03:48 UTC
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
Comment 13 Christian Kleinewaechter 2007-08-22 00:52:45 UTC
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.
Comment 14 Wolfgang Glas 2007-08-22 01:59:32 UTC
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
Comment 15 Christian Kleinewaechter 2007-08-22 02:19:42 UTC
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
Comment 16 sean.mullan 2007-12-20 13:34:18 UTC
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
Comment 17 coheigea 2009-06-30 08:17:27 UTC
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.
Comment 18 sean.mullan 2009-07-10 07:41:46 UTC
(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.
Comment 19 Wolfgang Glas 2009-07-10 07:50:09 UTC
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
Comment 20 sean.mullan 2009-07-10 11:00:42 UTC
(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
Comment 21 coheigea 2009-07-14 04:38:48 UTC
Patch applied.

Colm.