Re: Schema Validity and Syntax Constraints (Was: Followup on I18N Last Call comments and disposition )

From:  "Joseph M. Reagle Jr." <reagle@w3.org>
Message-Id:  <3.0.5.32.20000721150453.01a555f8@localhost>
X-Sender:  reagle@localhost
Date:  Fri, 21 Jul 2000 15:04:53 -0400
To:  "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>
Cc:  "Martin J. Duerst" <duerst@w3.org>, w3c-ietf-xmldsig@w3.org,
            Dan Connolly <connolly@w3.org>
In-Reply-To:  <200007182143.RAA07750@torque.pothole.com>
References:  <Your message of "Wed, 12 Jul 2000 18:02:32 EDT."             <3.0.5.32.
20000712180232.00ab5100@localhost>

>[Thread moves back to question of whether a valid XML Signature is
>well-formed, well-formed+constrained, DTD Valid, or Schema Valid]
>
>At 05:43 PM 7/18/2000 -0400, Donald E. Eastlake 3rd wrote:
> >>Does the text [1], "Thus, to interoperate between different XML
> >>implementations, the following syntax constraints MUST be observed" mean
> >>ONLY when a DTD/schema is not present, or any XML content being signed can
> >>never have attribute values? (I assume not).
> >>[1] http://www.w3.org/TR/2000/WD-xmldsig-core-20000711/#sec-XML-1
> >
> >I meant something like "Signatures which do not follow the three
> >syntax constrains below will generally fail to interoperate if any XML
> >implementation that ever tries to verify them does not have the
> >required DTD/schmea(s) present." 
>
>Ok... (So this isn't required for conformance, just warning?)

If we are going to require schema enforcement, then I guess this can
just be a warning.

> > Note that it is not just the dsig
> >DTD/schema but for anything within the SignedInfo and other stuff in
> >the same document referenced by any References.  In generaly, it seems
> >like mandating these syntax contraints would be a good idea.
> 
>I expect you don't mean "Signatures which do not ..." because I'd expect a
>Signature application would have some sense of the  Signature DTD/schema;
>you mean content being signed? This also returns us to the question as to
>whether we expect Signature verifying applications to check for XML DTD or
>schema validity.

? I'm not sure I understand your paragraph abaove.  The syntax
constraints are to avoid changes during input due to the DTD/schema.
Signatures break for changes in either the signature or in the data
signed which, if it is XML anywhere in the same document as the
Signature element, will have gone through XML 1.0 input processing.

>DTD is out for enveloped/envloping signatures.

Considerations are the same for a "detached" signature where the
signed data is in the same XML document as the signature.

>I argue a conformant Signature application needs to valdiate the Signature
>element against the Signature schema. Fortunately, we aren't using that many
>features, we could get away with some text akin to (tweaked Connolly
>
>    a conforming digital signature element is an element [information 
>    item] that is _schema-valid_ with respect to the schema element 
>    declarations found within each element's respective description and
>    definition.

Certainly we want to minimize requirements as to method and
concentrate on requirements as to result.

> >>And with respect to the text, "2. all entity references (except "amp",
>"lt",
> >>"gt", "apos", "quot", and other character entities not representable in
>the
> >>encoding chosen) be expanded" How would you respond to Martin's comment? I
> >>think the point was to say these things don't vary as they are defined by
> >>the doctype and convention, so that's why we don't mind if people use them
> >>in their non-expanded form: &amp; = &#38;
> >
> >You have to be able to use most of the enumerated entities to properly
> >express things without tripping up the XML parsing and they are
> >pre-defined by the XML 1.0 specificaztion.  &amp; = &
> >"Expansion" is an odd term in this case as they change into one
> >character so they get shorter.
> 
>I tried to rewrite the text of this section and the one below but was unable
>to do so? Could you take a stab such that Martin's comments are addressed? 

OK.

> >>[1] http://www.w3.org/TR/2000/WD-xmldsig-core-20000711/#sec-XML-1
> >>
> >>At 15:44 6/27/00 -0400, Joseph M. Reagle Jr. wrote:
> >> > >7.1, second list, point 2: 'except... and other character entities
> >> > >not representable...': This may be wrongly understood to mean that
> >> > >e.g. &eacute; in a HTML document shouldn't be expanded if
> >> > >the encoding is US-ASCII. This is of course wrong, &eacute;
> >> > >should in this case be changed to the appropriate numeric
> >> > >character reference (and the spec may have to say whether
> >> > >these should be decimal or hex,...).
> >
> >I guess that's right, ie, characters not representable should be
> >changed into a numeric character reference.  But I can't see how it
> >matters whether it is decimal or hex.  Any conformant XML 1.0 reader
> >will translate the numeric character references into the appropriate
> >character.  Things which depend on the surface input character string
> >and assume no XML processing are completely screwed as far as
> >interoperability anyway.
>
>_________________________________________________________
>Joseph Reagle Jr.   
>W3C Policy Analyst                mailto:reagle@w3.org
>IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/

To follow the IETF tradition, we would require signature generation to
conform to the schema and signature validation to be more forgiving.
However, I don't really see much need for such flexibility at validators.
I think we have provided enough flexibility in the elements and extensions
explicitly provided.  Given a desire to use automated tools to enforce
syntax checks, I think that requiring conformant validators to enforce the
schema is fine.

===================================================================
 Donald E. Eastlake 3rd                    dee3@torque.pothole.com
 140 Forest Avenue                          lde008@dma.isg.mot.com
 Hudson, MA 01749 USA     +1 978-562-2827(h)    +1 508-261-5434(w)

Received on Monday, 24 July 2000 14:59:47 UTC