W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > April to June 1999

Re: Chair Request: Final Comments Submissions to RD

From: Richard Himes <rhimes@nmcourt.fed.us>
Date: Fri, 11 Jun 1999 14:57:30 -0600
Message-ID: <3761783A.52CC0EC@nmcourt.fed.us>
To: w3c-ietf-xmldsig@w3.org

Thanks, Todd.  I agree with the need for signed BLOBS.  I'm not convinced that
signing the base64 representation is sufficient.  It is desirable to sign the
document in its native format (e.g. PDF or images), which is closer to the
format at the time of presentation for signature (that is, we can assure that
the signature represents the base64, but we aren't as assured that the base64
represents the original BLOB).

Also, and I think this is more important, if legacy programs (including word
processors and e-mail) produce signatures for BLOBS, there won't be a _standard_
way to represent those existing signatures in XML for later data mining
applications (all the legacy validation engines will have to be retained).  I
agree that the embedded document should be base64, just that we should allow a
signature for the unencoded version of the BLOB.

Richard Brown gave me a proposed solution using his spec, and I hope the new
design not only doesn't lose the capability but actually formalizes some
procedure.  In his solution, (I don't have immediate access to the exact
solution), he treated the signed blob as a (pseudo) external reference in
<Locator href=...>, but also included the embedded base64 encoded version in
<Package>.  The two were tied together with a common href attribute.

Rich Himes
rhimes@nmcourt.fed.us

w3c-ietf-xmldsig@w3.org wrote:

> Hi Todd,
>
> I agree with the need for this.  In the so-called Brown-IETF draft, please
> see section 5.8, which discusses a package element that can be used to
> include arbitrary data using either no encoding (except CDATA and/or
> escaping) as well as base64.  Section 5.4 shows how a package can be fitted
> into a dsig:Document, which can also contain one or more dsig:Signature
> elements.
>
> Furthermore, the ability of the manifest to indicate elements within the XML
> root element or its subelements (including the dsig:Document element) means
> that an application can choose to base-64 encode any arbitrary blob of data
> and have it signed.
>
> John Boyer
> Software Development Manager
> UWI.Com -- The Internet Forms Company
> jboyer@uwi.com
>
> -----Original Message-----
> From: Winchel 'Todd' Vincent, III <winchel@mindspring.com>
> To: IETF/W3C XML-DSig WG <w3c-ietf-xmldsig@w3.org>; Joseph M. Reagle Jr.
> <reagle@w3.org>
> Date: Friday, June 11, 1999 10:22 AM
> Subject: Re: Chair Request: Final Comments Submissions to RD
>
> >
> >> 2. Design Principles and Scope
> >>
> >>     1. The specification for XML-DSig shall describe how to digitally
> >>        sign an XML document. [Charter]
> >>     2. The meaning of the signature is very simple:  The XML signature
> >>        syntax associates the cryptographic signature value with Web
> >>        resources using XML markup. The meaning of the signature may be
> >>        extensible by a set of semantics specified separately. [Charter]
> >>     3. An XML-Signature can apply to parts of XML documents. [Charter]
> >>        The solution shall enable authentication of part or totality of an
> >>        XML document.   [Brown]
> >>     4. More than one signature may exist over any resource. [Charter] The
> >>        solution shall provide for extended signature functionality such
> >>        as co-signature, endorsement, plurality of recipients, etc.
> >>        [Brown]
> >>     5. The specification will not specify methods of serialization or
> >>        canonicalization. XML content is normalized by specifying and
> >>        appropriate content C14N algorithm [[34]DOMHASH, [35]C14N];
> >>        applications are expected to normalize application specific
> >>        semantics prior to handing data to a XML-DSig application.
> >>        [Charter]
> >
> >At the workshop, we discussed the ability to sign BLOBs not simply an XML
> >document.  I do not see this requirement above.
> >
> >Two examples of why this requirement is very important for Legal XML as
> well
> >as other vertical industry applications.
> >
> >First, there are three barriers to creating XML documents in a verticle
> >industry: (1) creating the statandrd DTD(s) and other specifications (2)
> >creating the authoring tools that will use the XML DTDs to allow authors to
> >create XML documents (3) motivating authors to use the XML authoring tools.
> >
> >It can be expected that the order of events described above will occur (1),
> >(2), (3).  The practical reality is that lawyers will continue to create
> >documents in Word and Word Perfect for sometime into the future.  (It
> >appears most courts will require PDF documents to be filed in court.)
> >Nevertheless, XML can be used to capture and transmit important
> >case/document management information that can be submitted along with
> >whatever BLOB the court or other entity (law office) accepts.  If one sends
> >XML and a BLOB together, one would like to sign everything using the same
> >technique -- in this case XML that describes the signature.
> >
> >Second, any electronic document (BLOB) created in any application is
> >potential evidence in a court case, for government reporting, or simply as
> >lawyers exchange information.  For instance, an Excell spreadsheet might
> >contain important evidence used in a court case.  Such evidence, in the
> >paper world, is routinely attached as an exhibit to a filing or other
> >report.  Even if the primary filing or report is in XML, there is still a
> >need to attach and sign exhibits, which may be XML or BLOB or several of
> >both.
> >
> >I do not believe that the above requirements are limited only to exchanging
> >legal information/documents.  I suspect the same is true in other vertical
> >industries.  I would suggest that the usefullness of Signed-XML will be
> >depreciated in the market if it does not have the ability to use XML to
> sign
> >both XML and/or BLOBs.
> >
> >I realize there are other industry accepted, non-XML techniques for signing
> >BLOBs.  However, in my view, the market is clearly moving to XML
> >solutions -- which means XML tools, XML experts, XML methodology, etc.
> >Accordingly, there is a need for an XML technique for signing not simply
> XML
> >but also BLOBs.
> >
> >I do not see this requirement spelled out anywhere and I did not think it
> >was at issue . . . perhaps I'm missing something??
> >
> >> 3. Requirements
> >>
> >> Signature Data Model and Syntax
> >>
> >>     1. XML-Signature will use the RDF data model [RDF] but need not use
> >>        the RDF serialization syntax. [Charter]
> >
> >Does this mean that XML-Signature will use XML (not RDF) that is modeled
> >such that it translates easily into RDF, but does not actually use RDF?
> >
> >Finally, a minor point, I notice that this workgroup and workproduct is
> >alternatively called Signed XML and XML-DSig.  In light of the requirement
> >that the "solution shall provide indifferently for digital signature and
> >message authentication codes, considering symmetric and asymmetric
> >authentication schemes" it would be clearer to stick with "Signed XML"
> >rather than ". . . DSig" (at least drop the "D") (or change "D" to "E" for
> >Electronic Signature).
> >
> >Thanks,
> >
> >Winchel "Todd" Vincent III
> >Attorney and Technical Researcher
> >Project Director, E-CT-Filing Project
> >Georgia State University
> >J. Mack Robinson College of Business, Center for Digital Commerce
> >and College of Law
> >Phone: (404) 651-4297
> >Fax: (404) 651-2092
> >Email: winchel@mindspring.com
> >Web: http://gsulaw.gsu.edu/gsuecp/
> >
> >
>
>   ------------------------------------------------------------------------
>                     Name: RFC822.TXT
>    RFC822.TXT       Type: Plain Text (text/plain)
>                 Encoding: base64
>              Description:
Received on Friday, 11 June 1999 16:58:11 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:06 GMT