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

RE: Signature Portability, CanonicalizationMethod, etc.

From: Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com>
Date: Wed, 13 Jun 2001 14:25:23 -0400
Message-ID: <1DE737930E15D511B64400D0B76FE2620C0C72@ma07exm01.corp.isg.mot.com>
To: "'Mark Bartel'" <mbartel@thistle.ca>, "Joseph M. Reagle Jr." <reagle@w3.org>
Cc: w3c-ietf-xmldsig@w3.org, Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com>
I see 3.2, item 3, of the requirements as a requirement that XMLDSIG support protocol applications. While XML calls all XML objects "documents", I agree that XMLDSIG as it currently stands reasonably supports "documents" in the everyday sense of constructs similar a piece of paper whose context does not change and signatures and seals are added at the bottom. But your typical protocol application is not like that. It is normal for protocol messages to contain multiple independent items and signatures, multiple levels of hierarchy, to be enclosed within other protocols and/or to have other protocol messages enclosed within them, etc.

I'm working on a complete proposal for what I think should be done but another possibility is to just say that XMLDSIG provides interoperable signatures only for instances where the signature context does not change and that the signatures it provides do not interoperate where signature context changes in the absence of additional out-of-band application level agreements. I would prefer not to have to say that.


------Original Message-----
From: Mark Bartel [mailto:mbartel@thistle.ca]
Sent: Wednesday, June 13, 2001 11:11 AM
To: Joseph M. Reagle Jr.; Donald Eastlake 3rd
Cc: w3c-ietf-xmldsig@w3.org; Donald.Eastlake
Subject: Re: Signature Portabilit, CanonicalizationMethod, etc.

I think there might be some disagreement about what interoperable is meaning here... I agree with Donald that there is a serious issue with composition here, but if you view interoperability narrowly, in that a signature in document X can be verified by several independent implementations, then the problem is not one of interoperability.

I personally think that it would be highly desirable to be able to define a document format that encapsulates another document format, ie. given a (non-negotiable) document format for app Y that looks like


I can define my own schema for app Z that contains such a document as a subelement as in


and have any signatures in <A> still be verifiable without having to isolate the <A> element. I would personally call this an interoperability issue, but strictly speaking it is a composition issue, and I'm not sure this type of composition is mandated by the requirements [1] (see #3).

I'm thinking that A is something like SVG, something generic that many applications might wish to encapsulate.


-Mark Bartel
JetForm Corporation

----- original message -----
From: "Joseph M. Reagle Jr." <reagle@w3.org>
Sent: 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
Subject: Re: Signature Portabilit, CanonicalizationMethod, etc.

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?

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

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

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

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 14:25:32 UTC

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