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

Re: Question for Implementors (Was: Schema Validation Transform)

From: merlin <merlin@baltimore.ie>
Date: Tue, 11 Sep 2001 13:09:29 +0100
To: reagle@w3.org
Cc: w3c-ietf-xmldsig@w3.org
Message-Id: <20010911120929.3CFD843C09@yog-sothoth.ie.baltimore.com>

Just to reiterate (part of) what was said on the xmlenc conf call,
I think there are two issues:

1. Self-signed document validation

I create a self-signed document (same-document references).

  <Foo Id="foo"></Foo><Signature>...URI="#foo"</Signature>

The recipient of this document reads it in with validation (DTD or schema)
which introduces some default values.

  <Foo Id="foo" Bar="default"></Foo><Signature>...URI="#foo"</Signature>

The signature does not validate. This is a good thing, because the
document has changed. In particular, this will catch schema changes that
introduce new default values.

But, do we desire a statement in the spec to the effect that if you have
same-document references and validation may introduce default values,
you should be careful to either validate the document before signing,
or else explicitly specify all defaultable values?

2. Implicit parsing of octet resources

When the input to a transform is an octet stream and the transform
requires a node set (e.g., canonicalization) the dsig spec states that
the octet stream should be parsed. Further, it states that it should
not be schema-validated. However, it does not state whether or not
it should be DTD-validated. This appears ambiguous.

Options:

a) Leave it implementation-specific.

b) Specify that validated parsing is mandatory.

c) Specify that well-formed parsing is mandatory. Specify a new
   transform for DTD validation, just as we have one for schema
   validation. Aside: Internal DTD subsets are always applied, even in
   well-formed parsing mode.

It seems to me that a) is ambiguous and b) is inconsistent with our
handling of schemata.

By demand, we (Baltimore) currently support optional DTD validation during
this parsing step. Some applications want validation, others do not.

Merlin

r/reagle@w3.org/2001.09.10/12:48:19
>On Thursday 06 September 2001 13:45, merlin wrote:
>> WRT the PR review comment, it seems inconsistent that we say
>> *don't* schema validate, but *maybe* DTD validate. I know
>> that this has been a question from at least one customer, so
>> some clarification might be in order. I'd vote for *don't*
>> validate against an external DTD either. We've nailed down
>> implicit serialization (c14n); implicit parsing might be
>> good too.
>
>Well fortunately, I'm don't think XML1.0 (DTD) validation will affect the 
>instance all that much: introduces changes that survive C14N. We don't use 
>default attributes/values in the signature DTD. We do define internal 
>entities which require validating parsing, but I just added some text to 
>1.3 saying while we use them for editorial purposes, they aren't 
>recommended in actual instances.
>
>Can anyone else think of anything that would break (survive C14N) where one 
>party validated the signature, and the other didn't? (Or even yet, run a 
>test?)
>
>Can we leave it up to the application by permitting it to include the 
>DOCTYPE with DTD reference or not? (This was my assumption.)
>
>How many people actually DTD validate during their processing?
>


-----------------------------------------------------------------------------
Baltimore Technologies plc will not be liable for direct,  special,  indirect 
or consequential  damages  arising  from  alteration of  the contents of this
message by a third party or as a result of any virus being passed on.

In addition, certain Marketing collateral may be added from time to time to
promote Baltimore Technologies products, services, Global e-Security or
appearance at trade shows and conferences.

This footnote confirms that this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.
   http://www.baltimore.com
Received on Tuesday, 11 September 2001 08:10:09 UTC

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