[Action-32] - Document requirements and assumptions in simple signing strawman

Here is a list of requirements and assumptions for my strawman proposal 
from August. Requirements are not listed in priority order.

 
Document Signing Requirements
 
1. Support multiple signatures (in parallel), counter-signatures and 
   timestamps
2. Long term archived documents - must be able to embed certificates, 
   CRLs, OCSP responses and RFC 3161 timestamps for future validation
3. Support detached signatures
      a. Office 2007 XML document signatures are implemented as detached 
         signatures, which are then bundled with the document. 
4. Must be able to sign an element and its subtree
5. Compatible with XMLDSIG 1.0 
      a. See assumptions 1 to 3
6. Can be implemented as a small, simple library
      a. Minimize attack surface
      b. Easy to locate the signature verification key.
      c. Easy to determine the context or position of a signature
      d. Minimize memory footprint by allowing one-pass (streaming) 
         signature generation and verification
      e. Consider standardizing a way to indicate the maximum size limits 
         for nodes
      f. Must be easy for applications determine if a signature covers 
         the set of data it expects. 
      g. Cannot require applications to connect to untrusted URLs to 
         complete signature verification
      h. Minimize dependency on other XML standards. A simple standard is 
         much easier to implement, test and use correctly.
7. Must be resilient to most "shred and reconstruct" operations by 
   different layers in the application (or application plug-in)
      a. Application plug-ins may not always use the same XML parser as 
         the application

Assumptions

1. A signed document may be submitted to Web services that are based 
   on XMLDSIG 1.0 which will verify the signature, and possibly add 
   counter signatures and timestamps to the document
2. New applications written to run on multiple OS versions may not be 
   able to leverage a new XMLDSIG library. Instead, they may have to 
   use an existing XMLDSIG 1.0 library if they cannot ship a new 
   XMLDSIG library, or update the XMLDSIG 1.0 library in the OS
3. A document signed with a newer version of application may have to 
   be verified by a user running an older version of the application, 
   or the application with a 3rd party developer plug-in
4. The location or context of a signature within a document materially affects its 
   meaning
5. Applications may want to prevent additional processing of a document 
   if the signature cannot be verified. The API used to verify document 
   signatures may be different than the XML parser used to parse the 
   document
 
 
Kelvin

Received on Wednesday, 15 October 2008 20:44:15 UTC