[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [office] DSIG proposal - URIs, Packages, and Namespaces - Proposal CORRECTION
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. [ ... ]
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]