OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[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

Hello Dennis

First of all, well spotted on the namespace.  I hadn't noticed that
OOo 3.0 had started using the new namespace..

2009/1/8 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:

This solution is only required if we really see this as a dilemma.  I
admit when I first saw the use of these relative path URI's I thought
it was a bit odd, but in retrospect, I think the rationale which has
been provided is sound enough.  Indeed the 'convention' adopted has
the additional advantage that any URI's that may appear in files in
the META_INF directory must resolve to "files" within the package.
This is, in my opinion a good thing.  The only compelling reason to
allow other URI's would be if you wanted the signature to reference
something outside the package, which you wouldn't.  This is not odd.
For example, even though ECMA376 has quite a different packaging
model, I understand that the same restriction effectively applies -
signatures refer to parts within the package.

So the dilemma is not really a dilemma.  The main effect of your
proposed change would be to make existing implementations
non-compliant.  If this was necessary to solve a real problem, I would
support it, but I don't see that it is.


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