W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > July to September 2000

Re: New proposed fix for here()

From: Donald E. Eastlake 3rd <dee3@torque.pothole.com>
Date: Thu, 17 Aug 2000 09:06:31 -0400
Message-Id: <200008171306.JAA15853@torque.pothole.com>
To: "Martin J. Duerst" <duerst@w3.org>
cc: XML <w3c-ietf-xmldsig@w3.org>

From:  "Martin J. Duerst" <duerst@w3.org>
Message-Id:  <>
Date:  Wed, 16 Aug 2000 09:27:46 +0900
To:  Kevin Regan <kevinr@valicert.com>, John Boyer <jboyer@PureEdge.com>,
            Petteri Stenius<Petteri.Stenius@done360.com>,
            "'merlin'" <merlin@baltimore.ie>
Cc:  XML <w3c-ietf-xmldsig@w3.org>
In-Reply-To:  <27FF4FAEA8CDD211B97E00902745CBE201AB43F6@seine.valicert.co

>I have a somewhat similar feeling than Kevin, but on a
>slightly higher level. Transforms in many cases are
>defined by an input octet stream as a parameter, but
>I think it's impossible to work with a model that limits
>parameters to transforms to a fixed list. As an example,
>many transforms need a character encoding ('charset')
>as an input parameter, others may need other parameters.
>If the model is written in a way that gives the impression
>that the list of parameters is closed, and implementations
>are built on that assumption, these implementations will
>run into problems sooner or later.
>So I would advise to: 1) Make clear that there can be
>more parameters, depending on the transform. 2) For

There is a general framework for the inclusion of arbitrary additional
explicit paramters to algorithms, including transforms, as described
in section 6.1.

>the enveloped signature transform, make clear that
>there is an additional parameter that identifies where
>the signature is. It may not be necessary to define
>a representation for this parameter, that may be left
>to implementations.

If left to implementations, it would be completely non-interoperable.

>In other words, tell people that something close to
>a hack may be needed, but don't try to tell them how
>to hack :-).
>Regards,  Martin.
>At 00/08/15 14:15 -0700, Kevin Regan wrote:
>>I did like the fact that XPath was not required in order to implement
>>canonicalization or the enveloped signature transform.  If I remember
>>correctly, XPath was introduced for canonicalization and the enveloped
>>signature transform as a convenient way of expressing those transforms.
>>It seems regrettable that a syntax introduced to express those
>>is now "taking over" the transforms and becoming "required" in the sense
>>that if XPath is not implemented, then enveloped signatures will not
>>be possible (this would seem to suggest that XPath was not an adequate
>>means of describing the enveloped signature transform).

Received on Thursday, 17 August 2000 09:03:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:34 UTC