Okay. In the Apache XMLSec code, this happens more or less automatically (That is, you verify the signature with checkSignatureValue, which takes a key as an argument, and may or may not also check references depending on what other settings you've specified).
I'm not really all that familiar with the JDK 1.6 API. In looking at it I see it changed quite considerably more than I expected, which probably explains most of my confusion. I assumed that the bug was against the apache implementation (this is the apache bug database, right?), not JDK code. So out of curiosity, how does one verify the Signature/KeyInfo match up in the JDK 1.6 code? Thanks, Jason On 11/8/06, Scott Cantor <[EMAIL PROTECTED]> wrote:
> Yes, of course. My question is, if the KeyInfo in a valid signature > can be changed without failing the signature check, then what good > does it do me to check the chain of trust on the KeyInfo? By itself, nothing. You still also have to verify that the KeyInfo actually validates the Signature. There's no attack here, you can't just substitute an arbitrary key and actually make it validate the signature too. Not unless there's a broken encryption algorithm anyway. > I presume this behavior is implemented as specced by the W3C. The spec says nothing about it, unless you mean the part about whether KeyInfo is digested. That part is in the spec, yes. -- Scott
-- - Jason
