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

RE: question on latest spec

From: Kevin Regan <kevinr@valicert.com>
Date: Wed, 15 Nov 2000 14:18:33 -0800
To: John Boyer <jboyer@PureEdge.com>, Kevin Regan <kevinr@valicert.com>
Cc: w3c-ietf-xmldsig@w3.org
Message-id: <613B3C619C9AD4118C4E00B0D03E7C3E3CB13B@exchange.valicert.com>

Also, it seems that the only interoperability issue would be
non-validating processors trying to deal with XML documents
that reference DTDs.  It is questionable if this should be supported
at such a high cost...

Kevin Regan

-----Original Message-----
From: John Boyer [mailto:jboyer@PureEdge.com]
Sent: Wednesday, November 15, 2000 2:06 PM
To: Kevin Regan
Cc: w3c-ietf-xmldsig@w3.org
Subject: RE: question on latest spec

Hi Kevin,

The reason is signature interoperability with non-validating processors.

I empathize, though :)

John Boyer

-----Original Message-----
From: Kevin Regan [mailto:kevinr@valicert.com]
Sent: Wednesday, November 15, 2000 1:50 PM
To: John Boyer
Cc: w3c-ietf-xmldsig@w3.org
Subject: RE: question on latest spec

What is the reason for doing this?  Isn't the exclusion of insignificant
white space one of the key forms of equivalence?  XML documents can be
displayed and handled in many different ways, with white space being
or removed from element content at various steps.  In general, this is
not a problem if a DTD is being used.  The meaning of the document
is clear.  However, this form of equivalence is eliminated in the XML
specification.  Why?

Kevin Regan 

-----Original Message-----
From: John Boyer [mailto:jboyer@PureEdge.com]
Sent: Wednesday, November 15, 2000 1:12 PM
To: Kevin Regan; w3c-ietf-xmldsig@w3.org
Cc: Joseph Reagle
Subject: RE: question on latest spec

Hi Kevin,

Actually, Section 2.10 of the XML spec makes it quite clear that all XML
processors must be capable of providing to the application ALL
within the document element.  Validating processors must further be
of telling the application whether a given whitespace character appeared
element content, i.e. was insignificant.

Many implementers of validating processors allow the application
to configure whether the whitespace should simply be discarded.

The statement you've come across in Section 2.1 is telling you how to
configure your validating parser.  You MUST set it so that all
whitespace is
reported to the canonicalizer.

NOTE: I don't see any harm in throwing out insignificant whitespace
the document is signed.  In other words, the original document accessed
the user from the web may have insignificant whitespace that your
application strips out before even presenting the information content to
end-user.  Once the end user affixes a signature, though, any
whitespace that gets added to the signed document will break the

John Boyer
Development Team Leader,
Distributed Processing and XML
PureEdge Solutions Inc.
Creating Binding E-Commerce
v: 250-479-8334, ext. 143  f: 250-479-3772
1-888-517-2675   http://www.PureEdge.com <http://www.pureedge.com/>

-----Original Message-----
From: w3c-ietf-xmldsig-request@w3.org
[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Kevin Regan
Sent: Sunday, November 12, 2000 6:20 PM
To: w3c-ietf-xmldsig@w3.org
Subject: question on latest spec

I've been a way on other activities for a while, and have just recently
gotten back to
the XML C14N specification.  I came across the following in section 2.1:

"All whitespace within the root document element MUST be preserved
(except for any #xD characters deleted by line delimiter normalization).
This includes all whitespace in external entities. Whitespace outside of
the root document element MUST be discarded."

I'm assuming that this means white space that is presented after the
document is processed
by the XML processor.  When a validating XML processor reads in a
document against a DTD,
insignificant white space is removed.  This is not the white space that
the specification is
referring to, is it?

Kevin Regan

Received on Wednesday, 15 November 2000 17:20:40 UTC

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