RE: SignedInfo c14nAlg

I think Don is absolutely right.  If one is signing XML content
that is meant to be understood and processed at the XML level,
one needs to use an XML-aware canonicalization algorithm.

I know I'm risking raising this subject too many times but
here goes again in detail.

Suppose you have some XML content, e.g.

<Cheque xmlns:directory="http://www.directories.r.us.com">
<directory:To>Alice Apple</directory:To>
<directory:From>Bob Banana</directory:From>
<Amount currency="dollars" country="Canada">100.00</Amount>
</Cheque>

For processing purposes, the above XML content could be
equivalently expressed as

<Cheque xmlns:whoswho="http://www.directories.r.us.com">
<whoswho:To>Alice Apple</directory:To>
<whoswho:From>Bob Banana</directory:From>
<Amount
country="Canada"
currency="dollars">100.00</Amount>
</Cheque>

Note the changes to namespace, order of attributes, and intra-element
whitespace.  Running a hash algorithm over the two instances would
result in different hashes.  This is alright if you care about each byte
but problematic if you only care at the XML level.
It is problematic because at the XML-level, the two ways of expressing
the <Cheque> element are equivalent; there is no change in the XML
semantics.  To me, the <SignedInfo> element is one type of XML content
that we need to canonicalize at the XML level rather than at just the
byte/character level.

Hence, I strongly favour a DOM canonicalization approach designed
with the principles like those expressed in the DOMHASH Internet
Draft
("http://www.ietf.org/internet-drafts/draft-ietf-trade-hiroshi-dom-hash-03.t
xt").

Using DOM canonicalization, one wouldn't get the false negatives
that would likely occur using lower forms of canonicalization.

Note: I have no problem supporting null and minimal canonicalization
methods for the content of <Transformation> elements.

Ultimately, the question ultimately comes down to whether we
want

<Signature xmlns:dsig="http://www.w3.org/Signature">
<SignedInfo>
<SignedAlg dsig:algorithm="rsaWithSHA-1" version="1.0"/>
<ObjectReference>...</ObjectReference>
<SignatureValue dsig:encoding="base64">abc123def</SignatureValue>
<KeyInfo><KeyName>Solo</KeyName></KeyInfo>
</Signature>

and

<Signature xmlns:xmlsig="http://www.w3.org/Signature">
<SignedInfo>
<SignedAlg         version="1.0"           xmlsig:algorithm="rsaWithSHA-1"/>
<ObjectReference>...</ObjectReference>
<SignatureValue xmlsig:encoding="base64">abc123def</SignatureValue>
<KeyInfo><KeyName>Solo</KeyName></KeyInfo>
</Signature>

to be equivalent.  Note that only the namespace, intra-element
whitespace and attribute order are different.  The content
of <SignatureValue> remains the same in both (as it should)
despite the XML surface string differences.

Ed

-----Original Message-----
From: Donald E. Eastlake 3rd [mailto:dee3@torque.pothole.com]
Sent: October 8, 1999 12:46 AM
To: w3c-ietf-xmldsig@w3.org
Cc: dee3@us.ibm.com
Subject: SignedInfo c14nAlg



The latest draft tweak required the SignedInfo c14nAlg element to be
present.  The more I think about this the more I think that rather
than being mandatory, this element should just be eliminated.  We know
and are specifying the syntax and processing of SignedInfo.  I see no
reason not to just specify thorough canonicalization, such as "DOM
Canon".  True, this is not necessary in some benign environments.  In
some static binary clean environments, you might even be able to get
away with Null canonicalization of SignedInfo.  But we know and are
specifying enough about SignedInfo that we can assure that thorough
canonicalization will not hurt Signatures now or in the future.  And
such canonicalization might be necessary to make some signatures
robust enough to not break when they are processed through more
obstreperous environments.  In other words, I don't see enough of a
downside to make it worth the additional complexity of having to
specify the SignedInfo c14nAlg.

Thanks,
Donald
=====================================================================
 Donald E. Eastlake 3rd   +1 914-276-2668     dee3@torque.pothole.com
 65 Shindegan Hill Road, RR#1  +1 914-784-7913(work)  dee3@us.ibm.com
 Carmel, NY 10512 USA

Received on Friday, 8 October 1999 12:10:33 UTC