RE: Canonicalization

> -----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.

> 
> 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.

> 
> 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%.

> 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.

> 
> 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 Thursday, 21 October 1999 22:09:29 UTC