Apache OpenOffice (AOO) Bugzilla – Issue 60875
Certificate key usage is not handled by the OpenOffice programs when sign a document digitaly
Last modified: 2013-08-07 15:31:14 UTC
The cerficate key usage is not handled in the Digital Sign feature, so it is possible, to sign a document with an encryption certificate. Reproduction: 1. Sign a document with an encryption certificate, (Key Enchipherment set) 2. It will be successful, so it is wrong. Solution: By the regarding RFCs and ETSIs, the Non-Repudation bit and/or Digital Sign bit should be set, for the signing certificate. Key Enchipherment should not allowed, or minimum should together with a Digital Sign. For qualified certs (EU): only Non-Repudation more info: RFC 3039 For other certificates: Non-Repudation and/or Digital Sign ( more info: ETSI TS 102 280 chapter 5.4.3 Key usage, table, Line A, B, C (the RFC overides the description of qualified, so only the A usable in qulified) Line D - not recommended, dread later Line E - for encryption D line - not recommended, because: 1) most of the EU contry laws are not allowing to use for digital signing a combined certificate. 2) ETSI security notes describes, for security reasons it is not recommended.
TM->FST: Please have a look, thanks !
Hi Joachim, please have a look at this one. Frank
Evaluate.
.
Retargeting to 3.x
Tested on OO 3 and still not working. Retargeting to OO4??? :)
This issue will probably be retargeted. In my opinion the current implementation is barely usable for a couple of reasons. What we need are requirements of the form: "The signature must comply with standard A in order to be legally accepted in country B." Because this is actually a huge task, i suggest that signature components may be developed by individual parties and OOo is improved to better integrate these components. Have a look at my OOo 2008 conference presentation: http://marketing.openoffice.org/ooocon2008/programme/friday_1419.odp
My opinion, to filter out the signer certificates with Key Enchipherment Key Usage. The separation of the encryption(EC), authentication(DS), and signing(NR) function came from a security problem. Please imagine it: case 1: You have a certificate with DS, NR, EC. You want to login on a webpage, and the server drops some random data to sign it. You sign it, then the server check the signature, and logins you, when it is correct. But if the server drops some patched data, not random, the server owner will have a signed document, which is signed with a certificate, where the allowed purposes includes non repudation (NR), so your "random data" was SIGNED for them. case 2: You have EC with NR bits. You can have an application, which simply sign with your encription certificate, of course, this is not a way, yo want, but you sign something, with a law acceptable certificate. case 3: You sing something with a EC certificate You signed it, because you want to make it an official document. But when you will use it, on the judge, you will found, oops, no really signeture on it. So you lost on the judge.
I agree that we should follow some standards here. If I remember correctly, the German Signature Act requires the use of the right key usage as well. Your #1 scenario could maybe apply for the case when OOo establishes a https connection and the server requires a client authentication. However, I am not sure if this is possible at all with OOo.
Yes, jl, you have right. I simply detailed the knowledge behind the separation of the certificates.