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

Re: XML and canonicalization

From: Donald E. Eastlake 3rd <dee3@torque.pothole.com>
Date: Wed, 27 Oct 1999 21:46:28 -0400
Message-Id: <199910280146.VAA07294@torque.pothole.com>
To: <w3c-ietf-xmldsig@w3.org>
Phil,

From:  "Phillip M Hallam-Baker" <pbaker@verisign.com>
Resent-Date:  Wed, 27 Oct 1999 14:35:48 -0400 (EDT)
Resent-Message-Id:  <199910271835.OAA26286@www19.w3.org>
To:  "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>,
            <w3c-ietf-xmldsig@w3.org>
Date:  Wed, 27 Oct 1999 14:37:00 -0400
Message-ID:  <001e01bf20aa$417b6c00$6e07a8c0@pbaker-pc.verisign.com>
In-Reply-To:  <199910271536.LAA06893@torque.pothole.com>

>> 	If it were practical to always carry along a particular
>> surface representation, there would never have been any pressure to
>> design DER (Distinguished Encoding Rules) which provides a unique
>> external serialization of the true internal ASN.1 data.
>
>Even Steve Kent can probably be made to agree that nobody knows of 
>a system in which X.509 certificates are parsed into components and 
>signatures stored separately and then rebuilt.
>
>Most of the real world certificate applications in the world
>generate DER encoding but accept BER encoding. In fact the number
>of faulty DER encodings is such that if applications were to
>depend on DER encodings they would break.

I never said a word about certificates.  I had nothing to do with the
PKI or certificate part of the SET software I was working on.  When
ever my code got down to certificates or CRLs or BCRLIs, I just called
code designed and implemented by someone else which did all the
certificate parsing and key caching.  In my mesage I talked only about
messages in SET, a reasonable exmple of a complex protocol but using
ASN.1 instead of XML.  Multistage tearing apart and sometimes
decrypting and sometimes verifying parts of requests and multistage
building and signing and encrypting merchant to bank gateway requests
including pieces of the cardholder to merchant messages and reply
messages includes pieces of request message, etc.  The creating, clean
binary channel handling, and processing of certificates is probably
much more like a document application than a protocol application as I
have been using those terms.

>> >Instead of canonicalization, specify a syntax constraint. This might 
>> >state for example that the signed octets presented were presented with
>> >null space eliminated, tags fully epanded and attributes sorted into
>> >alphabetical order.
>> 
>> Yes, you could canonicalize at "print" time rather than at signature
>> and at verification time, throwing away the readability and
>> flexibility of XML.  Of course, nothing that passes the result or
>> verifies the signature could use SAX or DOM unless it was willing to
>> re-canonicalize it (in which case it is unclear what you gained by
>> canonicalizing at print time).  They would have to use proprietary
>> home-brew processing.
>
>I fail to discern any meaning in the above paragraph.

Sorry, I'll try to clarify it.

>For the generator the only constraint imposed by the proposed syntax
>constraint is that it would have to sign and deliver canonical form.

"print" = deliver.  Right, with your proposal, you need XML
canonicalization at the signer.

>'print time'? 'proprietary'? I fail to see any connection to the
>proposal.

See above re print time.  As far as I can tell, the definition of XML
and the actual SAX and DOM interfaces that almost everyone uses will
sometimes break your signer imposed canonicalization and thus break
the signatures unless canonicalization is also implemented at the
verifier.  For soemthing to preserve the canonicalization, it would
have to use some specially crafted parser, which I don't think it is
entirely unjustified to call "home-brew".

>> I haven't the faintest idea why, in such a contentious area, you think
>> this issue was ever closed in this WG.  
>
>When someone starts a post "I have been re-thinking this issue", that
>implies to me that they want to re-open it. 

There were arguments over this previously in this WG.  There wasn't a
consensus on whether a fixed canonicalization algorithm was reasonable
or what the defualt canonicalization algorithm should be for
SignedInfo.  As long as there isn't a WG consensus, the question is
open.  Under these circustances, it seems reasonable for me to think
about it a bit more.  You quote is wrong.  See
<http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/1999OctDec/0148.html>.
I said "I've been mulling this over and studying the standards
starting with the basic XML 1.0 standard."

>However since you then proceeded to make exactly the same argument
>that you did the first time round it was not exactly 're-thinking'. 

I see no reason why mulling over and studying shouldn't end up
confirming a prior opinion.

>If the issue is indeed 'contentious' then it looks a little odd if
>the Working group chair starts staking out such a committed 
>interpretation of it. I take it then that we are agreed that there
>is not a consensus?

Interpretation?  I have a technical opinion.  You have one also.

Consensus?  At this point, I think there is a rough consensus that
Null, Minimal, and at least one XML canonicalization and application
specified canonicalziations should be optionally available for data.
But there isn't a consensus on whether canonicalization can be fixed,
and if so at what, or defaulted, and if so to what, for SignedInfo.

>> I'm sorry that you don't like XML and wish it were a different animal
>> than it is. 
>
>Don, don't try to patronize me. I was using XML before it had a name.
>
>		Phill

Donald
Received on Wednesday, 27 October 1999 21:46:32 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:08 GMT