Re: Chair Request: Final Comments Submissions to RD

Dear Richard,

It is a pleasure to hear from you again.

W.R.T. whether base 64 is 'good-enough', there are two reasons why signing
the base 64 is in fact sufficient.

1) There is a well-known and documented bijection between binary and base 64
[1].  In other words, every binary document is expressible by a base 64
encoding that is unique to that document.  There is no ambiguity of
translation.  To wit, we take a far greater security risk in accepting a
hash of the document as the signature.

[1] N. Freed & N. Borenstein.  Multipurpose Internet Mail Extensions (MIME)
Part One: Format of Internet Message Bodies.  Innosoft, First Virtual, Nov.
1996.  Available at:  http://ds.internic.net/rfc/rfc2045.txt

2) It is inconsistent to say that a signature on a lossless translation of a
document is unacceptable but a signature on the 'original' image or PDF
format is acceptable.  The reason is that the image format and the PDF
format are themselves translations of what the user was actually looking at
when he/she committed to the document.

Compared to decompressing a PNG, the base 64 translation is quite simple.  A
PDF document (or Word, Excel, etc., which were Todd's concern) are simply
binary instructions that tell a very complex black box interpreter how to
draw a bitmap.  Consistent closure on a restriction to the 'original'
document would mandate that the only thing we can sign is a bitmap of the
screen that the user viewed. Of course, this negates signing XML itself, and
hence should not be a requirement of the signed XML specification.

In the end, it is still your application's choice as to whether you permit
base 64 encoded blobs.  However, if you intend to enclose PDF documents,
images and so forth in your XML document, then you are forced to endure some
form of encoding (escaping with entity refs) because XML itself has
restrictions on content.

If your application has a requirement for the completely unadulterated
version of a subdocument such as an image, PDF or Word document, then it mus
t reside outside of the main XML document.  The Brown IETF draft also
accounts for this.

The requirement to enclose other documents within a given XML document is an
application requirement that can be satisfied by XML itself using base 64 or
normal XML escaping techniques.  The requirement to associate other
documents with an XML document is satisfied by XLink.  The only thing a
signed XML requirements document should do is to say that we require the
ability to sign internal and external resources, which is stated in 3.a.4.

John Boyer
Software Development Manager
UWI.Com -- The Internet Forms Company
jboyer@uwi.com


-----Original Message-----
From: Richard Himes <rhimes@nmcourt.fed.us>
To: w3c-ietf-xmldsig@w3.org <w3c-ietf-xmldsig@w3.org>
Date: Friday, June 11, 1999 1:59 PM
Subject: Re: Chair Request: Final Comments Submissions to RD


>
>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 17:49:11 UTC