RE: Canonicalization

This is the kind of statistic that lends credence to having a decompression
transform available.

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


-----Original Message-----
From: w3c-ietf-xmldsig-request@w3.org
[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Jim Schaad
(Exchange)
Sent: Thursday, October 21, 1999 4:07 PM
To: W3c-Ietf-Xmldsig (E-mail)
Subject: Canonicalization


I was playing around looking at the canonicalization and put together this
example:  (Don't pretend that the acutal structure of the source is correct.

This source ---
------------------------------------------
  <SignInfo>
    <CanonicalizationAlgorithm
name="http://www.w3.org/1999/07/WD-xml-CanonicalizationAlg-19990729"/>
    <SignatureAlgorithm name="urn:rsasdi-com:rsa">
      <DigestAlgorithm name="urn:nist-gov:sha1"/>
    </SignatureAlgorithm>
    <ObjectReference>
      <Location HREF="sha-testcase-1"/>
      <DigestAlgorithm name="urn:nist-gov:sha1"/>
      <DigestValue
encoding="urn:dsig:base64">qZk+NkcGgWq6PiVxeFDCbJzQ2J0=</DigestValue>
    </ObjectReference>
  </SignInfo>
-----------------------------------------

Is going to be encoded as

--------------------------------------------
  <n1:SignInfo xmlns:n1="http://www.w3.org/1999/10/signature-core">
    <n1:CanonicalizationAlgorithm
xmlns:n1="http://www.w3.org/1999/10/signature-core"
n2:name="http://www.w3.org/1999/07/WD-xml-CanonicalizationAlg-19990729"
xmlns:n2="http://www.w3.org/1999/10/signature-core"></n1:CanonicalizationAlg
orithm>
    <n1:SignatureAlgorithm
xmlns:n1="http://www.w3.org/1999/10/signature-core"
n2:name="urn:rsasdi-com:rsa"
xmlns:n2="http://www.w3.org/1999/10/signature-core">
      <n1:DigestAlgorithm
xmlns:n1="http://www.w3.org/1999/10/signature-core"
n2:name="urn:nist-gov:sha1"
xmlns:n2="http://www.w3.org/1999/10/signature-core"></n1:DigestAlgorithm>
    </n1:SignatureAlgorithm>
    <n1:ObjectReference xmlns:n1="http://www.w3.org/1999/10/signature-core">
      <n1:Location xmlns:n1="http://www.w3.org/1999/10/signature-core"
n2:HREF="sha-testcase-1"
xmlns:n2="http://www.w3.org/1999/10/signature-core"></n1:Location>
      <n1:DigestAlgorithm
xmlns:n1="http://www.w3.org/1999/10/signature-core"
n2:name="urn:nist-gov:sha1"
xmlns:n2="http://www.w3.org/1999/10/signature-core"></n1:DigestAlgorithm>
      <n1:DigestValue xmlns:n1="http://www.w3.org/1999/10/signature-core"
n2:encoding="urn:dsig:base64"
xmlns:n2="http://www.w3.org/1999/10/signature-core">qZk+NkcGgWq6PiVxeFDCbJzQ
2J0=</n1:DigestValue>
    </n1:ObjectReference>
  </n1:SignInfo>
---------------------------------------------

In this example, the first 62% of the document (roughly 840 characters) is
the same for all signed messages. (This assumes that the same
canonicalization and signature algorithm are routinely used.)  This means
that the data that changes from message to message is not contriubuting as
much to the hash computation as it could. I would like to fight this by
changing the order of the fields in signed info to

ObjectReferece, CanonicalizationAlgorithm SignatureAlgorithm

I don't believe this will hurt any implemenations as I do not believe that
one pass parsing and signature evalution is possible in XML and this
significantly improves the hash as you cannot preload 50% of the hash
computation.

jim

Received on Thursday, 21 October 1999 19:24:02 UTC