Comments on Scenarios

John, good job on [1], comments follow. [Todd, I've cc'd you because there
is some good definition candidates in here.]

[1] http://www.w3.org/Signature/Drafts/xmldsig-scenarios-990818.html

 >2. Scenarios
 >2.1 Enveloped Internal Content
 >2.1.1 Enveloping by Packaging
 >   ISSUES:
 >     * The intent of this scenario is that an XML signature should sign
 >       the enveloped information, yet the core behavior does not include
 >       validation of the enveloped information. 

We should converge on some definitions of the native encoding and package
encoding, I'm not quite sure what you are speaking of. Also, what do you
mean by "validation of the enveloped content"?

 >       Thus, at a minimum, it
 >       would seem that the Resource element should also specify a
 >       canonicalization algorithm so that applications other than the one
 >       that generated the signature can also validate the enveloped
 >       information.

        Not following.

 >     * Should we permit or disallow specification of certificates by
 >       Locator (as opposed to specifying by Value as shown below)?
 
I think so. Treat it as a rdf:resource.

 >2.1.2 Direct Envelopment
...
 >   Another example of this is suggested by an upcoming protocol named
 >   IMPP (Internet Messaging and Presence Protocol). IMPP messages have
 >   the property that their human-readable content is typically quite
 >   short, so signature-block size has a distinct impact on the overall
 >   bandwidth used by an IM system. Were we to do create signature markup

(Where)

 >   using the indirection of a manifest, the manifest itself could be
 >   about as large as the IMPP message! The direct method reduces the
 >   overall size, and the size can be further reduced by not even putting
 >   the content in the Resource element.

I'm calling this a package.

 >2.2 Unenveloped Embedded Content

/me wonders if there is a better word than unenveloped? In the data model
[1], it's still just a reference, but happens to be sitting in the same
document. Straightforward aside from excerpting yourself out from the
signature you discuss below.

[1] http://www.w3.org/Signature/Drafts/xml-dsig-datamodel-990823.html

 >   ISSUES:
 >     * If applications other than the one that generated the signature
 >       must validate the resource indicated by the Manifest, then the
 >       Resource must indicate the canonicalization algorithm used on the
 >       indicated element.

Still not quite getting this.

 >   <AnXMLDocument id="root">
...
 >     * If the element indicated in the Resource contains (is an ancestor
 >       of) the elements representing the signature, then every
 >       canonicalization algorithm will have to know how to omit the
 >       subelements of a signature that must be changed during signature
 >       generation.

If you are going to the bother of naming an element "root" other than the
real root (href=""), then why not just move the dsig outside the
<AnXMLDocument>?

   <?xml version='1.0'?>
   <!DOCTYPE AnXMLDocument ...
   
   <AnXMLDocument id="root">
   ...
   </AnXMLDocument>
   <dsig:Signature>
   </dsig:Signature>
...   

Ah, that's impossible by [2], can only have on root. I wonder if we should
use namespaces to take care of a lot of this exclusion. For instance, if in
legal issues someone might create a document, and others will add things via
another namespace, would the signature break. Is it possible to _forbid_
others from adding other namespace qualified declarations in your content?
Perhaps schema will give us the ability... At this point I'd probably agree
we need some sort of exclude ability.

[2] http://www.w3.org/TR/REC-xml#NT-element

 > 2.2 Unenveloped Direct Signatures
 >   ISSUES:
 >     * If applications other than the one that generated the signature
 >       must validate the resource indicated by the Manifest, then the
 >       Resource must indicate the canonicalization algorithm used on the
 >       indicated element.

Ed: I'd prefer if numbered the issues and used fragment IDs and hrefs to
point to redundant text.

 >2.4 Signing Partial XML Documents
...
 >   <dsig:Locator href='#A'/>

who is #A pointing to? is this an xptr?

 >2.4.2 Document Closure

Could you define this please?

 >2.4.3 Preserving Ancestor Element Information
...
 >   For a specific example, suppose we have a hypothetical declarative
 >   computation language in which each computed XML element derives a
 >   current value tagged by cval based on evaluation of a mathematical
 >   expression contained in a subelement called compute.

Ok, now I understand the scenario here given its closeness to XFDL.

 >   the author of such a document wishes to digitally sign the
 >   computations to guarantee to users that the interpreting application
 >   of the XML document will behave as the author intended. To do this,
 >   the cval elements must be omitted from the signature so that the
 >   computations can be operated in the interpreting application without
 >   breaking the author's signature.

What I don't understand is will the application be dynamically changing the
values for the variables in the XML as it computes? If so, the signer only
wants to sign the expressions and the initial values? Why not just keep
intermediate values in memory till the whole thing is processed?


 >2.4.4 Preserving Order of Non-continuous Element Blocks
..
 >   Furthermore, XML does not forbid the interspersion of elements from
 >   differing [46]namespaces, so the ability to sign only those elements
 >   in a given namespace may be hindered if we cannot capture the order in
 >   which those elements appear.

I'm somewhat uncomfortable with the repeated "XML does not forbid the ..."
XML doesn't forbid many things, however that doesn't open our scope to
include all application requirements XML does not forbid. <smile>


_________________________________________________________
Joseph Reagle Jr.   
Policy Analyst           mailto:reagle@w3.org
XML-Signature Co-Chair   http://w3.org/People/Reagle/

Received on Monday, 23 August 1999 18:00:18 UTC