Re: The real crux...

I think I'm leaning more towards John's XPath-on-SignedInfo solution than
location-as-hint, but I'm still a bit uncomfortable with it.

Speaking as a human, I'd really rather see everything in SignedInfo be
signed, and not have to worry about applying transformations to it.  I'm
going to get very confused if bits of SignedInfo are omitted from the
signature.

On the other hand, I realize that sometimes people will want to sign a
document's URI, and sometimes they won't (insert similar thoughts about
transforms here).  So we really do need a mechanism that allows us to omit
pieces from what gets signed.  I just think that a self-transforming
SignedInfo is too confusing, that the stuff that gets transformed should be
isolated.

So I propose that John's solution using the current syntax -- that we use a
Manifest -- be formally adopted.  I'd go so far as to say that SignedInfo
must only contain a single ObjectReference to a Manifest that is inside the
Signature element, but not in SignedInfo.  In other words, allow only a
single IDREF ObjectReference inside SignedInfo.  The SignedInfo reference to
the Manifest could then contain various transformations on the Manifest to
omit or include URIs and/or various transforms.

This makes things a bit more explicit as to what's being directly signed, and
what's being transformed in various ways.

I'd like to make a point about the core behaviour resolving URIs.  There are
two ways to sign URIs, either:

 (a) as a pure reference, where whatever is retrieved from the URI isn't
itself signed.  A URI to retrieve a live audio stream would be a good example
(see my message on the "Detached Signatures Vs Detached Objects" thread for a
start at how to authenticate the retrieved data).  Basically, in this case
the URI is fixed but the data it points to can change.

 (b) as an absolute location for some data, where whatever is retrieved from
the URI is also signed.  In this case, both the URI and its document are
fixed by the signature.

For case (a), core behaviour needn't (and shouldn't) do anything to resolve
the URI.  For case (b) though, what's on the other end of the URI is vital to
verifying the signature, and so core behaviour really has to know what's
there.

I have a couple of problems here.  My first is that I'm not sure the current
syntax allows us to differentiate between the two ways to sign URIs.  (If it
does, could someone please show me.)

My second problem is that I can't see how, in case (b), the core behaviour
can be expected to always be able to resolve the URI.  HTTP isn't the only
protocol on the planet, and it isn't practical for the core behaviour to be
conversant in evey protocol.  There are conceivably a myriad of private
protocols that people might want to use with XML signatures.  In practical
terms, I don't see how the core library can do anything but ask the
application to resolve a URI.

		Marc


John Boyer wrote:
> 
> 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 Friday, 26 November 1999 14:04:54 UTC