Re: Scenarios upgrade and Data Model RSN

Thanks for the scenarios, they really helped me to understand the current
status.
I now firmly believe the <Package> element is just clutter.  From the scenario
in 2.1.1:

<dsig:Package id='data'>
   <dsig:ContentInfo type='urn:mime:image%2fjpeg'/>
   <dsig:Value encoding="base64">...</dsig:Value>
</dsig:Package>

<dsig:Signature>
   ...
   <dsig:Locator href='#data'/>
   ...
<dsig:Signature>

Would be cleaner as:

<MyElement ContentType='urn:mime:image%2fjpeg' encoding='base64'
      id='data'>...</MyElement>
...
   <dsig:Locator href='#data'/>
...

In my understanding, this is a _valid_ construct (in the current spec) which
signs only the base64 text (not the content type or the encoding).  I suspect
that this is the way it will be used by applications, that is, without the
Package.  If this is considered a security problem (the content type and
encoding aren't included in the hash), then they should be included
(duplicated) in the manifest.  Note that this also works as a direct
envelopment, as in the <impp> example..

My primary interest initially will be in validating the document, that is,
assuring it hasn't changed since it was filed with the court.  Assuming they
have a signed manifest (<Signature> element), suppose an attorney downloads a
copy of a PDF from the Internet (purporting to be an official copy), and wishes
to validate that it is an exact copy of the official document.  In the
<Package> scenario, they (the application) would have to wrap it in a Package
element, hoping to construct it in exactly the same way (e.g. assuming there
aren't multiple synonyms for the same content type), encode it, canonicalize it
correctly, hash it, and compare it to the hash in the manifest.  This is a
critical problem, in my view, with unnecessary clutter and difficulties for
application developers.  More likely, the hash would be on the unencoded
external document or the encoded internal document (does this lack of symmetry
bother anyone else?)

Also, I would like the manifest to support an unencoded hash of an internal
document.  All that would be required is a parameter such as reformat="ueb64"
(unencoded base64).  So, in order to validate the document mentioned in the
previous paragraph,  the only requirement (other than validating the signature
of the manifest) would be to hash the PDF directly and compare it to the hash
in the manifest.

Thanks,
Rich

w3c-ietf-xmldsig@w3.org wrote:

> Two notes on action items. John has sent me the latest scenarios draft,
> which I've posted at [1]. (Thanks John!) I've been having a good
> conversation with Ralph Swick on the data model, at first seemingly very
> complex, and now getting simpler with some elegance/coolness resulting. But
> I still don't have anything I can share with the group yet. Maybe by
> tomorrow I'll have a GIF of  DLGs, maybe even some schema definition
> language, but perhaps not. Took me much longer to catch up on trivia,
> adminstrivia, and manegeria <smile> after being away for a week. Sorry!
>
> [1] http://www.w3.org/Signature/Drafts/xmldsig-scenarios-990818.html
>
> Forwarded Text ----
>  From: "John Boyer" <jboyer@uwi.com>
>  To: "Joseph M. Reagle Jr." <reagle@w3.org>
>  Subject: Scenarios upgrade
>
>  Hi Joseph,
>
>  Attached is a new scenarios document with more information in it.  Please
>  post this for consideration by the WG before tomorrow's call.
>
> End Forwarded Text ----
>
> _________________________________________________________
> Joseph Reagle Jr.
> Policy Analyst          mailto:reagle@w3.org
> XML-Signature Co-Chair   http://w3.org/People/Reagle/
>
>   ------------------------------------------------------------------------

Received on Thursday, 19 August 1999 12:07:36 UTC