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

Re: Chair Request: Final Comments Submissions to RD

From: John Boyer <jboyer@uwi.com>
Date: Fri, 11 Jun 1999 10:53:32 -0700
Message-ID: <000f01beb433$5251fff0$9ccbf4cc@kuratowski.uwi.bc.ca>
To: "Winchel 'Todd' Vincent, III" <winchel@mindspring.com>
Cc: "Dsig group" <w3c-ietf-xmldsig@w3.org>
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

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

-----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.
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
>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
>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
>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
>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).
>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/
Received on Friday, 11 June 1999 13:51:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:09:55 UTC