RE: [office] DSIG proposal - FYI

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

Bob, I want to support this proposal.  I have some questions and
suggestions:

1. Definitive References
   1.1 Please provide a definitive reference to ETSI TS 101 903 v1.3.2 that
someone could use to obtain the specification.
   1.2 I suggest that that [xml-dsig] reference a specific version of the
XML DSIG specification. Unless there is a conflict with ETSI TS 101 903, or
with canonicalization of ODF XML items, I suggest "Donald Eastlake, Joseph
Reagle, David Solo, Frederick Hirsch, Thomas Roessler (eds.).  XML Signature
Syntax and Processing (Second Edition).  W3C Recommendation 10 June 2008.
Available at <http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/>.  (This
will also work for citation of the SHA-1 Message Digest procedure.) 

2. References to Signed Material
   2.1 In this specification, detached signatures are found in XML documents
of the packages META-INF folder.  In the simplified proposal, there is no
specified name, but one can expect that they are of MIME type
application/XML and the root element is <ds:Signature
xmlns:ds="http://www.w3.org/2000/09/xmldsig#";> (or logical equivalent).
That seems to be an immediate consequence of not specifying anything
further.  Is that understanding correct?  One might assert that much in the
ODF 1.2 specification.
  2.2 In the <ds:Signature> element, there will be one or more
<ds:Reference> elements.  Those elements will need to refer to Zip items
within the ODF package for there to be signing of those items or elements
within them (in the case that the item is an XML document).   
  2.3 It is probably important to point out that the use of relative paths
in the <ds:Reference> element URI is subject to the interpretation for ODF
1.2 relative paths and that the reference is understood to be [in]to the
uncompressed form of the Zip package item.
  2.4 Although one <ds:Reference> can have no URI and have
application-determined significance, there is no such agreement for ODF.  If
you want to reserve that for an ODF-specific usage, we need to say so.
[xml-dsig 4.3.3.1]
  2.5 There needs to be some profile information about whether or not data
objects being signed are limited to octet streams or whether they may be
(XPATH) node sets. [xml-dsig 4.3.3.2].  I suggest the octet stream case.  If
individual XML-item elements are permitted to be referenced, I suggest that
be by fragment identifier and xml:id be used for identification of the
fragment.  If you want to somehow skirt this consideration, I think there
needs to be some limiting statement (octet streams only, say) so that richer
cases remain available in future extensions.  The octet-stream-only case
seems to be the only simple rule that reserves dealing with fragment
identifiers and/or XPATH (that is, XPOINTER fragment ID) expressions to
future extensions. 
  2.6 It doesn't have to be mentioned, but it is of course possible to have
<ds:Signature> elements that sign other <ds:Signature> elements and such
counter-signing activity is not unusual.

 - Dennis


-----Original Message-----
From: Bob Jolliffe [mailto:bobjolliffe@gmail.com] 
http://lists.oasis-open.org/archives/office/200812/msg00103.html
Sent: Friday, December 12, 2008 01:09
To: office TC
Subject: [office] DSIG proposal - FYI

Greetings

For those who are busy examining proposals I'd like to point out that, in
the interest of progress on 1.2, I have drastically simplified the digital
signature proposal made earlier this year by Jomar and myself.
 
http://wiki.oasis-open.org/office/DSigProposal

As it currently stands, there are no longer any schema changes being
proposed - just a short (two sentence) addition to the text indicating that:

"These digital signatures shall conform to the W3C XML Digital Signature
specification (http://www.w3.org/TR/xmldsig-core/). Applications may use
extensions to the XML DSIG core specification, such as those required for
implementation of XAdES signatures specified in ETSI TS 101 903 v1.3.2."

Regards
Bob