Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | Certificate key usage is not handled by the OpenOffice programs when sign a document digitaly | ||
---|---|---|---|
Product: | General | Reporter: | vargaviktor <viktor.varga> |
Component: | code | Assignee: | AOO issues mailing list <issues> |
Status: | ACCEPTED --- | QA Contact: | |
Severity: | Trivial | ||
Priority: | P3 | CC: | issues |
Version: | OOo 2.0.1 | Keywords: | security |
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Latest Confirmation in: | --- |
Developer Difficulty: | --- |
Description
vargaviktor
2006-01-20 12:28:19 UTC
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. |