DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUGĀ· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=42644>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED ANDĀ· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=42644 Summary: SignatureAlgorithm problem with initSign and initVerify methods (xmlsec-1.4.1) Product: Security Version: unspecified Platform: All OS/Version: Windows XP Status: NEW Severity: regression Priority: P2 Component: Signature AssignedTo: security-dev@xml.apache.org ReportedBy: [EMAIL PROTECTED] We're migrating a working web application from Java 1.4.2 to Java 1.5. Our 1.4.2 application used xmlsec-1.2.1 and worked fine. We've upgraded to xmlsec-1.4.1 in the process and we have encountered a problem that occurs when we try to sign/verify multiple documents with the same key pair: Consider a scenario when multiple XML documents need to be signed and verified with the same key pair. (The verification is just to confirm that signing worked). Therefore, for a given KeyPair instance, we do the following on each iteration: 1. XMLSignature sig = new XMLSignature(....); 2. Sign XML document with PrivateKey 3. Verify XML document with PublicKey (sanity check) The problem occurs on the second iteration. It appears that, because we are using the same PrivateKey to sign on each iteration, the code remains initialised for verification (a result of step 3 above), and is not re-initialised for signing as it is using a cached Private Key. We were unable to find an API call to resolve this. We made changes to SignatureAlgorithm::initSign(Key) and SignatureAlgorithm::initVerify(Key) so that cached keys were no longer used. We are therefore always calling the engineInitSign(Key) and engineInitVerify(Key) on the SignatureAlgorithm implementation. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.