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

Feedback on requirements

From: John Boyer <jboyer@uwi.com>
Date: Tue, 27 Jul 1999 17:50:01 -0700
To: "Joseph M. Reagle Jr." <reagle@w3.org>
Cc: "DSig Group" <w3c-ietf-xmldsig@w3.org>
The subsections of Section 3 should be numbered.

A number of the URLs in the references don't work.

In Section 2, paragraph 2.1:
When it says "...describe how to digitally sign... an XML document..."
Is this referring specifically to the non-terminal symbol 'document' in the
If so, this would include the Prolog and Misc*.  The reason I mention this
is that I heard recently that the canonicalization group was hoping to drop
these...  What's the story?

In Section 2, paragraph 2.2:
What is meant exactly by "cryptographic" signature?  What qualifies and what
According to the ABA, a signature is that which provides signer
authorization, document authentication and signer authentication.  The
degree of security depends on the algorithms chosen within an application.
Perhaps just remove the word cryptographic and instead define what a
signature is...

In Section 2, paragraph 2.3:
What do these mean?  Point A seems to be vacuously true.  Point B doesn't
seem to be correct.  It is not the case that we associate a signature with
other info that provides validity and identity.  The signature *is* that
which provides validity and identity.

In Section 2, paragraph 7:
We seem to have adopted the XLink as our way of indicating resources.  This
has security problems with respect to identifying parts of an XML document
(as required in Section 2.3).  Firstly, we need a way to identify
non-contiguous portions of a document in such a way that the relative
positions of the connected components is preserved.  Not even an XML
fragment does this (I'm not refering here to fragment as that which appears
after the # but rather to the XML Fragment Interchange working draft).
Secondly, there seems to be no way right now to obtain document closure.
That is, we can list that which got signed in a document, but we also need
to have a way of expressing what gets omitted from a document.  The reason
is that we want to omit certain things (like a second signature element) but
we want the first signature to break if anything else gets added to the
document.  Otherwise we have a signed document where anything could be
added, even things that obscure the original intent of the document when it
is rendered.

In Section 3, paragraph 2 of Signature Data Model and Syntax:
Clarification.  The term is being used in the same sense as it appears in
the XLink spec, namely an element id appearing after a #.  You are not
refering to fragment as defined in the XML Fragment Interchange working
Again, we should require at least fragments, but since they don't allow
non-continuous pieces, we need something more (or we need to require the
fragment group to add discontinuity).

In Section 3, under Processing:
XML applications should generate an error in this case, shouldn't they?  Is
there a valid case (i.e. a case where someone isn't trying to exploit a
security hole) where we'd want a cryptographic blob's data to be different
from the attributes expressed in the XML.  I don't think we'll get through
very many security reviews with software that permits this.
Received on Tuesday, 27 July 1999 20:49:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:09:55 UTC