You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@santuario.apache.org by jason marshall <jd...@gmail.com> on 2006/11/08 16:45:11 UTC
Re: DO NOT REPLY [Bug 40921] - XML contents modified and signature normallly validated.
Maybe I'm misunderstanding the commentary made so far in this bug report.
If KeyInfo is indeed advisory, then how does one establish the
trustworthiness of an enveloped signature?
Thanks,
Jason
On 11/7/06, bugzilla@apache.org <bu...@apache.org> wrote:
> ------- Additional Comments From cantor.2@osu.edu 2006-11-07 21:18 -------
> An enveloped signature omits anything inside the Signature element apart from
> SignedInfo. KeyInfo is not commonly signed. The only attack possible is against
> broken software that doesn't understand that KeyInfo is advisory, not trusted
> information.
>
>
> --
> 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.
>
--
- Jason
Re: DO NOT REPLY [Bug 40921] - XML contents modified
and signature normallly validated.
Posted by Sean Mullan <Se...@Sun.COM>.
jason marshall wrote:
> 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.
Well I don't think it is a bug in either implementation, but it would
probably help to explain the difference in the Apache and JDK 6 (1.6)
XML Signature APIs/implementation.
The API included in JDK 6 is based on JSR 105 which was a standard XML
Signature API defined via the Java Community Process. The reference
implementation of JSR 105 that is included in JDK 6 is based on the
Apache Java XML Security implementation.
The JSR 105 API and code was contributed back to the Apache Software
Foundation. It will be included in the next Apache XML Security release
(1.4) which should be available soon. You can download the source and
build it yourself now if you choose.
Don't worry though - we plan to continue to include both the JSR 105 API
and the current Apache XML Security API though I would encourage you to
transition over time to the standard JSR 105 API.
--Sean
Re: DO NOT REPLY [Bug 40921] - XML contents modified
and signature normallly validated.
Posted by Berin Lautenbach <be...@wingsofhermes.org>.
Scott Cantor wrote:
>>So out of curiosity, how does one verify the Signature/KeyInfo match
>>up in the JDK 1.6 code?
>
>
> I don't think that's how I would approach the question. In all cases, I
> think the application needs to supply the verification key. The application
> MAY choose to examine KeyInfo as part of determining what key to try, but
> that's up to it.
>
> In that light, KeyInfo is simply one of many inputs into the process of
> determining the key. The critical difference is that in my mind, you start
> by identifying the signer, usually based on the message itself, not based on
> KeyInfo. From there, you get keying material, or policy to control
> certificates that might be in KeyInfo.
+1.
I cannot think of any case where I would "trust" a message purely
because *the message* told me it was OK. That's effectively what you do
if you base a "trust" decision on a key info element.
The KeyInfo is like the keyid for a PGP/GPG signed message. It's a
pointer into your own keyring (or key management approach - whatever)
that lets *you* make a decision based on something outside the message
as to whether the message is signed by someone you know.
And FWIW - the match between key info and signature is trivial. If the
key that you determine from the keyinfo validates the signature then it
matches. Otherwise it doesn't. Incorporating the keyinfo into the
signed information tells you precisely nothing - if someone has inserted
their own key into KeyInfo, then they can obviously re-sign the message
and send it to you in its new form. So putting the KeyInfo inside the
signature tells you nothing about the validity of the key.
Given that fact - it would actually be dangerous for the spec to do it
by default as it would give a false sense of security to end users.
"The key info is included in the signature and the signature verified,
therefore the key is correct". Badness.
Cheers,
Berin
RE: DO NOT REPLY [Bug 40921] - XML contents modified and signature normallly validated.
Posted by Scott Cantor <ca...@osu.edu>.
> 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.
I've never looked at it. I mainly do C++ anyway, the Java's somebody else
now, mercifully for all the people who hated my Java code.
> So out of curiosity, how does one verify the Signature/KeyInfo match
> up in the JDK 1.6 code?
I don't think that's how I would approach the question. In all cases, I
think the application needs to supply the verification key. The application
MAY choose to examine KeyInfo as part of determining what key to try, but
that's up to it.
In that light, KeyInfo is simply one of many inputs into the process of
determining the key. The critical difference is that in my mind, you start
by identifying the signer, usually based on the message itself, not based on
KeyInfo. From there, you get keying material, or policy to control
certificates that might be in KeyInfo.
Just my two cents.
-- Scott
Re: DO NOT REPLY [Bug 40921] - XML contents modified and signature normallly validated.
Posted by jason marshall <jd...@gmail.com>.
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 <ca...@osu.edu> 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
RE: DO NOT REPLY [Bug 40921] - XML contents modified and signature normallly validated.
Posted by Scott Cantor <ca...@osu.edu>.
> 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
Re: DO NOT REPLY [Bug 40921] - XML contents modified and signature normallly validated.
Posted by jason marshall <jd...@gmail.com>.
On 11/8/06, Sean Mullan <Se...@sun.com> wrote:
> jason marshall wrote:
> > Maybe I'm misunderstanding the commentary made so far in this bug report.
> >
> > If KeyInfo is indeed advisory, then how does one establish the
> > trustworthiness of an enveloped signature?
>
> The relying (validating) party still needs to determine the
> trustworthiness of the KeyInfo material, or the key that it used to
> validate the signature (does the signing key actually belong to someone
> I trust?). For example if KeyInfo contains an X509Certificate then you
> shouldn't blindly trust the certificate, you need to determine if you
> trust the CA that issued that certificate - for example by building a
> chain of certificates from a trust anchor and validating the certificate
> chain (checking if certs have not been revoked, etc). XML Signature does
> not define how this is done, it is up to the application. However, there
> are CertPath APIs in the JDK which already help you do this: see
> http://java.sun.com/j2se/1.5.0/docs/guide/security/certpath/CertPathProgGuide.html
> for more information.
>
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?
I presume this behavior is implemented as specced by the W3C. I'm
just wondering what the solution was to this problem if the above
isn't actually sufficient.
-Jason
> --Sean
>
> >
> > Thanks,
> > Jason
> >
> > On 11/7/06, bugzilla@apache.org <bu...@apache.org> wrote:
> >> ------- Additional Comments From cantor.2@osu.edu 2006-11-07 21:18
> >> -------
> >> An enveloped signature omits anything inside the Signature element
> >> apart from
> >> SignedInfo. KeyInfo is not commonly signed. The only attack possible
> >> is against
> >> broken software that doesn't understand that KeyInfo is advisory, not
> >> trusted
> >> information.
> >>
> >>
> >> --
> >> 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.
> >>
> >
> >
>
>
--
- Jason
Re: DO NOT REPLY [Bug 40921] - XML contents modified
and signature normallly validated.
Posted by Sean Mullan <Se...@Sun.COM>.
jason marshall wrote:
> Maybe I'm misunderstanding the commentary made so far in this bug report.
>
> If KeyInfo is indeed advisory, then how does one establish the
> trustworthiness of an enveloped signature?
The relying (validating) party still needs to determine the
trustworthiness of the KeyInfo material, or the key that it used to
validate the signature (does the signing key actually belong to someone
I trust?). For example if KeyInfo contains an X509Certificate then you
shouldn't blindly trust the certificate, you need to determine if you
trust the CA that issued that certificate - for example by building a
chain of certificates from a trust anchor and validating the certificate
chain (checking if certs have not been revoked, etc). XML Signature does
not define how this is done, it is up to the application. However, there
are CertPath APIs in the JDK which already help you do this: see
http://java.sun.com/j2se/1.5.0/docs/guide/security/certpath/CertPathProgGuide.html
for more information.
--Sean
>
> Thanks,
> Jason
>
> On 11/7/06, bugzilla@apache.org <bu...@apache.org> wrote:
>> ------- Additional Comments From cantor.2@osu.edu 2006-11-07 21:18
>> -------
>> An enveloped signature omits anything inside the Signature element
>> apart from
>> SignedInfo. KeyInfo is not commonly signed. The only attack possible
>> is against
>> broken software that doesn't understand that KeyInfo is advisory, not
>> trusted
>> information.
>>
>>
>> --
>> 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.
>>
>
>
RE: DO NOT REPLY [Bug 40921] - XML contents modified and signature normallly validated.
Posted by Scott Cantor <ca...@osu.edu>.
> Maybe I'm misunderstanding the commentary made so far in this
> bug report.
>
> If KeyInfo is indeed advisory, then how does one establish the
> trustworthiness of an enveloped signature?
As Sean said, trust, whatever you believe that means, is outside the scope
of XML Signature and of the ds:KeyInfo element. The element is used to
transmit hints to the relying party to assist in efficiently verifying the
signature. After that, there's an entirely separate set of code that every
application has to have that evaluates the "legitimacy" of the signing key,
and you also have to verify that what's been signed is what you expected.
Both steps can be very complex.
I think it would be useful if the xmlsec Javadocs made this somewhat more
clear in the doc comment for any "verify" methods that exist. People need to
be very clear that that method does not mean "trust this message". It's a
drop in the bucket. I worry sometimes about the applications out there using
this stuff.
-- Scott