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.

http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2001AprJun/att-0267/02-SigPorta.html

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.

http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2001AprJun/att-0267/01-CanonMethod.html

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 Tuesday, 12 June 2001 15:57:58 UTC