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
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.