[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
Bob, I think the problem is that it conflicts with the obvious interpretation of the URL parameter when the expansion into a hypothetical directory hierarchy takes place, in contrast with the Package section 2.6 rule which, under the stated 2.6 restraints, works the same either way (ignoring the corner cases involving character sets and encodings). In fact, if you simply said that the constraint on the xml-dsig <Reference> URL is that it must target a sub-file of the same package, you'd be done and be consistent with the 2.6 rule for interpretation of IRIs. I think that qualifies under point 2 of my recommended cure. - Dennis PS: Does anyone know if the metadata RDF proposal use of URIs also going to be an exception to Package section 2.6? Lets not do that for any of these borrowed standards that use URI in widely understood ways and that we have not explicitly constrained very well. The saving grace for manifest.xml is the use of an ODF-specific definition for the manifest:full-path attribute. PPS: Oddly, OO.o 3.0 will open and verify an OO.o 2.4 ODF 1.1 signed document but it will refuse to sign such a document when in Save as ODF 1.0/1.1 mode. It will only create signatures on documents saved as OO.o documents with office:version="1.2" and then with the provisional OASIS namespace that we have been using in the ODF 1.2 drafts and proposals. PPPS: The requirement that the URI resolve to a file within the package is different than saying the URI must be resolved against the root of the package rather than the (hypothetical) location of the XML document within the package (a statement that the current Package section 2.6 makes concerning all uses of URIs in the XML documents of the package and that 17.5 made already for ODF 1.0 and ODF 1.1). I don't feel responsible for an existing undocumented implementation that makes an unexpected alteration of the use of URI by the xml-dsig specification (and also made an exception to 17.5 in its implementation of a foreign extension to the ODF 1.1 package). I think that is arguably a bug in the particular reliance on xml-dsig, and the use of an alternative namespace confines the bug and allows implementations to recognize its occurrence and automatically correct for it if the implementers so choose. That is one of the wonders of using namespaces as a means for differentiation of semantics. Specifications find it necessary to break-from existing implementations (and bugs in earlier versions of themselves) by using a different identifier quite often (a common practice when there are bugs or defects in an API specification). I think this is an appropriate approach in this case, although the TC as a whole will decide the matter. -----Original Message----- From: Bob Jolliffe [mailto:bobjolliffe@gmail.com] http://lists.oasis-open.org/archives/office/200901/msg00060.html Sent: Thursday, January 08, 2009 02:01 To: dennis.hamilton@acm.org Cc: office TC; Jomar Silva; Michael Brauer 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>: http://lists.oasis-open.org/archives/office/200901/msg00057.html > 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. Regards Bob [ ... ]
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]