more comments on scenarios

(Back from vacation, gradually catching up...)

John, Richard, Brian, good work.

A few comments...

2.1.2 Direct Envelopment:
http://www.w3.org/Signature/Drafts/xmldsig-scenarios-990818.html#EnvelopedDi
rect
I have come to agree that we need to support this scenario.  It seems
reasonable to allow a signature to directly contain a resource.


2.2  Unenveloped Embedded Content:
http://www.w3.org/Signature/Drafts/xmldsig-scenarios-990818.html#two
One of the issues raised for each scenario here is "If the element indicated
in the Resource contains (is an ancestor of)..."  Given that the document
format or schema (explicitly specified in a DTD or schema or implicit in an
application) must include the signature element if the application is to
process the signature, I would assume that people would design their future
formats such that this will not be an issue (basically separating
to-be-signed data from not-to-be-signed data).  Adaptation of present
formats to use the new signature specification may be an issue, although as
suggested special canonicalization could be used to achieve that effect.


2.2.2  Unenveloped Direct Signature
http://www.w3.org/Signature/Drafts/xmldsig-scenarios-990818.html#Unenveloped
Direct
I am not sure how providing the option to directly sign the resource helps
here.  If the originating application chooses to use the digest-in-manifest
approach, the receiving application can choose not to verify the digest
against the actual contents.  Providing the option of directly signing the
content seems roughly equivalent to allowing the originating application to
force the receiving application to verify the digest in the manifest against
the actual data.  Is this the intent?  I would assume that most applications
would attempt to verify the digests against the actual resources in the case
where the resources reside in the document.  In the cases where the
receiving application does not do this verification, you must have control
over the originating application in order for the option to be of
assistance.


2.4  Signing Partial XML Documents
http://www.w3.org/Signature/Drafts/xmldsig-scenarios-990818.html#Four
The following issues lead me to feel that the general case of signed-data
interspersed with not-signed-data is too complex to be dealt with at
anything but the application level.  Each of the issues could be dealt with
by application-specific canonicalization algorithms.  Most of the issues
could also be dealt with by adding an extra element to the signature that
makes the appropriate assertion.


2.4.2  Document closure:
http://www.w3.org/Signature/Drafts/xmldsig-scenarios-990818.html#DocumentClo
sure
This concept is a little more amorphous than it might seem.  For example, a
document format may be defined that allows annotations to be added.
Excluding specific elements won't work in this case, since annotations might
be added after the signatures are computed.  I am assuming that the current
idea is to exclude specific pre-existing items, not general classes of
items.

For example, several of JetForm's form products allow users to attach
"JetNotes" to a form; these are like Post-It notes.  These might give the
next person in the process instructions on what to do with this particular
form, provide comments, or anything else for which one might use a paper
Post-It note.  Similarly, JetForm's workflow products allow one user to give
instructions to the next user.  In both scenarios, "document closure" may
(depending on the application) mean everything except the notes or
instructions, which might be added anywhere after the signature is computed.


2.4.3  Preserving Ancestor Element Information:
http://www.w3.org/Signature/Drafts/xmldsig-scenarios-990818.html#AncestorInf
o
I would note that the XML language also does not forbid an element from
deriving meaning from the attributes of its siblings or of the descendents
of its siblings, or for that matter from non-tag data located in any of
these places.  Note: I do not claim that the possibilities in the previous
sentence are a good idea, just that they are possible.  In some cases it may
make sense to do these things.

Also, a format may be designed where certain attributes must be omitted in
the signature, similar to the example with elements.  Using the example in
2.4.3 in the document, what if the nodes were something like this:

<node id="F" cval="5">
	<compute id="Fcompute"> C + D </compute>
</node>

I have changed the cval element to an attribute of the parent node.  This is
a common question when creating XML formats, whether to make something an
attribute or an element.  With this change to the example, we would need to
sign the node including the id attribute but excluding the cval attribute to
get the desired result.


2.4.4  Preserving Order of Non-continuous Element Blocks:
http://www.w3.org/Signature/Drafts/xmldsig-scenarios-990818.html#Noncontinuo
usInfo
I agree that this is important, however I must pick a nit...  I disagree
with the comparison to hash algorithms.  The order of the elements to be
signed may not matter.  In fact, in the general case there is no ordering,
since the elements are not in the same document.  The whole point to hash
algorithms is to guarantee the order of the bytes.  I do not think the
implication of "broken" is appropriate.  The proper level of security can be
provided at a different layer.  Previously I suggested several mechanisms
for dealing with this
(http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/1999JulSep/0086.html)
and at least one more (using a special canonicalization algorithm) has been
proposed. 


-Mark Bartel
JetForm Corporation

Received on Wednesday, 25 August 1999 14:14:01 UTC