Re: Feedback on requirements

At 05:50 PM 7/27/99 -0700, John Boyer wrote:

John, I'm not qutie sure since you don't provide a referent for your
comments, but I think they are over an older version. I applied what I could
to [1], resulting with [2]:

[1] http://www.w3.org/Signature/Drafts/xmldsig-requirements-990721.html
[2] http://www.w3.org/Signature/Drafts/xmldsig-requirements-990728.html

 >The subsections of Section 3 should be numbered.
 
fixed.

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

 >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
 >XML BNF?

http://www.w3.org/TR/1998/REC-xml-19980210#dt-xml-doc
[1]  document ::=  prolog element Misc* 


 >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?
 
I expect to have the c14n draft up today. We are signing the (c14n) form of
a XML document, if a particular algorithm throws that info away, it's the
applications choice to select it.

 >In Section 2, paragraph 2.2:
 >What is meant exactly by "cryptographic" signature?  What qualifies and
what
 >doesn't?
 >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...
 
Given how hairy many of these terms are, starting a definition section now
with extremely precise and well referenced terms would be a good idea.
However, that will take a lot of work (it's most of the spec IMHO!) and I'm
afraid to load it all into the requirements document, but good point, I'll
give this some thought.

removed "cryptographic"

 >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

This is very hairy... Could you explain how it doesn't?
        XML-Fragment Interchange 
        http://www.w3.org/1999/06/WD-xml-fragment-19990630.html 

 >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.

I'm very afraid of this in the short term. I would suggest that applications
that care about fragments and specifying no-inclusion/inclusion use XSLT or
whatever else, and sign that. Then if they want to ensure the generated XML
is a valid version of the transormed content on signature validation, do
that at the application level.
        XSL Transformations (XSLT) Version 1.0
        http://www.w3.org/TR/WD-xslt
For instance, one could use things like those in XFDL to:"When a program
checks a signed form, it compares the data in the [transformed data] with
that of the portion of the form that is apparently signed" Is this
reasonable. Building this into DSig now is too ambitious.
        XFDL 4.0
        http://www.w3.org/TR/NOTE-XFDL
        
 >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.

Yep, part of the processing model will probably say, and when you sign
href="" (the object you are in) remove bits of yourself from consideration.

   4.2. Same-document References
   A URI reference that does not contain a URI is a reference to the
   current document.  
   http://www.ietf.org/rfc/rfc2396.txt

However, this removal has to be smart enough not to remove other signatures,
if in fact that is what you are signing. To this end, this is why I prefer
manifests where you can canonicalize external objects according to content
c14n, instead of dsigs embedded in content that refer to the things of which
they are part of. I hope to see more of this in the scenarios. 

 >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).

I'm interested in what you are thinking, but not quite sure, and would
enourage you to send it to the fragment group (cc me) and we can see what
happens.

 >In Section 3, under Processing:
 >XML applications should generate an error in this case, shouldn't they?

I'm not sure frankly, I'll add this as a comment.
_________________________________________________________
Joseph Reagle Jr.   
Policy Analyst           mailto:reagle@w3.org
XML-Signature Co-Chair   http://w3.org/People/Reagle/

Received on Wednesday, 28 July 1999 15:44:37 UTC