RE: [office] DSIG proposal - external-sigining use case

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

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.

[ ... ]