|Bob Jolliffe||Dec 12, 2008 1:08 am|
|Dennis E. Hamilton||Jan 4, 2009 10:59 pm|
|Bob Jolliffe||Jan 5, 2009 5:26 am|
|Michael Brauer - Sun Germany - ham02 - Hamburg||Jan 5, 2009 6:42 am|
|Dennis E. Hamilton||Jan 5, 2009 10:28 am|
|Bob Jolliffe||Jan 5, 2009 1:24 pm|
|Dennis E. Hamilton||Jan 5, 2009 3:02 pm|
|Bob Jolliffe||Jan 6, 2009 4:54 am|
|Michael Brauer - Sun Germany - ham02 - Hamburg||Jan 6, 2009 5:48 am|
|Bob Jolliffe||Jan 6, 2009 6:12 am|
|Dennis E. Hamilton||Jan 6, 2009 1:11 pm|
|Dennis E. Hamilton||Jan 6, 2009 1:56 pm|
|Bob Jolliffe||Jan 7, 2009 2:17 am|
|Dennis E. Hamilton||Jan 7, 2009 12:21 pm|
|Dennis E. Hamilton||Jan 7, 2009 1:34 pm|
|Bob Jolliffe||Jan 7, 2009 2:06 pm|
|Jomar Silva||Jan 7, 2009 2:36 pm|
|Dennis E. Hamilton||Jan 7, 2009 3:48 pm|
|Dennis E. Hamilton||Jan 7, 2009 4:45 pm|
|Dennis E. Hamilton||Jan 7, 2009 6:00 pm|
|Bob Jolliffe||Jan 8, 2009 2:00 am|
|robe...@us.ibm.com||Jan 8, 2009 8:27 am|
|Dennis E. Hamilton||Jan 8, 2009 10:52 am|
|Dennis E. Hamilton||Jan 8, 2009 10:53 am|
|Svante Schubert||Jan 8, 2009 11:57 am|
|Dennis E. Hamilton||Jan 8, 2009 2:47 pm|
|Dennis E. Hamilton||Jan 8, 2009 4:16 pm|
|Bob Jolliffe||Jan 11, 2009 2:48 pm|
|Dennis E. Hamilton||Jan 11, 2009 6:41 pm|
|Bob Jolliffe||Jan 12, 2009 1:09 am|
|Michael Brauer - Sun Germany - ham02 - Hamburg||Jan 12, 2009 1:37 am|
|Dennis E. Hamilton||Jan 12, 2009 8:25 am|
|Subject:||Re: [office] DSIG proposal - external-sigining use case|
|From:||Bob Jolliffe (bobj...@gmail.com)|
|Date:||Jan 11, 2009 2:48:29 pm|
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.
2009/1/9 Dennis E. Hamilton <denn...@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 22.214.171.124 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:bobj...@gmail.com] Sent: Thursday, January 08, 2009 02:01 To: denn...@acm.org Cc: office TC; Jomar Silva; Michael Brauer Subject: Re: [office] DSIG proposal - URIs, Packages, and Namespaces - Proposal CORRECTION
[ ... ]
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.
[ ... ]
--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php