Open Bug 503530 Opened 16 years ago Updated 3 months ago

email messages signed before certificate revocation do not appear valid afterwards

Categories

(MailNews Core :: Security: S/MIME, defect)

Product:
MailNews Core
Component:
Security: S/MIME
Platform:
x86
All
Type:
defect

Tracking

(Not tracked)

Status:
UNCONFIRMED

People

(Reporter: kraynopp, Unassigned)

Details

Attachments

(2 files)

testcase for bug 503530
9.22 KB, application/octet-stream
Details
Screenshot with bug 503530
188.54 KB, image/jpeg
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.1) Gecko/20090624 Firefox/3.5 Build Identifier: 2.0.0.22 (20090605) The digital signature of message, signed before revoking of the certificate should be considered is valid. Reproducible: Always Steps to Reproduce: 1. Send signed message. 2. Revoke the certificate. 3. update CRL (if you do not use OCSP) 4. Receive message from mail server. Actual Results: The digital signature will consider as invalid. Expected Results: The digital signature should be valid. My certificate has "Trusted Timestamping" extention
I have tested Thunderbird 3 Beta 2 (Mozilla/5.0 (Windows; U; Windows NT 5.2; ru; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2). This version is also affected.
adding a few experts to get their advice.
Version: unspecified → Trunk
Have you tried to set env var NSS_ENABLE_PKIX_VERIFY=1 ? Just to check we haven't this already fixed in PKIX.
This discussion ignores the validity period of the revoked cert. I would agree with the reporter's premise, if it is modified to limit its scope to be during the validity period of the cert, e.g. > The digital signature of message, signed before revoking of the certificate > should be considered valid, *when examined during the certificate's validity period.*
I partially agree with Nelson Bolyard (:MisterSSL), but I have one question. What happens if message is signed using good, not revoked certificate, during certificate's validity period but signature of this message will be examined when the validity period is over? (For example, somebody analyzes his old archive of messages). I suppose, the signature should be considered as valid because of it has been made when the certificate was still valid. I suppose, signatures should be considered as invalid if the certificate used for signing is already invalid (expired or/and revoked). Maybe it will be better to reformulate in the following way: "The digital signature of message, signed before revoking of the certificate during the certificate's validity period, should be considered as valid." Please tell me if I am wrong.
I forgot to add: 1. All above should work only, and ONLY if certificate has "Trusted Timestamping" extended key usage (1.3.6.1.5.5.7.3.8). Without it you can not trust date and time when the signature has been made and all signatures should became invalid immediately after revokation or expiration the certificate. But my certificate has "Trusted Timestamping" extended key usage and should work as I wrote in my recent comment. 2. The MS Office 2003 can sign documents and I try to test this situation using this software. And I have found that everything is ok - signature that has been made before revokation of the certificate remians valid after revokation, but signature that has been made after revokation of the certificate consider as invalid.
After the sender's cert is expired, its issuer is no longer obligated to report on its revocation status. In general, we cannot ask questions about the revocation of a cert after it expires. Now, what Thunderbird *could* do, and im my opinion *SHOULD* do, is to record the observed validity of the message signature, each time it verifies that signature DURING THE CERT's VALIDITY PERIOD. Then after the cert is expired, Thunderbird would not make any further attempt to verify the signature, but instead would rely on the good/bad signature flag that it had previously recorded while the cert was unexpired. This scheme has the nice property that it relies only on the relying party's own clock, and hence does not need any timestamping services.
Yes, it will work with one little exception. What happens if the first examination of signature takes place during validity period, but when certificate is already revoked? Without trusted timestamping this signature will consider as invalid in any case and it is wrong.
Messages are already timestamped by Thunderbird with the time received using the recipient's local clock. This can eliminate all reliance on the sender's clock.
Hm... maybe. But I think the sender's clock is more important. I can receive signed message now, or in a month, or in a year after sending and this fact should not affect status of the signature if it has been made using good certificate. By the way you do not answer my question in comment #8.
In answer to question 8, during the certificate's validity period, the determination of the mail signature's validity should be based on a comparison of the date of the email (receiver's time, or sender's time only if trusted) and the date of revocation. It should already work that way. If not, that's a bug.
Excellent. Finally we could understand each other and I agree with you in your recent comment :) Unfortunately it does not work... To Honza Bambas (:mayhemer), back at full time!: I've tried to set env var NSS_ENABLE_PKIX_VERIFY=1 but without any effect, at least in Thunderbird 3 Beta 2. Thunderbird 3 Beta 3 does not show signature icon and terminates abnormally frequently...
(In reply to comment #12) > icon and terminates abnormally frequently... Can you file a new bug for that and gives us some breakpad ids (see http://kb.mozillazine.org/Breakpad) ?
I don't expect NSS_ENABLE_PKIX_VERIFY=1 to have any effect on this issue.
Component: Security → Security: S/MIME
Product: Thunderbird → MailNews Core
QA Contact: thunderbird → s.mime
Summary: Problem with messages, signed before revoking of the certificate → email messages signed before certificate revocation do not appear valid afterwards
kraynopp: would be great to have a test case (a message that should be valid). Could you please provide some? Nelson: I'm not actually sure where the code responsible for Time Signatures lies, can you give me an advice please?
archive contains: 1. cacert.pem. Certificate of root CA. 2. cert.p12. My certificate used for signing the message. Password: qwerty 3. test.eml. Signed message. 4. crl.crl. Certificate revokation list in der format. 5. crl.pem. Certificate revokation list in pem format (I am unable to import it due bug 200630. I hope this file will help to fix it).
Honza, set a breakpoint in CERT_CertTimesValid and then view a signed email. capture all the stacks. I think you'll find the answer to your question in one of them. If you'll add an attachment to this bug with the stacks you capture, I'll look at them.
This bug remains unconfirmed. A useful first step would determine if this can be reproduced, and if so, whether the problem is in NSS or not. Julien, I'd like you to look into it. If there is a bug, it may be in the revocation code, or in cert path validation, or in the CMS library (the misnamed libSMIME), or in Thunderbird's SMIME code.
Assignee: nobody → julien.pierre.boogz
kraynopp, The behavior depends on the time at which the message is getting verified. Thunderbird should attempt to verify the message at the time the message was written, not at the current time. NSS does not recognize the "trusted timestamping" extension, so that doesn't make a difference. If only CRL revocation is involved, the signature should be verified as valid if the signature date is before the revocation date. I will look at the test case.
I've checked ocsp code path. The ocsp legacy code correctly uses user supplied time to verify that the cert in question was valid in the past. Now, libpkix has the bug since it uses time from PR_Now to to establish cert validity. The bug 508467 is filed.
Alexei, Do we have any reason to think that Mozilla's email client is using libPKIX's OCSP code when checking email cert validity?
To Nelson: I am discouraged that the bug remains unconfirmed. The message has been sent in 18:50:55 (14:50:55 in UTC), the certificate hes been revoked in 15:01:02 in UTC. I am going to take and send a screenshot... To Alexei Volkov: Unfortunately I could not find any differences in behaviour of CRL and OCSP (from my user's point of view, of course). Signature verification remains wrong.
We check the cert chain before we check the CMS signature. CA is found invalid at NOW so, we claim the signature is invalid. It was introduced as simple 'rather false negative' solution in bug 324474. See the discussion there. This should be marked as WONTFIX according to it or we should properly implement '1.3.6.1.5.5.7.48.3 - timestamping' OID usage. Seems we know this OID in the code already: http://mxr.mozilla.org/mozilla-central/ident?i=PKIX_INFOACCESS_TIMESTAMPING http://mxr.mozilla.org/mozilla-central/ident?i=SEC_OID_PKIX_TIMESTAMPING
The behavior introduced by the "solution in bug 324474" sounds like a bug.
Those whole issue of verifying old signatures is well understood. The expedient of always testing for "now" is wrong. Let's stop trying to solve these problems with band-aid solutions, and do the right thing. See my comment 7.
(In reply to comment #21) > Do we have any reason to think that Mozilla's email client is using libPKIX's > OCSP code when checking email cert validity? Do not have any reason, although it would be easy to switch to use libpkix as it was suggested in comment #3. But since we have two code paths I've check them any way. (In reply to comment #24) > This should be marked as WONTFIX according to it or we should properly > implement '1.3.6.1.5.5.7.48.3 - timestamping' OID usage. Seems we know this OID > in the code already: > > http://mxr.mozilla.org/mozilla-central/ident?i=PKIX_INFOACCESS_TIMESTAMPING > http://mxr.mozilla.org/mozilla-central/ident?i=SEC_OID_PKIX_TIMESTAMPING Yes, we have OIDs, but these OIDs are for compatibility reasons. NSS lacks 'timestamping' support since we don't have strong case to implement the feature.
(In reply to comment #22) > To Alexei Volkov: > Unfortunately I could not find any differences in behaviour of CRL and OCSP > (from my user's point of view, of course). Signature verification remains > wrong. Neither ocsp nor libpkix is in a root of the problem. I'm not expecting the patch to fix your problem either. I did code review to assure NSS follows the specs during ocsp validity check of a cert.
Here is my evaluation using the command-line tools certutil and crlutil . a) importing the CA and user certs, but not the CRL [jp96085@monstre]/net/monstre/export/home/julien/nss/tip/mozilla/dist/SunOS5.10_i86pc_DBG.OBJ/bin 5 % rm *.db [jp96085@monstre]/net/monstre/export/home/julien/nss/tip/mozilla/dist/SunOS5.10_i86pc_DBG.OBJ/bin 6 % certutil -d . -N Enter a password which will be used to encrypt your keys. The password should be at least 8 characters long, and should contain at least one non-alphabetic character. Enter new password: Re-enter password: [jp96085@monstre]/net/monstre/export/home/julien/nss/tip/mozilla/dist/SunOS5.10_i86pc_DBG.OBJ/bin 7 % certutil -d . -A -i cacert.pem -t C,C,C -n CA [jp96085@monstre]/net/monstre/export/home/julien/nss/tip/mozilla/dist/SunOS5.10_i86pc_DBG.OBJ/bin 8 % pk12util -d . -i cert.p12 Enter password for PKCS12 file: pk12util: no nickname for cert in PKCS12 file. pk12util: using nickname: Pavel - Some-Company pk12util: PKCS12 IMPORT SUCCESSFUL [jp96085@monstre]/net/monstre/export/home/julien/nss/tip/mozilla/dist/SunOS5.10_i86pc_DBG.OBJ/bin 9 b) verifying the cert on 08/04 and 08/06 [jp96085@monstre]/net/monstre/export/home/julien/nss/tip/mozilla/dist/SunOS5.10_i86pc_DBG.OBJ/bin 9 % certutil -d . -V -n "Pavel - Some-Company" -u S -b 090804000000Z certutil: certificate is valid [jp96085@monstre]/net/monstre/export/home/julien/nss/tip/mozilla/dist/SunOS5.10_i86pc_DBG.OBJ/bin 10 % certutil -d . -V -n "Pavel - Some-Company" -u S -b 090806000000Z certutil: certificate is valid [jp96085@monstre]/net/monstre/export/home/julien/nss/tip/mozilla/dist/SunOS5.10_i86pc_DBG.OBJ/bin 11 % As expected, the cert is valid on both dates. c) importing and listing the CRL [jp96085@monstre]/net/monstre/export/home/julien/nss/tip/mozilla/dist/SunOS5.10_i86pc_DBG.OBJ/bin 11 % crlutil -d . -I -i crl.crl [jp96085@monstre]/net/monstre/export/home/julien/nss/tip/mozilla/dist/SunOS5.10_i86pc_DBG.OBJ/bin 12 % crlutil -d . -L CRL names CRL Type CA CRL [jp96085@monstre]/net/monstre/export/home/julien/nss/tip/mozilla/dist/SunOS5.10_i86pc_DBG.OBJ/bin 13 % crlutil -d . -L -n CA CRL Info: : Version: 1 (0x0) Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption Issuer: "CN=TestCA,OU=Some-department,O=Some-Company,ST=Some-State,C=RU" This Update: Tue Aug 04 15:02:04 2009 Next Update: Wed Aug 05 15:02:04 2009 Entry (1): Serial Number: 1 (0x1) Revocation Date: Tue Aug 04 15:01:02 2009 [jp96085@monstre]/net/monstre/export/home/julien/nss/tip/mozilla/dist/SunOS5.10_i86pc_DBG.OBJ/bin 14 % d) again verifying the cert on 08/04 and 08/06 . 08/04 is before the revocation date, 08/06 is after the revocation date. [jp96085@monstre]/net/monstre/export/home/julien/nss/tip/mozilla/dist/SunOS5.10_i86pc_DBG.OBJ/bin 15 % !9 certutil -d . -V -n "Pavel - Some-Company" -u S -b 090804000000Z certutil: certificate is valid [jp96085@monstre]/net/monstre/export/home/julien/nss/tip/mozilla/dist/SunOS5.10_i86pc_DBG.OBJ/bin 16 % !10 certutil -d . -V -n "Pavel - Some-Company" -u S -b 090806000000Z certutil: certificate is invalid: Peer's Certificate has been revoked. [jp96085@monstre]/net/monstre/export/home/julien/nss/tip/mozilla/dist/SunOS5.10_i86pc_DBG.OBJ/bin 17 % As expected, when verifying as of 08/04 - before the revocation date, the cert is valid. And when verifying as of 08/06, it is correctly seen as revoked. My conclusion is that NSS is doing the verification properly as instructed. The issue the poster is complaining about does not lie in NSS. It is most likely to the caller of CERT_VerifyCert verifying as of the current time, as opposed to the message signature's time.
Nelson, Re: comment 26, I think in the absence of secure time-stamping support, the solution chosen in bug 324474 - which is to consider all signatures revoked if the cert is revoked as of the current date - is actually reasonable. The reason is that there is no way to know when the signature was generated. If the key was compromised, it could simply be a backdated message. Unless and until we implement secure timestamping, I think it is OK to keep this compromise. The best we could do without it is to look at revocation reasons and treat cases of key compromises differently than other reason codes - and relax the check for other, less serious reason codes. But this is not a very good solution, IMO. Secure timestamping would be much preferable. IMO, with the current test case, where the signed message does not contain a secure timestamp, the behavior is correct. There is no bug in either NSS or PSM. If we want to improve the handling of old signatures, we should scope the work for implementing secure timestamping. I don't know what priority this work should be, but it is clearly RFE. I suspect there would be some work to do in Thunderbird, and some in NSS. I haven't looked closely at this subject before.
Just a note from a CAs point of view, a certificate which has been revoked shouldn't have been issued in first place. Except in case the private key of the cert was compromised at some point,any message signed by a revoked certificate shouldn't be valid even before the compromise and revocation of the certificate.
Eddy, Re: comment 31, if the private key was compromised, there is nothing to stop somebody from backdating messages with it. So it is actually the worst case when it comes to verifying old signatures.
Well yes. My point is that a revoked certificate shouldn't be trusted, not before and not after the date of actual revocation. The worst case however is a certificate which shouldn't have been issued in first place.
Nelson, Re: comment 7, Actually, if NSS supported the Archive cut-off extension, it would be possible for NSS to reliably ascertain the revocation status of certs after they have expired. Unfortunately, this extension is only defined for OCSP responses, not for CRLs :-( Archive Cutoff is defined in RFC2560 section 4.4.4 . I agree that Thunderbird could contribute to improving the situation by doing verifications of the cert before it is expired and recording the data. However, this might not be very reliable, especially if somebody is using IMAP and not always using the same computer. The info would have to be saved into a local database which would not guaranteed to be available. For this to be really useful, the client would have to be able to save the data along with the message so that it would always be available. I am not sure if IMAP allows a client to do that - it sure would be neat if it did. But it sounds more like a job for LDAP :-( Even if there is a network location to push the data, the scheme depends on the user reading the message and getting it verified up to a time shortly before the cert's expiration. It would certainly be an improvement over the current situation, but there could not be any guarantees. This could similarly be accomplished in NSS by having a persistent cache for OCSP responses, or storing multiple overlapping CRLs in order to have the largest scope of certs listed - but one would have to diff the CRLs in order to decide which full CRLs to keep. At that point, we are better off implementing delta CRLs in NSS, and storing them all from the oldest base CRL we have. However, doing this in NSS would suffer from the same problem as doing it in Thunderbird - a lack of a network location for this information to be fetched, and a lack of guarantees about the scope - unless we have a completely uninterrupted chain of delta CRLs up to the current time, but that is probably very difficult to guarantee.
Julien, re-read my comment 7.
Nelson, I re-read it, and I am not sure what you think I missed.
Maybe RFC 3852 (part 11.3) will be useful.
Re: comment 37, From that section : " No requirement is imposed concerning the correctness of the signing time, and acceptance of a purported signing time is a matter of a recipient's discretion. It is expected, however, that some signers, such as time-stamp servers, will be trusted implicitly."
(In reply to comment #38) Certainly. It means that recipient should decide if he can trust or can not trust the sender's local clock. I suppose he will trust. Unfortunately I do not know if any other method exists except trusted timestamping...
Just an idea: what about using the Received: header of the email? It contains time it come to certain servers and some of them might be taken as a temporary time authority. However, this doesn't really say when the message has been signed. The first machine in the list might be an attacker local server that spoofs the date or it simply went from the outbox much later then it was written. The last machine is often our provider or our local server, time stamp of those is closer to the receive time and not to the message creation time. Probably not the way either...
Please read comment 9. The recipient always trusts his local clock. See also comment 7. Once TB has evaluated the signature during the cert's validity period, it should remember the signature's status from then on, rather than continually rechecking it.
(In reply to comment #40) If you check your mailbox very infrequently, you can possibly rely on Received: header of the last machine on the list. It can be provider mail server or public mail server and it is online 24/7. So the date from header can be much closer to signing date than the date when the message is actually received by recepient. But I do not know if mail servers are obligated to synchronize local clocks with NTP service consequently I do not know if I can rely on local time of mail server. So I suppose Nelson is right, recipient can trust only his local clock, at least while TSA is not implemented... By the way, have you got any plan to implement utilizing of TSA?
I've read recently RFC 5126 "CMS Advanced Electronic Signatures (CAdES)". I suppose it is the most correct decision. What do you think?
Assignee: julien.pierre.boogz → nobody
Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: