DO NOT REPLY - XML contents modified and signature normallly validated

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=40
921>.
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=40921





------- Additional Comments From cantor.2osu.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=ema
il
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the
assignee.

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, bugzillaapache.org <bugzillaapache.org> wrote:
> ------- Additional Comments From cantor.2osu.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=ema
il
> ------- You are receiving this mail because: -------
> You are the assignee for the bug, or are watching the
assignee.
>


-- 
- Jason

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, bugzillaapache.org <bugzillaapache.org> wrote:
>> ------- Additional Comments From cantor.2osu.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=ema
il
>> ------- You are receiving this mail because:
-------
>> You are the assignee for the bug, or are watching
the assignee.
>>
> 
> 

On 11/8/06, Sean Mullan <Sean.Mullansun.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, bugzillaapache.org <bugzillaapache.org> wrote:
> >> ------- Additional Comments From cantor.2osu.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=ema
il
> >> ------- You are receiving this mail because:
-------
> >> You are the assignee for the bug, or are
watching the assignee.
> >>
> >
> >
>
>


-- 
- Jason

> 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

> 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