Re: Canonicalization

Sorry, I seem to have gotten some of the things you were saying backwards.
My fault...

From:  "Jim Schaad (Exchange)" <jimsch@EXCHANGE.MICROSOFT.com>
Message-ID:  <EAB5B8B61A04684198FF1D0C1B3ACD194A70B4@DINO>
To:  "'Donald E. Eastlake 3rd'" <dee3@torque.pothole.com>
Cc:  "W3c-Ietf-Xmldsig (E-mail)" <w3c-ietf-xmldsig@w3.org>
Date:  Thu, 21 Oct 1999 19:09:25 -0700

>> -----Original Message-----
>> From: Donald E. Eastlake 3rd [mailto:dee3@torque.pothole.com]
>> Sent: Thursday, October 21, 1999 6:32 PM
>> To: Jim Schaad (Exchange)
>> Cc: W3c-Ietf-Xmldsig (E-mail)
>> Subject: Re: Canonicalization 
>> 
>> 
>> 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.
>
>The different prefixes and xmlns declarations are required by the
>canonicalization algorithm and not something that I dreamed up on my own.

Yup, I just went and looked at it.  You're doing what they say, which
is excessively verbose.  If they stick with that, it's a point on
which we can improve.  There is no need to define two different
prefixes for the same namespace at the same element.

>> 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?
>
>If you look, I put Object reference first just because it was going to be
>more likely to change.

OK, I had what you were saying backwards.

>> 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. 
>
>While it is true that a good hash algorithm will have many of the bits
>changed, if you are trying to do an attack you want to make the attacker
>compute the entire hash and not be able to start at the mid point thus
>reducing the work load by 50%.

I don't really see a significant work factor reduction for the public
key case as the signing is orders of magnitude more work than the
hash.  But you may have a point in the keyed hash case.

>> 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.
>
>The original assumption was that you would have the canonization and digest
>algorithm comes first so that you know this as early as possible in order to
>aid in doing the processing while you are parsing.  If you had this last,
>you would need to save the entire item in order to do the processing.

That wasn't my assumption, perhaps others thought that.

 Thanks,
 Donald

>> 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
>> >name="http://www.w3.org/1999/07/WD-xml-CanonicalizationAlg-19
>> 990729"/>
>> >    <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:Cano
>> nicalizationAlg
>> >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:Dige
>> stAlgorithm>
>> >    </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:Dige
>> stAlgorithm>
>> >      <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+NkcGg
>> Wq6PiVxeFDCbJzQ
>> >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 Friday, 22 October 1999 00:04:46 UTC