Re: Multiple digests of the same resource

[jason marshall <jd...@gmail.com>]

Interesting point.  It wasn't clear to me from reading the code that
this was the only thing this method changes about the signature check.
 Will regular references still be validated (ie, references to other
elements within the document)?

So if I did that, then I'd still have to check to make sure that
SignatureB only signed across files that were in SignatureA, and that
the digests listed in SignatureB match those in SignatureA.  If not,
I'd have to turn following back on, and run the check again.

I think I could probably live with that, if that's really the only
reduction in signature checking that occurs.

Thanks,
Jason


On 10/23/06, Sean Mullan <Se...@sun.com> wrote:
> Did you know that Manifest/Reference digests are not validated by default?
>
> This is just a guess, and probably not exactly what you want because I
> don't think I fully understand the problem, but you could validate the
> first signature including the manifests and then disable it for
> subsequent signatures, see
> (XMLSignature.setFollowNestedManifests(false))... so effectively your
> file digest is only calculated and verified once.
>
> --Sean
>
> jason marshall wrote:
> > I have a usage of XML Signatures that's probably at the intersection
> > of several out-of-the-ordinary uses of the spec, and I'm wondering if
> > there are any shortcuts I can take.
> >
> > I am using ds:Object/ds:Manifest References to refer to external
> > files, for the purposes of providing a digest of files which accompany
> > to the XML document.  Sometimes these files are quite large.
> >
> > I am also using detached signatures, sometimes more than one to a
> > single XML file.  In this case the certs mean different things to
> > different consumers of the same XML file.  They might be added all at
> > once, or accumulated over time.
> >
> > This results in a situation where one XML document posesses multiple
> > digests for the same file.   This presents a throughput problem when
> > verifying signatures, as the digests in this case are the proverbial
> > tall tent pole by a good margin.  I haven't discovered any mechanism
> > built into the XMLSec API which allows or encourages the sharing of
> > digest calculations for the same resource.
> >
> >  From my reading of the Java implementation, all of the fields and
> > methods related to calculating the digest are safely hidden away from
> > my grubby hands, and probably for good reason considering how fragile
> > this could make the verification code.  I'm wondering if there's some
> > way to accomplish this without jeopardizing correctness, and
> > especially without heavily subclassing the Reference or Manifest class
> > to do so.
> >
> > Or am I out of luck?
> >
> > Thanks,
> > Jason Marshall
> >
> >
>
>


-- 
- Jason

Re: Multiple digests of the same resource

[jason marshall <jd...@gmail.com>]

I've looked into this a bit further now, and can make some more
informed comments.

The biggest problem with this suggestion is that the XMLSec API does
not expose sufficient information to reason about whether a given
nested manifest can be skipped or not.

That is, if you look at the verify code in Manifest, you'll see that
it builds the nested Manifest inline in the verification method.  It
performs what appear to be a number of delicate operations (some
including protected methods) to construct the nested Manifest
precisely as it should appear.

If I can't correctly reproduce this operation, how can I be certain
that two manifests bear the same digests, and hence represent
redundant operations?  Once I start replicating functionality, I open
myself up to twisty new attack vectors.

It seems to me that the entire nested manifest mechanism in the XMLSec
project could use a bit of TLC.  Between this matter, and the fact
that you have to quite literally -trick- the API into not loading
external references into memory (I've posted what I think is a
reasonable workaround to the bug entry in the database), it seems like
one is actively discouraged from using the API to sign files.

I've seen some commentary (where, I don't recall) suggesting that
parts of the Manifest system were being considered for a rewrite.  I'm
requesting that some consideration also be given to exposing nested
Manifests to third party code when this occurs.  Some additional
method for comparing them to each other would be spectacular, but I
suspect that equivalence depends to some extent on the context in
which the signatures are used.

Thanks,
Jason Marshall




On 10/27/06, jason marshall <jd...@gmail.com> wrote:
> Interesting point.  It wasn't clear to me from reading the code that
> this was the only thing this method changes about the signature check.
>  Will regular references still be validated (ie, references to other
> elements within the document)?
>
> So if I did that, then I'd still have to check to make sure that
> SignatureB only signed across files that were in SignatureA, and that
> the digests listed in SignatureB match those in SignatureA.  If not,
> I'd have to turn following back on, and run the check again.
>
> I think I could probably live with that, if that's really the only
> reduction in signature checking that occurs.
>
> Thanks,
> Jason
>
>
> On 10/23/06, Sean Mullan <Se...@sun.com> wrote:
> > Did you know that Manifest/Reference digests are not validated by default?
> >
> > This is just a guess, and probably not exactly what you want because I
> > don't think I fully understand the problem, but you could validate the
> > first signature including the manifests and then disable it for
> > subsequent signatures, see
> > (XMLSignature.setFollowNestedManifests(false))... so effectively your
> > file digest is only calculated and verified once.
> >
> > --Sean
> >
> > jason marshall wrote:
> > > I have a usage of XML Signatures that's probably at the intersection
> > > of several out-of-the-ordinary uses of the spec, and I'm wondering if
> > > there are any shortcuts I can take.
> > >
> > > I am using ds:Object/ds:Manifest References to refer to external
> > > files, for the purposes of providing a digest of files which accompany
> > > to the XML document.  Sometimes these files are quite large.
> > >
> > > I am also using detached signatures, sometimes more than one to a
> > > single XML file.  In this case the certs mean different things to
> > > different consumers of the same XML file.  They might be added all at
> > > once, or accumulated over time.
> > >
> > > This results in a situation where one XML document posesses multiple
> > > digests for the same file.   This presents a throughput problem when
> > > verifying signatures, as the digests in this case are the proverbial
> > > tall tent pole by a good margin.  I haven't discovered any mechanism
> > > built into the XMLSec API which allows or encourages the sharing of
> > > digest calculations for the same resource.
> > >
> > >  From my reading of the Java implementation, all of the fields and
> > > methods related to calculating the digest are safely hidden away from
> > > my grubby hands, and probably for good reason considering how fragile
> > > this could make the verification code.  I'm wondering if there's some
> > > way to accomplish this without jeopardizing correctness, and
> > > especially without heavily subclassing the Reference or Manifest class
> > > to do so.
> > >
> > > Or am I out of luck?
> > >
> > > Thanks,
> > > Jason Marshall
> > >
> > >
> >
> >
>
>
> --
> - Jason
>


-- 
- Jason