OASIS Open Document Format for Office Applications (OpenDocument) TC

Hi,

please find below a proposal for adding digital signatures to ODF. It 
consists of two parts. The first one adds digital signature to ODF 
packages in general. The 2nd describes how they are used in OpenDocument 
documents.

Best regards

Michael


Digital Signatures (to be added to chapter 17, Packages)
========================================================

Files within a package may have a digital signature applied. Digital 
signatures are stored in one or more files within the META-INF folder. 
The names of these files *shall* contain the term "signatures". Each of 
these files contains a 

On 16/02/07, Michael Brauer - Sun Germany - ham02 - Hamburg

Dave,

Dave Pawson wrote:
> On 16/02/07, Michael Brauer - Sun Germany - ham02 - Hamburg
> 

On Feb 16, 2007, at 6:08 AM, Michael Brauer - Sun Germany - ham02 -  
Hamburg wrote:

> Files within a package may have a digital signature applied. Digital  
> signatures are stored in one or more files within the META-INF folder.  
> The names of these files *shall* contain the term "signatures".

Using file names to denote function seems like a bad idea to me. The  
manifest should be used to indicate whether a file is a signature (or  
something else)?

This issue has larger implications. See:

Bruce,

please let me clarify this. The proposal actually consists of two parts. 
One part is to add files called "documentsignatures.xml" and 
"macrosignatures.xml", which contain document signatures and macro 
signatures. The situation here is the the same as for the "content.xml" 
and "styles.xml" files that contains a document's content or styles, and 
that are also identified by their name. I therefore think it is 
reasonable to reuse this identification mechanism for these two kind of 
signatures as well.

The other part of the proposal actually is about adding signatures in 
general. The sentence that a signature stream shall include the term 
"signature" is actually not to be understood as an identification schema 
for signatures, but only as a naming guideline. Actually, there is no 
requirement for other kind of signatures than the two mentioned above. 
For this reason, if this naming guideline can be mis-understood, I would 
suggest that we remove it, instead of trying to find some identification 
schema for signatures, that we actually don't need at the moment.


Bruce D'Arcus wrote:
> 
> On Feb 16, 2007, at 6:08 AM, Michael Brauer - Sun Germany - ham02 - 
> Hamburg wrote:
> 
>> Files within a package may have a digital signature applied. Digital 
>> signatures are stored in one or more files within the META-INF folder. 
>> The names of these files *shall* contain the term "signatures".
> 
> Using file names to denote function seems like a bad idea to me. The 

It depends on how the files in question are used. Using the name to 
denote the function of a file is reasonable if there is exactly one file 
that has this function. That's the case for the content.xml and 
styles.xml, but also for the proposes documentsignatures.xml and 
macrosignatures.xml.

If there could be multiple files that have certain function, like in the 
metadata case, then a more flexible identification schema is in fact 
required.

> manifest should be used to indicate whether a file is a signature (or 
> something else)?

Actually, the signatures are considered to be part of the package 
itself. That's why they are stored in the META-INF folder. I'm therefore 
  not sure whether they should be added to the manifest at all.

Michael

Michael,

I would like to propose a functional extension to your proposal.
From our experience with digital signature for documents in the
marketplace and from looking at the digital signature functionality in
other document formats such as PDF and OOXML, I believe that visual
signatures are extremely important.
Your proposal creates invisible signatures in the sense that the
signature is not visible in the document content itself.
I think we should amend the proposal to include the option of adding an
interactive signature field (or signature line) to the document with the
ability to display in this field the graphical signature image of the
signer as well as other information (signer name, date/time, validity
marks).
If you find merit in such a proposal I can elaborate further with a more
formal description.

Thanks,

- Uri

Uri Resnitzky
Chief Scientist
ARX
http://www.arx.com

On Tuesday 20 February 2007 15:03, Uri Resnitzky wrote:
> I would like to propose a functional extension to your proposal.
> From our experience with digital signature for documents in the
> marketplace and from looking at the digital signature functionality in
> other document formats such as PDF and OOXML, I believe that visual
> signatures are extremely important.
> Your proposal creates invisible signatures in the sense that the
> signature is not visible in the document content itself.
> I think we should amend the proposal to include the option of adding an
> interactive signature field (or signature line) to the document with the
> ability to display in this field the graphical signature image of the
> signer as well as other information (signer name, date/time, validity
> marks).

Any signature has, by nature, a reference to the name / email of the signer.
If the signature is to be checked, that information needs to be present on the 
computer of the one checking if the signature is relevant.

This has the effect that if you get a signed document from me, you can only be 
sure it is actually from _me_ by checking against your local key from me.  So 
sending any such info in the ODF is useless and counter productive.
After all, if you receive a document with my name and a signature you don't 
have (because its false, for example) you might just think that since the 
name is OK, the document must be OK. And that silly computer doesn't know me.

In the end a gpg signature thus needs a gpg public key. And that key holds my 
name, email and other data like a picture (optional).
So, for your request all that is needed is support from the application, and 
its actually a bad idea to add ODF support for it.

Cheers!
-- 
Thomas Zander

Thomas,

I think you misunderstood Uri.

The signatures are W3C DSIG - no discussions about the format/content/PKI.

Uri didn't propose to add additional signer information to ODF.

He proposes to additionally add the possibility to have text fields or something like that, where the different elements of the signature(s) can be *displayed*.
See Adobe Acrobat, where you can spawn some area on the document, where you want data from your signature/certificate to be displayed.

Not a bad thing, IMHO.

Malte.




Thomas Zander wrote, On 02/20/07 15:52:
> On Tuesday 20 February 2007 15:03, Uri Resnitzky wrote:
>   
>> I would like to propose a functional extension to your proposal.
>> From our experience with digital signature for documents in the
>> marketplace and from looking at the digital signature functionality in
>> other document formats such as PDF and OOXML, I believe that visual
>> signatures are extremely important.
>> Your proposal creates invisible signatures in the sense that the
>> signature is not visible in the document content itself.
>> I think we should amend the proposal to include the option of adding an
>> interactive signature field (or signature line) to the document with the
>> ability to display in this field the graphical signature image of the
>> signer as well as other information (signer name, date/time, validity
>> marks).
>>     
>
> Any signature has, by nature, a reference to the name / email of the signer.
> If the signature is to be checked, that information needs to be present on the 
> computer of the one checking if the signature is relevant.
>
> This has the effect that if you get a signed document from me, you can only be 
> sure it is actually from _me_ by checking against your local key from me.  So 
> sending any such info in the ODF is useless and counter productive.
> After all, if you receive a document with my name and a signature you don't 
> have (because its false, for example) you might just think that since the 
> name is OK, the document must be OK. And that silly computer doesn't know me.
>
> In the end a gpg signature thus needs a gpg public key. And that key holds my 
> name, email and other data like a picture (optional).
> So, for your request all that is needed is support from the application, and 
> its actually a bad idea to add ODF support for it.
>
> Cheers!
>