The real crux...

I suppose I should point out the following:

Consider Rich Himes' scenario in which a signed resource must be moved from
the inside to the outside of a surrounding document.  On the inside it is
base64 encoded and in some Object X, so it must be identified by an XPath of
the form "//[@id="X"]/child::text()" (or substitute an IDREF for the first
part should we decide to keep IDREF).  *After* the XPath transform, we need
to base64 decode it.

To move this resource to the outside of the document, we must throw out both
the XPath transform (whether or not it locates X) and the base 64 decode
transform.  Further, the URI must change from "" to "something".

If I were forced to do this with the current syntax, I would use a Manifest.
In the core signature, the Manifest will be identified by an
ObjectReference, which means that I can apply transforms to it (in the same
way I described transforming SignedInfo).  Since I can apply an XPath
transform to the Manifest, I can use delete the specific things I need to
delete from the Manifest (and maintain security by being quite precise about
it using XPath) such that the DigestValue over the Manifest will not change
if the Location and specific transforms are changed by the application.

Thus, the crux of the matter is not whether we can solve Rich's problem.  It
is a question of whether core behavior or application specific behavior will
be necessary to solve Rich's problem.

The Location-as-hint and assertions-about-assertions ideas try to skate
around the problem that core behavior cannot solve Rich's problem without
introducing application-specific behavior *within* core behavior.  I think
that this is like going from the frying pan into the fire (at the very
least, we haven't gotten out of the frying pan).

What we should be saying is one of the following three:

1) Treat URI location as URL, allow signed XPath transform of SignedInfo,
and everyone's problems are solved by core behavior (as I showed at FTF#3).

2) URI resolution is application specific, so we should move it to the
Manifest and simplify the syntax.

3) A design limitation prevents the solution of problems in which the
Location and/or some transforms must change.  Applications needing to do
this can still use XML signatures by using Manifests (as described above),
but their signatures will require custom code to validate.

The other solutions are hacks that accomplish #3 in a manner inconsistent
with how we hope to capture other application-specific behaviors.

John Boyer
Software Development Manager
UWI.Com -- The Internet Forms Company

Received on Wednesday, 24 November 1999 16:17:48 UTC