Re[2]: MIME Blobs

     
     Richard,
     
     Thanks for your response.  Please see comments and questions below.
     
     Rich


______________________________ Reply Separator _________________________________
Subject: RE: MIME Blobs 
Author:  <rdbrown@GlobeSet.com> at ~Internet
Date:    4/8/99 11:33 AM


     
> However, there is still a solution to your problem. Both approaches allow 
for a particular signature mechanic formally known as detached-signature. 
According to this scheme, the hash is computed directly over the raw 
material. The resulting hash value in then inserted into a Signature 
Information Block, which is finally signed by the originator. Notice, 
however, that the signature is not applied directly to the raw material. The 
point being that there are signature attributes such as the algorithms being 
employed that must be sealed for obvious security reasons into the signature 
value. But, this approach is a bit closer to what your are looking for.
     
     Yes, this helps, thanks.  I think the raw hash is sufficient, as is 
     the indirect signature.
     
> Nonetheless, this approach solves only one aspect of your problem. How to 
I package the document and the signature into a single message. I would 
argue that it is very similar to the problem solved by S/MIME, which is 
built on top of CMS. S/MIME leverages a signature standard (CMS) and a 
"packaging" standard (MIME multipart) to address the problem. Probably we 
shall do the same with XML. 

By "we" are you referring to the DSig workgroup?

> What's about promoting an XML-based S/MIME-like DTD. This should be 
something close to a document that comprises a package element and a 
signature element. However, the resource element contains in the manifest of 
the signature element refers to the external resource instead of the 
internal package. Probably we will have to define a new attribute on the 
package element so that it can display the origin of the resource contained 
therein.

     Suppose a document is being transmitted from one location to another 
     (similar to e-mail, but I am facing the same problem with "live" 
     electronic filing.)  As I read what you are saying, there is no 
     problem with the hash (of the raw document) and the signature (of the 
     manifest).  However, in order to authenticate the signature, either 
     the original document of the originator would have to be URI- 
     addressable (it isn't a good idea to have attorneys hold the source 
     document for court references, but it should be signed at the client), 
     or an unencoded copy could be created locally and rehashed.  If this 
     is the case, and if I understand the problem, it shouldn't be 
     difficult to add an attribute to the hash specifying that it is 
     performed on the unencoded blob rather than an XML-based hash.  BTW, 
     is the content of the <resource> elements below the document or the 
     hash?
     
     Thanks,
     
     Rich
     
--- ILLUSTRATIVE PURPOSES ONLY ---
     
<document>
     
  <package encoding="base64" origin="http://doc1.pdf"
type="application/pdf">
    ABcv1jxfgdJNGrdjn==
  </package>
     
  <package encoding="base64" origin="http://doc2.pdf"
type="application/pdf">
    ABcv1jxfgdJNGrdjn==
  </package>
     
  <signature>
    <manifest>
      <resources>
        <resource href="http://doc1.pdf" halg="sha1">
          AABhrhrmjTYPhvhakj==
        </resource>
        <resource href="http://doc2.pdf" halg="sha1">
          AABhrhrmjTYPhvhakj==
        </resource>
      </resources>
      ... algorithm definitions ...
    </manifest>
    <value encoding="base64">
      falg1gwHGwhejJEKur...
    </value>
  </signature>
     
</document>
     
     
Will this kind of approach make sense to you?
     
Sincerely,
     
Richard D. Brown
Software Architect - R&D
GlobeSet, Inc. Austin TX - U.S.
     
     
> -----Original Message-----
> From: w3c-xml-sig-ws-request@w3.org
> [mailto:w3c-xml-sig-ws-request@w3.org]On Behalf Of 
> rhimes@nmcourt.fed.us
> Sent: Wednesday, April 07, 1999 9:03 PM 
> To: w3c-xml-sig-ws@w3.org
> Subject: MIME Blobs
>
>
>
>      I've encountered a related difficulty in a specification 
> I'm working
>      on at
>
>      http://www.nmcourt.fed.us/xci/xcispec.htm 
>
>      in which I'm defining a protocol for exchange of 
> information between a
>      court and attorneys, including electronic filing.  The 
> problem is that
>      our court is currently accepting electronic filings in 
> PDF format.  We
>      want the PDF documents signed in their native format 
> (i.e. as close to
>      presentation format as possible).  If the PDF document 
> were packaged
>      within XML, it would presumably be base64 encoded and 
> tagged with a
>      MIME package element (type="application/pdf").  The 
> problem is that I
>      need to include the signature of the source PDF in the 
> XML document,
>      not the base64 version with the tags, and I'd like to do it in a 
>      "standard" way.
>
>      Other applications may run into this same problem, where 
> the encoded
>      content is application-specific but signed in its native 
> format.  An
>      example may be future e-mail systems using MIME. 
>
>      I would like the standard to include the ablility to 
> specify that a
>      hash (signature) is applied only to the unencoded 
> content of a MIME
>      package (the original binary blob) without having to write it 
>      externally for verification.
>
>      Rich Himes <rhimes@nmcourt.fed.us> 
>
>
> ______________________________ Reply Separator 
> _________________________________
> Subject: Re: unparsed entities
> Author:  <w3c-xml-sig-ws@w3.org> at ~Internet 
> Date:    4/7/99 5:50 PM
>
>
> Hi Richard,
>
>
> >John,
> >
> >What is being signed shall be explicitly specified in the signature 
> manifest
> >by means of XML links. Thus, if an external/unparsed 
> entities needs to be
> >embedded into the signature process then this entity shall 
> be packaged into
> >the document and a link to the package element shall be 
> inserted in the
> >signature manifest. Conversely, if you can suffice with an external 
> >reference to the resource, but still want to bind the actual
> value of this
> >resource into the signature process then you should insert 
> both the hash
> and
> >the reference to this external entity into the signature 
> manifest. Notice
> >that you should not expect the "signature engine" to verify 
> that the hash
> of
> >the external entity matches with the one inserted in the signature 
> manifest.
> >An implementation that complies with the standard should 
> only assess that
> >the signature value is valid in regard to the signature 
> manifest. It falls
> >under the responsibility of the application layer to verify 
> the actual
> value
> >of the external entity.
>
> The external entities, once packaged into the document, can be signed 
> directly by simply regenerating a portion of the document
> that happens to
> include the elements containing the packaged external entities. 
>
>

Received on Thursday, 8 April 1999 17:25:29 UTC