Re[2]: The real crux...

Marc wrote:

>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.

I Agree.  If SignedInfo isn't always signed info, it's not intuitive and should
have another name.

>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.

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 the process, there are two core capabilities I need that John has mentioned,
those are unfixed (movable) location and unfixed base64-decode (the ability to
move a document internal to/from external and external to external without
breaking the signature).  Actually, this sounds like it should have been a basic
requirement, not just for me but for the generic world of applications.

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.

Thanks,
Rich

Received on Monday, 29 November 1999 18:31:47 UTC