Re: importing terminology in "XML-Signature Requirements"

Richard,

Thanks for your response.  Please see below.

> I am afraid that this approach might be a bit too much specific. In fact, I
> start to doubt about the actual benefit of hashing the unencoded content. In
> final, you sign the canonical representation of the Manifest and not the
> hash. Therefore, in order to sustain a claim, you will have to
> establish/demonstrate/prove the construction of the signature WRT to the
> original document, the signer key/credential, and the cryptograpic
> algorithms. Adding one step in the demonstration is not necessarily the/a
> problem (thoughts...)

I understand the concern, and I am becoming more convinced, thanks.  I now
believe I can work around this, and if nobody else thinks it is an issue, I'm
willing to drop it (it is on the requirements list.)

Does the compromise of at least allowing computation of the hash from the
unencoded document sound more reasonable?  The hash is easily recoverable and
verifiable (but not the original authentication if we can't somehow encapsulate
the original signature as an audit trail.)

More thoughts, suppose we have an XML-signed binary.  Somehow I am more
comfortable with it travelling (from document to document) with its manifest for
validation than I am requiring it to travel in it's precise original Package
structure (Package contains ContentInfo and Value, with Value carrying the
base64.) For one thing, c14n issues travel with it.

Even with the manifest, I'm concerned with (signed) reference collisions in
combined documents (such as a duplicate link ID that can't be fixed because both
are signed) but I don't have a good grasp on these issues yet.  Having the
capability of carrying these in the same structure rather than using links might
resolve this, which (if I remember correctly) John Boyer was suggesting (yes, I
know an included hash breaks itself, but I believe he was suggesting excluding
the hash during hash.)

Thanks,
Rich

Received on Friday, 30 July 1999 20:12:12 UTC