[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [office] DSIG proposal - external-sigining use case
Here's an use-case where signing material external to a document can matter. An ODF master document is an ODF document that includes other ODF documents as the contributions of parts to it. Clearly, the individual parts can be individually signed using DSIG. They have independent existence as documents and that's just fine. However, this does not account for their important use in combination with a given master document. There can also be external parts of any ODF document and these parts, whether signable or not, are not tied to any signature that is exclusively on the document that refers to the parts. The master document can be signed using DSIG, of course, and that can effectively sign the references to the parts but it doesn't do anything about tying the signature over the targets of the parts (which are presumably accessible and amenable to digesting as octet streams). The use case applies any time there is companion material that needs to be embraced by a single signature with the main document in order to assure that the composite is properly signed. Once could handle this with an external signature not involving ODF DSIG at all, and we could let it go at that. Or we could simply not preclude the eventual natural extension of the rules to allow it through eventual relaxation of restrictions atop of the existing 2.6 provision. (In other words, "never say never" as an architectural principle companion to "avoid irreversible decisions.") - Dennis PS: Even if what is signed in the master document is the (synthetic) document that is somehow the master with the components merged in, it would be pretty hairy to accomplish that with a canonicalization rule that doesn't invoke the specific parts somehow, since it is necessary to redo the canonicalization as part of verifying the signature. Although there are principles in xml-dsig that might be honored better this way, this is far more difficult than simply referencing the components in the signature of the master document that is intended to embrace some or all of the external material. PPS: I have no idea what happens in signing a master document and its parts in the current implementations. I also don't know what they have to say about the digital signatures when the master document is opened. (OO.o 2.4 allows signing of the parts but not the master document and it appears to make no note of the signing of the parts when the master document is opened with incorporation of the linked parts. I am not that curious what OO.o 3.0 does when in "ODF 1.2" mode.) PPPS: If we are going to talk about OOXML's restriction of references in signatures to parts of a package, which is indeed the case, we should note how they accomplish that using package-specific rules that carefully profile xml-dsig. It is instructive to see how they did it without breaking explicit rules in xml-dsig. I commend Section 13 of ISO/IEC 29500-2:2008 to your attention, along with the interesting example in subsection 13.3. This specification sets a pretty high mark for precision and rigor that is to be aspired to but I believe is out of reach for ODF 1.2 for several reasons. I also point out that the way package-specific URI rules are introduced is by use of manifests in <Object> sub-elements (where xml-dsig is generous), and that there is explicit allowance of additional application-defined object elements within a package signature element. Section 13.2.4.14 has the following interesting statement: "Format designers and producers might not apply package-specific restrictions regarding URIs and Transform elements to application-defined Object element. [O6.9]" [O6.9] refers to an informative (that is, non-normative) guideline for achieving conformance and on whom the responsibility falls with regard to the optional requirement (in this case, format designers, format producers, but neither package producers nor format consumers). -----Original Message----- From: Bob Jolliffe [mailto:bobjolliffe@gmail.com] 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 [ ... ] 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. [ ... ]
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]