Re: Minutes from Today's Call Please Review/Correct

Although it may be convenient to split things into a parameterless
canonicalization algorithms and parameter taking transformation
algorithm, the combined effect of these is precisely canonicalization,
ie, the deliberate discarding of some parts and/or representational
artifacts to get to the true essence you want to sign.

Donald

From:  "John Boyer" <jboyer@uwi.com>
To:  "Phillip M Hallam-Baker" <pbaker@verisign.com>,
            "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>
Date:  Fri, 20 Aug 1999 11:15:41 -0700
Message-ID:  <NDBBLAOMJKOFPMBCHJOICENCCAAA.jboyer@uwi.com>

>Hi Phillip,
>
>Although putting an exclusion list in the canonicalizer element is an
>interesting idea, it is certainly not the only place to put it.  I sent a
>write-up to Joseph with several alternatives, which he said would soon be
>added as a comment to requirement 3.1.3.
>
>Most compelling is the idea of adding an exclude element to the resource
>element.  So, in addition to a Locator, you would have a list of sub
>locators (XPointers, identifiers, ?) that would specify the parts of the
>document to drop out of the construction of the message to be hashed.
>
>If c14n is optional, then I'd definitely like to keep c14n separate from the
>need to indicate exclusions because I think the latter is mandatory if
>signing partial XML is a requirement (which it currently is).  Please see
>[1] and [2] for why.
>
>[1]http://www.w3.org/Signature/Drafts/xmldsig-scenarios-990818.html
>[2]http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/1999JulSep/0193.html
>
>Also, I'd like to reiterate that the implementation of an exclusion list is
>quite a simple programming task.  It would take less work to build one than
>it would to construct a convincing case that this would seriously impact an
>implementation timeline.  Even if one wasn't originally planning to procure
>and use an XML parser, there exist ones which are free, easy to work with,
>and very small (Clark's parser is an example).
>
>Finally, as to whether or not the thing we are talking about is a c14n
>algorithm, I agree that it is not, so c14n is not really the best place to
>put it anyway.  The canonical form of an object is a particular logically
>equivalent representative, whereas when we try to define which subelements
>to exclude, we are really talking about a way of specifying a different
>object (the element without certain descendants).  This is why I like the
>exclude list better in the resource (or somehow wrapped up in the syntax of
>a Locator itself).  Still, Brown suggested the possibility of putting it
>somewhere, anywhere, and that was a good enough start for me.
>
>John Boyer
>Software Development Manager
>UWI.Com -- The Internet Forms Company
>
>
>-----Original Message-----
>From: w3c-ietf-xmldsig-request@w3.org
>[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Phillip M
>Hallam-Baker
>Sent: Friday, August 20, 1999 10:44 AM
>To: Joseph M. Reagle Jr.; IETF/W3C XML-DSig WG
>Subject: RE: Minutes from Today's Call Please Review/Correct
>
>
>>             Removing selections of XML. Should the ability to
>>             preclude sections be a mandatory to implement
>>             feature/requirement of selection/c14n.
>
>Since it has already been agreed by the group that C14N
>is OPTIONAL it cannot be part of a mandatory to implement
>section.
>
>I already have XML signature applications being specified.
>I want to align them with the spec as soon as possible. I
>do not want to be forced to wait for the outcome of the
>C14N discussions to terminate before I can do this.
>
>I have no technical requirement for C14N and plenty of
>reasons to avoid it, not least the fact that like
>compression, C14N is a likely target of patents filed
>with corrupt intent.
>
>
>I know some people in the group believe that they must
>have C14N but they have already agreed that they will not
>force this requirement on others.
>
>If the overhead of XML signatures exceeds that of CMS it
>has lost all value for me.
>
>		Phill
>

Received on Monday, 23 August 1999 11:01:21 UTC