Re: Just Reconstruct (was RE: Without breaking (formerly: The real crux... ))

John Boyer wrote:

> Since it is quite likely that the application designer will know about the
> archive before the signature element is defined, it is possible to create a
> manifest M that contains an objectreference O_1 indicating an element X's
> base64 decoded text. The objectreference to X in M MUST use an xpath of
> string(child::text()) followed by a base64 decode (Rich must uses these
> transforms whether he acknowledges it or not).
>
> The objectreference O_2 in the signature that indicates the manifest M can
> use transforms that omit the specific xpath and base64 decode describe
> above, as well as the Location or IDref that indicates X.  This allows him
> to move the data from within X to an archive and to make the necessary
> modifications to objectreference O_1 (the one appearing in M).
>
> Thus, the signer's signature can be preserved despite the desired changes.
> This is the notion of document closure. Certain specific changes can be
> allowed by a signer since it can be proven that the specified changes pose
> no security risk.
>
> Rich indicated that he did not like the manifest idea and wanted core
> behavior to do the work.  The stated reason was so that he could get
> off-the-shelf software to do the work.  Yet, it is quite likely that vendors
> will implement the manifest part of the spec, making API calls available to
> applications like CoreValidate() and ManifestValidate().  One extra function
> call is not a lot to ask!

...

> However, I can agree that it is not absolutely necessary to address these
> problems in core behavior since these applications can simply reconstruct
> the document signed before passing them to other applications that only
> understand core signature validation.  My main point in mentioning these
> scenarios is that they came to me from others, I see how to modify core
> behavior to solve them by transforming SignedInfo, there really is no
> alternative that can be secure, so the WG has to decide whether to
>
> 1) Make the modification to transform SignedInfo
> 2) Decide that the scenarios are application specific

I oppose 2) since I think the sceanrios presented so far show that signing and
validating moving resources is a very general need. To phrase it abstractly, it
stems from the web being dynamically changing. So, there is not only a
distinction between internal and external resources in (information) space but
also an analogouos between fixed and movable ones in time direction. this
affects not only XML-DSig but any sufficiently general web application.

Especially for XML-Signatures, one is lead to the conclusion that the location
of the signed resource  has to be omitted from the digesting chain that produces
the (input for the) digital signature. If one accepts that this issue is indeed
so basic, this speaks for including this ability in core signature behaviour.

The two solutions proposed so far are 1) and transforms over a manifest
described above. I see no technical arguments against both.What makes me feel
uneasy about them is that they are not explicit, that is, directly
human-understandable. Again, if the orthogonal discriminations internal vs.
external and fixed vs. movable are accepted as basic, what speaks against having
special syntactic provisions in XML-DSig for _both_, like an additional
<RelocatableObjectRef> element?

Andreas
--------------------------------------------------------------------
Dr. Andreas U. Schmidt, Dept. SIT | mailto:aschmidt@darmstadt.gmd.de
GMD German National Research      | phone :+49-6151-869-712
Center for Information Technology | fax   :+49-6151-869-704
--------------------------------------------------------------------

Received on Wednesday, 8 December 1999 05:01:06 UTC