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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
