RE: XML Processing in Current Implementations

I agree with Donald.

With regard to section 8.1.2 and 8.1.3, while it may be
reasonable to briefly point out ways that inexperienced
implementors could create ineffective XML Signatures,
there are applications where the use of significantly
altering transforms  is useful and we don't want to stop
those who know what they are doing from doing it.

When discussing XSLT, it is important to remember there
are two semantically different reasons for using it:
1.  To define how an XML document should appear to a viewer.
2.  To transform an XML document into the data to be signed
(eg. as an alternative to XPath where XPath is insufficient).

For some apps, the same XSLT transformations may accomplish 
both cases 1 and 2.  For others, different transformations may be
needed for each case.  And for other apps, only one of case 1 or 2
may be relevant.

I have no doubt that experience with real-world XML Signatures
will help us understand what constitutes best practice.  While
we can list some basic "watch it"s in the spec, we MUST NOT
be too restrictive ;-}.  I would even go as far as taking out all the 
RFC2119 key words in section 8.1.3.

Ed
-----Original Message-----
From: Donald E. Eastlake 3rd [mailto:dee3@torque.pothole.com]
Sent: Tuesday, August 01, 2000 11:34 AM
To: IETF/W3C XML-DSig WG
Subject: 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 16:28:34 UTC