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/

Received on Friday, 11 June 1999 13:16:46 UTC