OASIS Open Document Format for Office Applications (OpenDocument) TC

We've been discussing this on the list for a few days now.  I think we're 
getting a better feel for the scope of what needs to be done, thanks to 
David's recent notes. . But I haven't seen a specific proposal yet.  I'm 
having some IBM colleagues look at this issue as well, since it is outside 
of my expertise.  But I will comment quickly on what our options are at 
this point:

1) Continue discussing and delay ODF 1.2 until we have a resolution.

2) Continue discussing, send ODF 1.2 out for public review knowing that 
this issue is open, and commit to resolving it when the public review 
ends.  But know that changes made after the public review would trigger 
another 15-day public review of those changes.

3) Remove the feature from ODF 1.2.

4) Do nothing in ODF 1.2, but address this area in a future revision.

5) Convince ourselves that there is not a problem ;-)

Are there any other options I've missed?

I think if we have the right people looking at this area, we should be 
able to resolve it in ODF 1.2.  So to me that sounds like option #1 or #2. 
 

Since the digital signature feature is not broadly entangled in the other 
features of ODF 1.2, I think it can be reviewed and revised without 
invalidating the review performed on other parts of specification.  So I'm 
inclined to recommend that we pick option #2. 

I reminded of the saying, 'Never code standing up', meaning if you are in 
a rush to leave the office, and you already have your hat on, and you are 
making one last change to the code while standing up to put on your coat, 
then you are asking for trouble.  I think we want to also avoid specifying 
security-related ODF features standing up.  Let's take a couple of months, 
during the public review of ODF 1.2, to figure out exactly what needs to 
be done here.  This will allow us to continue discussions at a deliberate, 
but unrushed pace.  We could continue discussions on the main TC list.  Or 
if we wanted to have a separate list and maybe a series of meetings on the 
subject (yes, more meetings) we could choose to form a "ODF Security 
Subcommittee".

Any thoughts on the process side of this, before we get back to discussing 
the details of XAdES?  In particular, any objections to #2?

-Rob

I have been attempting to avoid making specific proposals, because I do not feel like it is truly my place to define the standard. However, given that I'm the one person here who has actually written the code to create and verify xmlDSig and XAdES signatures, perhaps it would be good to put a proposal on the table, and then we can get the other implementers to comment and provide direction. I do not yet know the precise language for the document format, so please forgive me if I use incorrect terminology. For example, I see files in a zip archive. We refer to these as 'parts' in OOXML - I'll call them files below until I'm corrected, ditto with folders.

1) An ODF document signature shall be created using a signature as specified in [xmldsig]. An implementer is encouraged to support extensions as defined in [xades].

2) A document signature shall be created by signing the files contained within the archive based upon the unencrypted content of each file. A document signature may sign all or a portion of the document. If all of the document is to be signed, all files within the archive, excepting files contained within the META-INF folder, shall be contained within the signature by creating a Reference element for each as defined in [xmldsig].

3) A document signature shall be placed within the document-signatures element in the META-INF\documentsignature.xml file. A non-document signature may be created and placed in META-INF in a file to be defined by the implementer.

4) A KeyInfo element, as specified in [xmldsig], section 4.4 shall be present. The KeyInfo element shall contain an X509Data element containing at least an X509IssuerSerial element specifying the issuer and serial number of the signing certificate, and an X509Certificate element specifying the full signing certificate. Additional X509Certificate elements may be placed in the X509Data, or may be placed in the CertificateValues element of the XAdES Object, as defined in [xades] section 7.6.1. The additional certificates should represent the entire primary certificate chain used at signing time. [NOTE: This codifies what OOo is doing now.]

5) The Reference elements specifying the hash of each signed file within the archive shall contain a Type attribute specifying the type of data which is signed. [ NOTE - this needs refinement] Files contained within the archive shall have paths with a root established at the root of the archive, and shall have a Type of [ something specific to ODF here]. Reference elements with other Type attributes shall be considered to have a URI as defined in [xpath]. A Reference to an Object element within the Signature should have a Type attribute of "http://www.w3.org/2000/09/xmldsig#Object", and the Reference element specifying the hash of the XAdES SignedProperties element (if present) shall be as specified in [xades] section 6.3.1. [NOTE: This is a proper solution to the path resolution problem.]

