[xmlsec] "soft error" when calling xmlSecDSigValidate

[Meg Morgan]

The necessity of detached signatures is that we need for our
transcripts to be able to generate signatures on various subsets
of an election transcript without modifying the underlying
transcript data.  The transcript itself is signed by some election
official, and then the fact that various parts of the transcript have
been checked by various people is reflected by their signatures of the
various subsets.  Perhaps this can be done with lots of xml translations,
but just appending "detached" signatures to the end, with description of
what it was a signature for, seemed simpler.  

It is true that we are losing some of the xml DSig goodness.
At some point perhaps we will want it back, but our protocol
currently specifies detached signatures, so the best thing to
do aat this point is to just implement for ourselves something
like a detached signature.

meg

Aleksey Sanin wrote:
> 
> I just wonder, why you don;t want to put signature in the original
> document? You system may easily insert the Signature at the
> beggining of original document and later easily remove it so
> nobody else will see it.
> IMHO, the hash based approach removes all the XML DSig "beef".
> There is no reason why you could not just send calculated hash
> in any binary format.
> 
> Aleksey
> 
> Meg Morgan wrote:
> 
> >What we decided to do is to create a hash of the data we REALLY want
> >signed, and put the hash into a nice little xml tree, and sign THAT.  That
> >way we can pluck out the signature from the document and call it "detached"
> >if we want to.
> >
> >To check, we recalculate the hash of the original data, compare it with
> >what is in the signed document blob, then use the xmlsec functions to
> >check the signature against the public key.  In this way we can avoid
> >using URI references while still masking the content of our original
> >data.
> >
> >Thanks again,
> >meg
> >
> >Aleksey Sanin wrote:
> >
> >
> >>Actually, you have one more option: use a special protocol name
> >>(like "thisismyprotocol://....") and write custom protocol handlers
> >>that will read document from memory. Thought, it might be not such
> >>a good idea because of interop issues in the future.
> >>
> >>Aleksey
> >>
> >>
> >
> >
> >

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Meg Morgan                           425/450-2754
meg at votehere.net                   http://www.votehere.net