Introduction: Winchel Vincent + XMLDSIG Position

I am Winchel “Todd” Vincent, an attorney and technical researcher working on
an electronic court filing project at Georgia State University.  I apologize
for the tardiness of this introduction and (what I hope Joseph will accept
as a) position paper.  A combination of nearly three weeks of business
travel in the past month have kept me very busy.

The following is (1) a short background of Georgia State University’s
electronic court filing project (2) a statement of my background, interests
and potential for contribution (3) a statement of my limitations and (4) a
position regarding XML-DSIG goals/requirements.

GEORGIA STATE UNIVERSITY ELECTRONIC COURT FILING PROJECT

GSU’s E-CT-Filing project began in late 1997 as state pilot project for the
purpose of applying digital signature technology to government applications.
GSU’s Colleges of Law and Business partnered to complete the project.  We
choose electronic court filing because the application seemed natural in
view of the College of Law’s participation.

Very quickly, we realized that the creation of an electronic court filing
system required the resolution of multiple issues beyond the use or non-use
of digital signatures.  One of the more significant issues is the “document
format” issue.  There is a many-to-many relationship between courts and
lawyers.  As a result, courts and lawyers need to standardize on a common
document format in order to efficiently pass documents between multiple law
offices and courthouses.  Law offices are split about 50-50 in the use of
either Word Perfect (various versions, usually older version) and Microsoft
Word (usually newer versions).  Courts are similar.  At present, it appears
that many courts will require the filing of PDF documents, since this will
obviate the need to mandate a particular version of MS Word or Word Perfect.

PDF, of course, is not an elegant means of passing information.  The
prospect of an industry-accepted Legal XML standard is much more elegant.
The problem: creating the standard.