5a) [TO BE DISCUSSED] Alternately, Reference elements specifying the hash of archive files may be placed in a Manifest element contained within an Object element, and it is implied that the paths shall refer to files contained within the archive, and the URI path shall be resolved from the root of the archive. [TBD - need to create a way to uniquely identify this Object]

6) The only permitted Transform elements which apply to files contained within the archive shall be canonicalization transforms, as specified in [xmldsig], section 6.5. [Note - mayhem can ensue if you allow an XLST transform, and you can end up signing odd things and throwing parsers into infinite loops - this is an important restriction.] A canonicalization Transform MUST be specified for all XML files.

7) The signing time shall be specified in the [Object you already create - #include 

David,


nice work, I'll give it some thought.

One small remark:

> 2) (...) If all of the document is to be signed, all files within the archive, excepting files contained within the
> META-INF folder,  shall be contained within the signature by creating a Reference element for each as
> defined in [xmldsig].

Manifest.xml is also in META-INF, probably it should read

"except the file within the META-INF folder containing the signature"


Mvg,

Bart

PS: Rob, option #2 (send ODF 1.2 out for public review knowing that this issue is open, and commit to resolving
it when the public review ends) sounds good. I assume there will be (non-signature related) remarks anyway,
so that would probably lead to another 15-day review anyway.

Good catch, but this poses some difficulties. First is that it precludes ever encrypting a document after it is signed, as an encryption operation will write the manifest file. However, the existing encryption approach has a number of flaws, some serious, and this could be fixed if the encryption approach were updated. I'll put together a detailed proposal on that soon. This gotcha may be the cause of the mistake of not encrypting the documentsignatures.xml.

If you do not sign the manifest file, which would be another (quite bad) choice, then you're open to some fairly serious attacks where what's signed and what's rendered could be quite different.

The issue I was thinking of when I made that exclusion was that some servers may want to change benign metadata which is outside the signature. If everything were signed, then this would break the signature in one way or the other - if the metadata existed at signing time, then the server would break the signature, if not, then an evaluation of the signature would find that things were missing, and may choose to declare it a partial or even invalid signature. OOXML files run into the issue of benign metadata being added or edited with SharePoint, and I was thinking that other document repositories may have similar behaviors.

Perhap it needs to read:

If all of the document is to be signed, all files within the archive, excepting files contained within the META-INF folder, shall be contained within the signature by creating a Reference element for each as defined in [xmldsig]. The manifest.xml file within the META-INF folder shall be signed. Other files within the META-INF folder may be signed.

________________________________________
From: Hanssens Bart [Bart.Hanssens@fedict.be]
Sent: Sunday, May 09, 2010 11:07 AM
To: David LeBlanc; robert_weir@us.ibm.com; office@lists.oasis-open.org
Subject: RE: [office] What to do about digital signatures

David,


nice work, I'll give it some thought.

One small remark:

> 2) (...) If all of the document is to be signed, all files within the archive, excepting files contained within the
> META-INF folder,  shall be contained within the signature by creating a Reference element for each as
> defined in [xmldsig].

Manifest.xml is also in META-INF, probably it should read

"except the file within the META-INF folder containing the signature"


Mvg,

Bart

PS: Rob, option #2 (send ODF 1.2 out for public review knowing that this issue is open, and commit to resolving
it when the public review ends) sounds good. I assume there will be (non-signature related) remarks anyway,
so that would probably lead to another 15-day review anyway.

On 10 May 2010 00:07, David LeBlanc 

>> If all of the document is to be signed, all files within the archive, excepting files contained within the META-INF folder, shall be contained within the signature by creating a Reference element for each as defined in [xmldsig]. The manifest.xml file within the META-INF folder shall be signed. Other files within the META-INF folder may be signed.

>David this is a comprehensive proposal in a short time.  Nice work.  I like it.

Thanks very much - perhaps those many hours writing MS-OFFCRYPTO will turn out to have some benefit outside that document. I'd very much like to get to a point where we can get signing into the standard so that I can work toward getting it implemented in our apps.