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

minutes of 31 August 2000 Teleconference

From: Donald E. Eastlake 3rd <dee3@torque.pothole.com>
Date: Tue, 05 Sep 2000 02:22:36 -0400
Message-Id: <200009050622.CAA01910@torque.pothole.com>
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

	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.

	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.

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

 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

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