Apache OpenOffice (AOO) Bugzilla – Issue 103420
Enable revokation checking
Last modified: 2017-05-20 10:24:13 UTC
There is no OCSP/CRL checking performed during verification of documents (signatures made with revoked certificates appear to be valid for OpenOffice). In Windows everything is ok, Linux version is affected.
.
Accepted and setting target.
*** Issue 103444 has been marked as a duplicate of this issue. ***
Revokation checking should be implemented for all platforms.
*** Issue 63537 has been marked as a duplicate of this issue. ***
I am sorry for disturbance, but please take into consideration one moment from closed issue 103444. My certificate has "Trusted Timestamping" extended key usage (1.3.6.1.5.5.7.3.8) so users should trust the date and time when the document has been signed. Consequently if document signed when the certificate still valid, the signature should be considered as valid even after revokation of the certificate.
Time stamps are not supported yet. In the end it depends on what algorithm is used to validate a signature. It would be good if one could tell exactly to what specification or rules the algorithm conforms to. For example one could say the algorithm implements RFC 3280 or conforms to the German Signature Act, etc.
Maybe another decision exists. The fact is that the OCSP responder must return the date and time of revokation (for revoked certificate, of course). The CRL must include this information also. Unfortunately digital signature does not include the information when the document has been signed. At least I could not be able to find it but you do (or find another way). In the window where all signatures listed I find the date and time when the document has been signed (last column). I suppose if you compare this information with date and time when the certificate has been revoked (from OCSP response or CRL, I prefer OCSP) it will be enough to make right decision about status of signature.
Maybe RFC 3852 (part 11.3) will be useful.
By the way have you got any plans to implement trusted timestamping? If yes, maybe RFC 5126 "CMS Advanced Electronic Signatures (CAdES)" will be useful (especially part 5.11). This RFC contains example validation sequence also. I'll be glad if this information will help you.
Thanks for the information. CAdES is indeed very interesting. However, I would not implement it (or parts of it) myself. I'd rather use an external library, which is already well tested.
I suppose Bouncy Castle Crypto API for java (http://www.bouncycastle.org/java.html) can support CAdES. At least some elements of RFC 3126 (predecessor of RFC 5126) are implemented. Anyway developers of this library can answer exactly.
Change to 'defect'. If the revokation status cannot be checked then the validation must fail. Only if one can determine that the certificate is NOT revoked, then the certificate can be valid (RFC 3280, 6.1.3 Basic Certificate Processing).
@HI: Please verify. As a first step the verification will disregard missing revocation information and only use available information (crl, clr distribution point, AIA OCSP). We will later create a setting in the options dialog where the user can switch on strict revocation checking.
Verified with cws jl137= OK Signature gets valid or invalid regarding the given revocation list. Tested locale, with ocsp responder and http server