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

RE: Caononicalization Re: Minutes from Today's Call Please Review/Correct

From: John Boyer <jboyer@uwi.com>
Date: Thu, 26 Aug 1999 11:03:23 -0700
To: "Bob Relyea" <relyea@netscape.com>, "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>
Cc: "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>
Message-ID: <NDBBLAOMJKOFPMBCHJOIGEPDCAAA.jboyer@uwi.com>
<John>
I agree with Don here actually.
Signature verification need know nothing about application semantics.  It
just needs to know the encoding rules, transform rules and canonicalization
rules that were used to create the signed message so that the message can be
recreated for verification.

Disallowing encoding changes after signing is only slightly different from
saying we can't compress the files for transmission over the web.  It makes
no real difference as long as the the bytes that were hashed can be
recovered, and it is still the application that decides the meaning of those
signed bytes once we've been assured that 1) they haven't changed since
signing, and 2) who the signer is.

Also, it should be noted that at least some of the transforms we are talking
about are also applied before signing time.  For example, a manifest that
lists the elements to be signed is really just a special transform on the
total resource (and not logically different from the exclusion lists I'd
like to see).  It is a foregone conclusion that we sign the manifest, so as
a matter of course we should be signing all pieces of information that
necessary to regenerate the message signed.  Application semantics do not
enter the picture.

John Boyer
Software Development Manager
UWI.Com -- The Internet Forms Company
</John>

> From Don: Since signatures are computed over absolute bit(/octet)
> streams, it is necessary to use the encoding that was signed in order
> to verify a signature.  In such cases, either you mandate the
> availability of extra information as to the encoding that was used
> when the signature was generated or you specify a canonicalization
> algorithm that includes encoding into one specific encoding, say
> UTF-8.

From Bob:
So my problem here is in the normal case, once the document is signed, there
should be no transformations. The purpose of digital signatures is to lock
the document in a known static state. The argument that the transformed
document is semantically the same requires applications to agree on the
semantics of the signature itself. The working group has continued to push
off the semantics of the signature to the application. If this is the case,
only the application can choose appropriate c14n algorithms -- and then can
only interoperate with other applications that agree with its definition of
the semantics of the signature.
Received on Thursday, 26 August 1999 14:05:03 GMT

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