- From: Donald E. Eastlake 3rd <dee3@torque.pothole.com>
- Date: Tue, 05 Sep 2000 02:22:36 -0400
- To: w3c-ietf-xmldsig@w3.org
- cc: Donald.Eastlake@motorola.com
August 31, 2000, Teleconference notes On call: D. Eastlake, Ed Simon, Brian Lammachia, Merlin Hughs, Ken Goldman, John Boyer Canonicalization: There was considerable discussion of the recently posted different method for handling namespaces in canonicalization. In brief, this new method imports the total namespace context only into the top level element of the canonicalized XML and removes redundant namespace declarations internal to this XML. This means that, in general, the canonical form of a subelement of some canonical XML is different from the form of that subelement in the original canonical XML. There was a mildly favorable reaction to this change but some withheld their opinion pending attempting to actually implement it. There was some discussion of continued unhappiness with treating all whitespace as significant. This is still causing some difficulties with the library the Microsoft implementation is based on. However, no one proposed a good solution. You either have to assume validating parsing of all digested XML or treat white space as insignificant, which can be unsafe, to avoid the current treatment of all white space as significant. Comments are still optionally eliminated canonicaliztion, including minimal canonicalization. RSA Signature Format: URIs to identify wrapping of the Signature? include OIDs? Inclusion of the algorithm OIDs within the secured potion of the signature is needed for security. No one saw any reason to include plain text OIDs outside that area. The current specification that such an OID prefix is included should be dropped. here(): The change in the transform model eliminates the problem with here because it is no longer just an octet stream that is input to a transform. It can be a node set resulting from a URI or fragment. xml:base [my notes here seem a bit obscure but basically there wasn't any change in the situation as recently discussed] Raw X.509 Cert Type: The consensus on the call was that adding a RetrievalMethod Type for a binary X.509 certificate was a good idea. It was also clarified that the Type should specify the type of the data AFTER application of the transforms. So, for example, one could retrieve a plain Base 64 encoded certificate and use it with this type by providing a Base 64 decode transform. There was a consensus on the call that we should have one or two more calls. Thanks Donald ===================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 140 Forest Avenue +1 978-562-2827(h) Hudson, MA 01749 USA +1 508-261-5434(w)
Received on Tuesday, 5 September 2000 02:19:38 UTC