Over the past year and a half the GSU project has advocated the creation and
use of industry-standard legal SGML or XML DTDs.  In November 1998, GSU
began hosting the Legal XML Workgroup on a university listserve.
Presently, our numbers are around 40-45 and are growing.  We are partnered
in our efforts with FindLaw (www.findlaw.com).  FindLaw maintains a Legal
XML web site (www.legalxml.org).  Other information can be found on GSU’s
E-CT-Filing web site (http://gsulaw.gsu.edu/gsuecp/).  More information is
available on a password protected website.  Contact me if you would like to
join the list and have access to the password protected website.

MY BACKGROUND, INTERESTS AND POTENTIAL FOR CONTRIBUTION

I am a lawyer . . . which usually receives a cheerful “boo . . . hiss” from
technical folks . . . but would note that, while I do not have a technical
degree, I began programming in Basic and Pascal in eighth grade.  I continue
to do technical work and some programming using various databases, HTML,
Perl, some Java and Visual  Basic, and XML.  Additionally, the GSU
E-CT-Filing project is currently using commercial software to implement a
pilot PKI for use with a prototype electronic court filing system.

On the legal side, I am co-author and reporter of the National Automated
Clearing House’s  CARAT Certificate Policy Guidelines, I recently
co-authored amendments to Georgia’s Electronic Records and Signatures Act, I
played a nominal part in Senator Abrahams recently introduced Millennium
Digital Commerce Act (of which I do not necessarily approve), and I have
participated in the National Conference of Commissioners on Uniform State
Law drafting of its Uniform Transaction Act (of which I do not necessarily
approve).  (all of the above have something to do with the legal effect and
validity of electronic records and signatures and/or digital signatures)

A combination of both legal and technical skills, I hope, will allow me to
bring a unique perspective to the creation of technical standards for
signing XML documents.

LIMITATION TO MY CONTRIBUTION

While a combination of legal and technical skills may allow me to bring a
unique perspective to this effort, it is also a limitation.  My technical
knowledge is not nearly as advanced as many, if not all, of the people on
this list.  As a result, I ask for your patience and careful explanation if
and when I do not entirely grasp a technical issue.

POSITION ON XML-DSIG

The Legal XML Workgroup is beginning to formulate a methodology for
structuring and organizing our mark-up.  I have been using the following
metaphor to explain our methodology:  “skeleton”, “meat”, “brains”, and
“skin.”

SKELETON: There are various types of legal documents within the legal
domain: legal letters, contracts, court filings, statutes, law reviews and
journals, legal books, and treaties.  Each of these document classes has a
unique structure (the relationship of captions, titles, headings,
paragraphs, signature blocks, etc.).  Such structure exists because of the
type of information in each document, the purpose of the document,
tradition, etc. and we cannot expect to change the structure – lawyers would
rebel if certain documents did not continue to look (more or less) as they
do on paper when created electronically.  Accordingly, there is general
agreement in our group that different DTDs or namespaces within the legal
domain should be created for the structure of each document class.

MEAT: Within the legal industry, just as in any industry, there is a unique
vocabulary.  Much of this vocabulary is not (or should not be) specific to
any type of legal document.  For instance, the notion of <Jurisdiction> in a
court filing must not, and probably should not, be different than the notion
of <Jurisdiction> in a contract or a treaty.  Furthermore, certain non-legal
elements, such as <Name> and <Address>, can be expected to be found in all
types of legal documents.  In the Legal XML Workgroup we have been referring
to both legal and non-legal, non-structural elements as “semantic” elements
(whether or not this is “correct” use of “semantic”, this is what we have
been calling it).  “Semantic” elements are the “meat” on the various
“skeletons.”

BRAINS:  Although we have not reached consensus, there are some in the Legal
XML Workgroups (myself included) who see the need for “header” information
for legal documents.  Header information might include various types of
information, including but not limited to (1) routing or workflow
information (2) information about authorship, revision history, etc. and (3)
summary or bibliographic information.

SKIN: Legal documents must be signed and/or kept confidential.  There is a
need, therefore, for digital signatures and encryption (sealed digital
envelope).  The digital signature and/or digital envelope is the “skin” that
holds the “skeleton”, “meat” and “brains” together.

The Legal XML Workgroup would like to leverage on the work of a larger
community of “skin” developers.  We would also like to contribute to such
work.  It is my position that an XML-Digital Signature specification can be
and should be developed that is generic enough so that XML documents (or
BLOBS) from any industry can be digitally signed and/or encrypted.  The
following is a list of desired requirements:

1. Generic (usable by any industry)
2. Non-Proprietary
3. Digital Signature and Digital Envelope (encryption)
4. Signature of and Envelope around both XML and BLOBs (MIME types)
5. For XML Documents, Co-Signature of Entire Document, Request
Authorization: Signature of (Signature + Additional Content), Endorsements
6. Multiple Document Signing (regardless of whether documents are XML, BLOB,
or combination of both)
7. Time Stamps
8. WYSIWYG-capable Signatures and Envelopes

By WYSIWYG-capable Signatures and Envelopes I am referring to what appears
to be one of the most important issues/obstacles (assuming I understand
correctly) – XML Canonicalization Requirements or the lack thereof – the
ability to digitally sign XML elements/trees (as opposed to the byte-stream)
while assuring that what has been signed accurately represents all of the
information the signer viewed through the GUI.

Here is a legal perspective:

When a lawyer introduces and signed paper document in court claiming that it
is attributable to a purported maker, the lawyer, as a threshold matter,
must “authenticate” the document.  For instance, under Federal Rules of
Evidence 901(a), “The requirement of authentication or identification as a
condition precedent to admissibility [of a signed document, among other
things] is satisfied by evidence sufficient to support a finding that the
matter in question is what its proponent claims.” What this means,
basically, is that the lawyer “lays a foundation” – says some magic words –
that gives everyone in the courtroom a warm fuzzy feeling that the evidence
is what he says it is.  This is a very low threshold.  At the culmination of
laying a foundation, the lawyer generally shows the document to the witness
who states in open court either “Yes, this is the unaltered document and
this is my genuine signature” or “No, this document has been altered and/or
it is not my signature.”

In the former case, there is no problem, the document is admitted and the
case goes on.

In the latter case, where the witness denies the document or the signature,
the proponent of the document has the burden of proving that the document
and the signature are unaltered and authentic.  This requires much more
proof and takes time and money.

Why does it matter?

Imagine the difficulty that a lawyer will have if the witness does not
recognize the document at a glance – that is, the content within XML tags is
unaltered, the digital signature is valid, but a different style sheet is
used that makes the document look different – big problem.

What happens if it comes to light during a trial that a document author
inserted comments between XML tags, but that those comments were omitted
during the signing process.  If the comments are relevant (possibly even if
they are not, since they are absent and/or reputable), then there is a big
problem.

Or, alternatively, what happens if it comes to light that the application
(not the author) inserted and signed comments and or “header” information of
which the author was unaware.  Now we have additional information that could
cause problems.

Please understand, I cannot say in any of the above cases that the evidence
is completely worthless (the law has few, if any, binary answers), because
it probably won’t be deemed completely worthless.  However, little
peculiarities in how the technology works will give lawyers the ability to
argue for or against the credibility of the evidence.  If it is perceived by
users that a particular technology is subject to legal arguments against it,
the technology will not be used.

As a general matter, it is safe to say that what a document author/signer
writes and/or sees when he/she signs is what should be signed because what
is seen/read is that for which the person will be held legally accountable.
The technology should not produce inconsistent results based on random
applications – whether this can/should be prevented by technology or by
policy, I’m not yet sure, but I believe strongly that WYSIWYG is an
important requirement.

Some general principles:

If an author writes a comment, then the comment should be signed.

If a graphic or other object (spreadsheet, chart) is included (seen) in a
document, it should be signed.

Dynamic content should be signed.

If a link is included in a document, then the text of the link should be
signed.  The default should be that information on the other side of the
link should not be followed and signed, unless the author chooses to
incorporate the other information.  This is not a perfect rule (because the
information on the other side may be important and there is no guarantee
that the information will remain available, but it does take care of the
www.yahoo.com problem and it gives the author/signer control of what he/she
signs – i.e., to what he/she is legally bound.)

This one won’t be popular, but style sheets should be signed.

I’m not sure about general entities.  I need to see more examples.

Again, I apologize for the tardiness of this reply.

Winchel "Todd" Vincent III
Attorney and Technical Researcher
Georgia State University
The 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 Monday, 12 April 1999 12:20:25 UTC