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

Re: Canonicalization

From: Donald E. Eastlake 3rd <dee3@torque.pothole.com>
Date: Thu, 21 Oct 1999 21:32:01 -0400
Message-Id: <199910220132.VAA31428@torque.pothole.com>
To: "Jim Schaad (Exchange)" <jimsch@EXCHANGE.MICROSOFT.com>
cc: "W3c-Ietf-Xmldsig (E-mail)" <w3c-ietf-xmldsig@w3.org>
Hi Jim,

Seems like a good argument for a shorter namespace URI, like
"http://w3.org/sig-v1".  And I don't think different prefixes and
xmlns declarations are reasonable for the identical namespace.  But
this is just a matter of degree.

I have no problem with re-ordering fields to maximize data that would
be static for many applications at the front.  But it seems to me that
is already is, with canonicalization algorithm and signature algorithm
first.  Wouldn't Object Reference be more likely to change?

There are two of your remarks I don't understand.  One is about
contribution to the hash output.  Surely any good hash function should
have the characteristic that changing any bit of the input changes
about half the bits of the output.  It makes no different if it is the
first or last or a middle bit you change...every byte of input has an
equal effect on the output so it does not matter where a relatively
static area of data is. The second is that I don't see what the
reordering has to do with one pass processing.  If we want one pass
processing I would think it would be via a special element (I guess
I'm not supposed to the Processing Instruction) so I don't see how
SignedInfo element order would effect it.


From:  "Jim Schaad (Exchange)" <jimsch@EXCHANGE.MICROSOFT.com>
Resent-Date:  Thu, 21 Oct 1999 19:07:06 -0400 (EDT)
Resent-Message-Id:  <199910212307.TAA25082@www19.w3.org>
Message-ID:  <EAB5B8B61A04684198FF1D0C1B3ACD194A70AF@DINO>
To:  "W3c-Ietf-Xmldsig (E-mail)" <w3c-ietf-xmldsig@w3.org>
Date:  Thu, 21 Oct 1999 16:06:57 -0700

>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
>    <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
>    </ObjectReference>
>  </SignInfo>
>Is going to be encoded as 
>  <n1:SignInfo xmlns:n1="http://www.w3.org/1999/10/signature-core">
>    <n1:CanonicalizationAlgorithm
>    <n1:SignatureAlgorithm
>      <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"
>      <n1:DigestAlgorithm
>      <n1:DigestValue xmlns:n1="http://www.w3.org/1999/10/signature-core"
>    </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
Received on Thursday, 21 October 1999 21:32:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:32 UTC