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=43239>. 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=43239 ------- Additional Comments From [EMAIL PROTECTED] 2007-09-06 07:14 ------- (In reply to comment #6) > (In reply to comment #5) > > This problem is due to an open bug in the JDK: see > > http://bugs.sun.com/view_bug.do?bug_id=4953555 > > for more information. > > Is the "javax.crypto.Cipher" class really used for verifying a Signature? No, but the bug applies to all JCE provider-based classes (Cipher, Signature, Mac, etc). > > Since there is a workaround (use the correct key), > > I would like to close this bug. > > I don't agree. The problem occurs even if a new XMLSignature object is created > for each validation attempt (as you can see from the attached sample). IMHO, > the > Apache XML Security library does never recover if the first validation attemt > for a RSA Signature is done against a DSA key. Afterwards, any validation > attemt > for a RSA Signature against a RSA or DSA Key will fail. Therefore, the JVM has > to be restarted for recovering. I see. I'll look into this a little bit more. A relatively recent enhancement was made to cache and reuse java.security.Signature objects per thread. I think the problem is that it is caching and reusing Signature objects that are incorrectly initialized. Now, I still believe that this bug will go away once the JDK bug is fixed, but maybe in the meantime I can fix the cache such that incorrectly initialized Signature objects are not cached (or are flushed from the cache). > Why does the problem not occur if the Log4j log level is set to debug? Because of this code in org.apache.xml.security.signature.XMLSignature: SignatureAlgorithm sa =si.getSignatureAlgorithm(); if (log.isDebugEnabled()) { log.debug("SignatureMethodURI = " + sa.getAlgorithmURI()); log.debug("jceSigAlgorithm = " + sa.getJCEAlgorithmString()); log.debug("jceSigProvider = " + sa.getJCEProviderName()); log.debug("PublicKey = " + pk); } getJCEProviderName() triggers the provider-loading code such that it doesn't depend on the key and doesn't cause the JDK bug to be triggered. See http://java.sun.com/javase/6/docs/technotes/guides/security/p11guide.html#DelayedSelect for more information about delayed provider selection. This logging code should probably be fixed, because if enabled, it will probably cause problems with unextractable token keys. Also, can you use the standard JSR 105 API instead? That API doesn't use the same underlying code and caching mechanism for Signature objects. -- 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.
