W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > April to June 2001

Re: Signature Portabilit, CanonicalizationMethod, etc.

From: Donald E. Eastlake 3rd <lde008@dma.isg.mot.com>
Date: Wed, 13 Jun 2001 16:12:04 -0400
Message-Id: <200106132012.QAA02473@noah.dma.isg.mot.com>
To: w3c-ietf-xmldsig@w3.org
cc: lde008@dma.isg.mot.com

From:  "Joseph M. Reagle Jr." <reagle@w3.org>
Message-Id:  <>
Date:  Tue, 12 Jun 2001 15:57:25 -0400
To:  Donald Eastlake 3rd <dee3@torque.pothole.com>
Cc:  w3c-ietf-xmldsig@w3.org, Donald.Eastlake@motorola.com
In-Reply-To:  <3B264654.73760D95@torque.pothole.com>

>At 12:41 6/12/2001, Donald Eastlake 3rd wrote:
>>The second is a replacement for Section 7.3: Namespace Context and
>>Portable Signatures.
>>While I have more or less followed the trend of recent discussion in
>>editing these sections,  the more I think about it the more it seems to
>>me that, unless it mandates the implementation of a canonicalization
>>that substantially divorces the canonicalizaed XML from its context,
>>XMLDSIG fails to provide interoperable signatures for protocol applications.
>What is the proposal? That we delay the advancement of the xmldsig spec for 
>the advancement of a "repulsive canonicalization"? Getting the interop would 
>probably be relatively easy if there's interest -- while Merlin identified 
>the issue I'm not sure how he or other implementors feel, and some kibitzers 
>such as myself feel that enveloping/detachment is up to the enveloping 
>specification! Process wise it would probably take longer, an Informational 
>RFC on the IETF side and a REC on the W3C, just to advance the main spec 
>still. In either case, when I'm not sure it's necessary to be REQUIRED and 
>I'd like the spec to advance this month, I'm not keen to see this delay. How 
>do other people feel?

My words above were not a proposal but an opinion. However, to provide
a specific proposal, I have produced some HTML which I will post
separately. I don't see why what could be considered just an important
tweak to canonicalization can't just be added to the signature spec as
a response to Last Call comments.

I continue to be very leary of thinking that one can just say "cut out
the XML to be canonicalized" to avoid context dependency. XML isn't a
piece of paper you can apply scissors to. Inside an application, XML
is a logical structure.  It may be there is a DOM operation which does
this but that means we are saying that to get interoperable signatures
for protocol cases, people have to implement the DOM data mode. If
people happen to have an XPath data model (seemingly reasonable given
the references to XPath in XMLDSIG), then the work needed to divorce a
node from its context is essentially the same as the additional work
needed for produce a context repeling canonicalizaiton. And I'm
worried that DOM will change towards XPath and someone will find, at
some future time, when they rebuild with the latest DOM, signatures
work locally and they interoperate fine with themselves and they work
fine for documents but when they start trying to interoperate with
protocols with other implementations, suddenly some fraction of
signatures mysteriously break.

From my personal point of view, there are approximately three paths:

1. limit the scope of the document so that it does not claim to
provide interoperable signatures for applications where context can
vary (which is typical of protocol applications)

2. change something so that it does provide such interoperability

3. decide by working group consensus that it's just fine as is and
push it through without either of the above...

>>2. ... While this is simple, it is not, in general, interoperable.
>I don't agree. For example, if you have two implementation of an envelope 
>application, if that application specified how to detach the payload they 
>will interoperate perfectly, right?

Yes, but the interoperability of specific applications that profile
signature does not imply interoperabiilty of signatures.

Interoperability can mean different things. But in the IETF in terms
of protocols, it means that you specify the data bits sent between the
applications and what those bits mean at each end and it all works. If
additional out of band agreements are necessary, then those aspects
which need such agreements are not interoperable. This isn't
necessarily bad. For example, KeyName isn't interoperable. But a
signature standard where signature validation isn't interoperable
doesn't strike me as very useful. There isn't much difference in
principle between saying that entities that want to successfully
exchange signatures need to agree out of band which signed items are
divorced from their context and which aren't (resulting in 2**n
possibilities if n things are signed by the Signature) and saying that
the entities need to agree out of band on all aspects of
canonicalization or agree out of band on all aspects of signature
vertification and generation.

>>3. The SignedInfo element presents a special problem
>>which distinguishes it from general XML data. Due to the sensitivity
>>of SignedInfo, Transform operations over
>>it are not provided, only CanonicalizationMethod, and great
>>care must be taken to only use safe caonicalizations of SignedInfo.
>I'm not sure this is necessary. This spec is supposed to be relatively 
>mature and we decided not to do transforms (and this isn't an application 
>has an option for) so I don't see a requirement to introduce that issue.

If you just want to trim down the verbiage, that's fine. Perhaps
the above should have been as follows, especially with the addition
of material in the CanonicalizationMethod section about why you
should only use safe canonicalizations of SignedInfo:

       "3. Transform operations are not provided for SignedInfo so
        protection of it from context must be indicated by a
        CannonicalizationMethod algorithm. ...

>>One is a replacement for Section 4.3.1: The CanonicalizationMethod
>>Element. It adjusts it for the removal of MinimalCanonicalization from
>>the document and has an added security warning about allowing arbitrary
>>CanonicalizationMethod functions.
>1. This text was "adjusted" for removal of minimal but still needs to speak 
>of what to do for character based canonicalization methods. Even though we 
>don't specify one, they can be used and in either case we have to say how 
>the SignedInfo element is presented to that algorithm as characters or nodes.

Well, there may be character based canonicalizations and its
reasonable to say that they take a UTF-8 octet string as input.

[It continues to be my belief that "character based canonicalization"
of SignedInfo is fundamentally wrong and that such applications are
not XML applications.  No particular character string is ever XML
within an application, althogh it can be an external representation of
XML.  The XML standard makes it clear that XML within an application
is a logical structure which includes inherently unordered sets and
the like.  Applications which do not implement the XML 1.0 standard
but instead read in and manipulate SignedInfo as a character string
are not, for this facet of their behavior, XML applications.]

>2. On the cautionary NOTE, I think this text is valuable and reminds me of 
>the text found in the processing rules which explains why you should 
>canonicalize your references before validating them as the canonicalization 
>method could've changed them. So I made some links between this text.

OK, sounds like a good idea.

>3. (Editorial: Not sure adding "Although technically outside" to the 
>(previously) last paragraph adds anything but verbosity. We can lowercase 
>the RECOMMEND if you want.)

I don't really care... I suppose it should be lower case.

>Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
>W3C Policy Analyst                mailto:reagle@w3.org
>IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature
>W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/

Received on Wednesday, 13 June 2001 16:12:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:10:05 UTC