Re[2]: Re[2]: The real crux...

I'm using the term "manifest" in the sense of "an invoice of cargo", that is, a
list that clearly states what is and is not included in the signature, and
provides us with more clarity and flexibility than we have with the current
approach, while still allowing closure.

Thanks,
Rich

____________________Reply Separator____________________
Subject:    Re: Re[2]: The real crux...  
Author: "Joseph M. Reagle Jr." <reagle@w3.org>
Date:       11/30/99 1:04 PM

At 16:27 99/11/29 -0700, rhimes@nmcourt.fed.us wrote:
 >I'd like to see it head in this direction also.  Also, it is starting to
look
 >very messy to me.  I'd like to see Object, Manifest, Package, and
 >SignatureProperties combined in some way, preferably as the Manifest (in
 >unsigned <Signature> if present).  I'm not adverse to having multiple
digests
 >(object references) in SignedInfo, though, or allowing an optional direct
 >reference, though it might be cleaner to always use a manifest.  (Also,
maybe
 >location could be one of the optional SignatureProperties if one only
wants to
 >sign location and not content.)

In my mind, an object is the element which we define as having an open
content model. People can put whatever elements they want within an object
element (or if people wanted to use schema classes, other things could be a
subclass of an object).

Manifest, package and signature properties are all different "applications"
with different meanings that could be within an object (or a sub-type of).

 >It seems to me that this means the actual tags and attributes of
<Manifest> and
 >its sub-elements shouldn't automatically be hashed.  Rather, the Manifest
should
 >call out the list of things to be included in the hash (or not, perhaps
 >defaulting to include).  I think it would be far more lucid to have an
attribute
 >in each Manifest entry that specifies (hash=?)include/exclude rather than
use
 >XPath (also an attribute to specify base64-decoding of element content).
The
 >actual object(s) could be embedded or targeted.  I think
SignatureProperties
 >should be included in Manifest.  If there is a requirement for a
MegaManifest
 >that is application-specific, we should give it another name, but Manifest
 >should have core behavior for signature and authentication.

I think of a Manifest as a collection of resource/content references and I'm
not sure what SignatureProperties has to do with that. SignatureProperties
is a set of semantics related to the signature itself. (A specific place to
make an assertion about the signature.)


_________________________________________________________
Joseph Reagle Jr.   
Policy Analyst           mailto:reagle@w3.org
XML-Signature Co-Chair   http://www.w3.org/People/Reagle/