Re: XML Processing in Current Implementations

I am leary of MUSTs in this area.  In many protocol applications some
subset of fields in a document may be signed and the non-signed fields
will be those which change in transit (ie, a hop count) or have other
sufficient cross-checks applied or are to be chekced and signed by
some later participant in a multi-party transaction or who knows what.
If an external style sheet is referenced there is no reason to include
or sign it if it is determinable by the protocol and all receivers
have a copy which is authentic by definition. Etc.

No document will ever save you from an incompetant or foolish
implementor and attempts to craft such a document are doomed to
failure.  We need to adequately point out areas of potential problems
and leave it at that.

Donald

From:  "Joseph M. Reagle Jr." <reagle@w3.org>
Message-Id:  <3.0.5.32.20000801084406.0142fe18@localhost>
Date:  Tue, 01 Aug 2000 08:44:06 -0400
To:  TAMURA Kent <kent@trl.ibm.co.jp>
Cc:  "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>
In-Reply-To:  <200007291421.XAA23296@ns.trl.ibm.com>
References:  <"Joseph M. Reagle Jr."'s message of "Fri, 28 Jul 2000 14:45:08-0400" <3
.0.5.32.20000728144508.013e8738@localhost>
	     <3.0.5.32.20000728144508.013e8738@localhost>

>At 23:21 7/29/2000 +0900, TAMURA Kent wrote:
>>> 2. Otherwise, we'd have to recommend that
>'http://foo.example.com/bar.xslt'
> >> also be included in a Signature Reference if we  want to get bit by
>having
> >> foo.example.com changing the stylesheet to affect the result after the
> >> signature.
> >
> >I agree.
>
>I propose that we add a few sentences to section 8.1.3 "See" What is Signed:
>__
>Just as a person or automatable mechanism should only sign what it "sees,"
>persons and automated mechanisms that trust the validity of a transformed
>document on the basis of a valid signature SHOULD operate over the data that
>was transformed (including canonicalization) and signed, not the original
>pre-transformed data. /+This recommendation applies to transforms specified
>within the signature as well as those included as part of the document
>itself. For instance, if an XML document includes an embedded stylesheet
>[XSLT] it is the transformed document that that SHOULD be represented to the
>user and signed. To meet this recommendation where a document references an
>external style sheet, the content of that external resource SHOULD also be
>signed via a signature Reference -- otherwise the content of that external
>content might change which alters the resulting document without
>invalidating the signature.+/
>__
>
>I believe the reason these started out as SHOULDs is because we want to be
>permissive to applications and we can't enforce/check some of these
>recommendations. However, I'd feel more comfortable if some of them where a
>MUST. Does the WG think we are communicating the hazards involved in this
>domain of transforms well? Will implementors know to lock this stuff down
>and or even prohibit it if they don't do a really really good job? What do
>others think?
>
>
>_________________________________________________________
>Joseph Reagle Jr.   
>W3C Policy Analyst                mailto:reagle@w3.org
>IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/
>

Received on Tuesday, 1 August 2000 11:32:31 UTC