W3C home > Mailing lists > Public > w3c-xml-sig-ws@w3.org > April 1999

RE: MIME Blobs

From: Richard D. Brown <rdbrown@GlobeSet.com>
Date: Thu, 8 Apr 1999 11:33:11 -0500
To: <rhimes@nmcourt.fed.us>, <w3c-xml-sig-ws@w3.org>
Cc: <xml-dsig@globeset.org>
Message-ID: <000501be81dd$7f3221e0$0bc0010a@artemis.globeset.com>

I though I had addressed this point in a previous email exchanged on
xml-dsig mailing list, but I just found out that I had actually never
responded to you. So, beforeall, please accept my apologies for such a lack
of courtesy.

To my knowledge, there is no existing standard that allows signature of the
raw material per se. ASN1 cryptographic syntaxes such as PKCS#7 and CMS as
well as the XML Digital Signature Proposal requires the raw material to be
enveloped before authentication. With PKCS#7 or CMS, the raw material is
embedded in a ContentInfo element and authentication is applied to the
DER-encoded octets of the ContentInfo. With the Digital Signature Proposal,
the raw material is first base64 encoded and then embedded in a Package
element and authentication is applied to some canonical representation of
the Package element.

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.

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



  <package encoding="base64" origin="http://doc1.pdf"

  <package encoding="base64" origin="http://doc2.pdf"

        <resource href="http://doc1.pdf" halg="sha1">
        <resource href="http://doc2.pdf" halg="sha1">
      ... algorithm definitions ...
    <value encoding="base64">


Will this kind of approach make sense to you?


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 12:32:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:44:59 UTC