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

["Bob Jolliffe" <bobjolliffe@gmail.com>]

Hi Dennis

It's an interesting use case.  There are perhaps even others.  One can
imagine a scenario where a signature policy exists and is accessible
via a http URI.  One might want include a reference to the external
policy in the signed information so that a validator could assure
itself that the policy being referenced is the same as that which was
in force when the document was signed.  Whether it is a good idea to
implement such schemes is another matter, but I agree we probably
shouldn't preclude the possibility.

Which of course currently we don't.  This will perhaps be one of the
challenges to be addressed in the next version.

I agree, and I've said on a few occasions before, that the OOXML part
2 is a well crafted document.  As for the signature, I don't really
like the approach of using an extra level of indirection to get to the
actual content to be signed, but it works.  To me it feels like too
much advantage is being taken of the generosity offered by the
ds:Object element in xml-dsig.  But its a justifiable design decision
and also probably a bit off topic to discuss here.

Regards
Bob

2009/1/9 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.
>
> [ ... ]
>
>