RE: Meaning of document closure

Tim,

	I agree with your analysis. I think we are essentially arguing the
same case but with slight differences in terminology. What is signed
is by definition the document.

	In order to verify the signature the document the client has to
assemble the exact bit sequence that was signed. The client has no
business trusting any document other than the document that the verified
bit sequence represents.

	One XML document may well be transported encapsulated in another
but unless the enclosing document is signed the data it contains cannot
be trusted.

		Phill



> -----Original Message-----
> From: w3c-ietf-xmldsig-request@w3.org
> [mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Tim Berners-Lee
> Sent: Saturday, September 18, 1999 2:41 PM
> To: IETF/W3C XML-DSig WG
> Subject: Re: Meaning of document closure
>
>
>
> Short version:
>
> I think that the solution is now clear to the "signed in parts"problem,
> that you must define (using xpath or sed or whatever) the way
> a valid document is a function of the parts, and sign that document.
>
> Long version:
>
> I am worried that this "meaning of document closure" thread
> is suggesting that signing parts should be construed as parts
> having meaning
> in context.
>
> Basically, logically, a document is a sentence in
> a language, and we have applications which process documents
> according to specs, and we say that documents have meaning.
>
> Parts of documents do not have meaning per se.
>
> It is not, of course, for the digital signature spec to say what the
> semantics are
> of a document -- that is the for the language.  It is for the digital
> signature
> to show how a document has been signed with a certain key.
> It is for a trust system to determine the algorithm for defining
> what can be
> inferred from
> a document signed with a given key.
>
> When we talk about signing parts of a document, then they only way
> I can see of giving meaning to this is to say that we are signing a
> some document which is not acutally given, but is formed by making
> a particular transfortion on the document given.
>
> One  can try to talk about the "semantics of a part of the document
> in its context in the document" as much as one likes but one can only
> define what it means by showing or defining that it is equivalent to some
> other notional document.  John Boyer says, "An element's meaning can be
> changed by tags and attributes of any element in its ancestor path. "
> Well, you can change is by making any change anywhere along the lines of
> "this overrides what I said in the paragraph above" -- depending of course
> on the language you are writing in. But XML has no rules
> outlawing langauges
> which allow that.  So you can't ask me to sign the odd-numbered
> second level
> elements of a document. You can ask me to sign the document which would be
> formed by stripping out all even-numbered second-level elements.
>
> Life is then simplified.  A signature is over a document.
> The document can be referred to, and/or enclosed, directly,
> or specified as a manipulation function.  So long as both parties
> know how to do it, any function can be used. This puts the
> (xpath, say) function into a very similar position to the canonicalization
> function.
>
> We don't have (here) to discuss what modifications may or may not
> be made to
> a document later.  A particular sentence has been signed. According to the
> language,
> one may be able to deduce other valid things and craete other believable
> documents
> by futher manipulations but this spec doesn't have to worry about that.
>
> A signing user should of course be presented with the function being
> signed rather than any original document.
>
> I think this addresses for exaple the scenario Phill mentions in
> http://lists.w3.org/Archives/Member/w3c-xml-plenary/1999Sep/0044.html
>
> Tim BL
>
> ---------------------------
>
> (By the way, I think of closure in the sense of the set of all objects
> obtained by repeated application of an operation. I expected the term to
> represent the repeated operation of finding all dependent
> references within
> the document and signing them.  Dependent references meaning
> something which
> affects the meaning and you won't already know and trust.
>
>

Received on Monday, 20 September 1999 10:21:06 UTC