RE: [office] DSIG proposal - URIs, Packages, and Namespaces - Proposal CORRECTION

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

My (3) in the original note doesn't make sense because I didn't alter the
namespace in the "e.g." phrase. 

I have since confirmed, by generating some signed documents in OpenOffice
2.4 and 3.0, that there are indeed documents in the wild that use the
"urn:oasis:names:tc:opendocument:xmlns:digitalsignature:1.0" namespace as
well as  "http://openoffice.org/2004/documentsignatures"; and in both cases
the URIs look relative but are comparable to manifest:full-path values.
[PS: With regard to recommendations about digest algorithms, I see only
SHA-1 being used for digests here.  The signature itself uses PKI and, in
the case of my certificate, SHA-1 is used as part of the PKCS #1 RSA
Encryption.  I'm not worried.] 

Therefore, here is my revised solution to the dilemma, with the namespace to
be changed at once:

1. The introduction of the ODF usage of xml-dsig will be via the proposed
namespace and the xml-dsig namespace, to be revised in the schemas
for the DSIG proposal:

   1.1 The ODF 1.2 namespace for ODF DSIG will be
"urn:oasis:names:tc:office:xmlns:digitalsignature:1.0" 
(or any other acceptable, normative URI other than
"urn:oasis:names:tc:opendocument:xmlns:digitalsignature:1.0").

   1.2 The xml-dsig namespace is "http://www.w3.org/2000/09/xmldsig#"; 

   1.3 For example, the element introduced by the tag

 <DSIG:document-signatures 
   xmlns:DSIG="urn:oasis:names:tc:office:xmlns:digitalsignature:1.0"
   xmlns="http://www.w3.org/2000/09/xmldsig#";
   >

   introduces a DSIG in accordance with the ODF 1.2 specification (as
corrected here).

2. The interpretation of URIs within a <DSIG:document-signatures> element is
as prescribed in section 2.6 of draft 6 of the ODF 1.2 Package
specification.  (This is equivalent to section 17.5 of earlier
specifications, and clarification in response to the SC34 defect report will
not impact DSIG.)  
  2.1 If there are additional restrictions on the forms of URI that are
usable, the restrictions will not conflict with the rules for interpretation
of URIs [rfc-whatever] and the additional rules already incorporated in
section 2.6.  That is, the URI value can be used correctly without knowledge
of the DSIG-specific restrictions on providing such a value.  
  2.2 Note: We don't do this 2.1-like clarification anywhere else, and we
don't do anything else to profile xml-dsig (e.g., restrict canonicalization
methods, use of XPATH, and so on), so I would let it ride and rely on
implementers and perhaps application-specific interoperability profiles to
sort it out instead.

 - Dennis

-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] 
http://lists.oasis-open.org/archives/office/200901/msg00056.html
Sent: Wednesday, January 07, 2009 16:46
To: 'office TC'
Cc: 'Jomar Silva'; 'Bob Jolliffe'; 'Michael Brauer'
Subject: RE: [office] DSIG proposal - URIs, Packages, and Namespaces -
Proposal

[ ... ]

3. IN THE EVENT that usage of namespace
"urn:oasis:names:tc:opendocument:xmlns:digitalsignature:1.0" already exists
in documents produced by existing software, the ODF 1.2 specification will
choose a different namespace (e.g., 
"urn:oasis:names:tc:opendocument:xmlns:digitalsignature:1.0") and maybe,
just to be safe, we should change it anyhow.

[ ... ]