My account has a configured S/MIME certificate that expired in October 2012. However Bugzilla continues to encrypt secure mail to it. Certificate: Data: Version: 3 (0x2) Serial Number: 33:21:fd:84:a9:10:c1:f2:ba:34:a7:79:8c:7c:5a:38 Signature Algorithm: sha1WithRSAEncryption Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at https://www.verisign.com/rpa (c)09, OU=Persona Not Validated, CN=VeriSign Class 1 Individual Subscriber CA - G3 Validity Not Before: Oct 23 00:00:00 2011 GMT Not After : Oct 22 23:59:59 2012 GMT Subject: O=VeriSign, Inc., OU=VeriSign Trust Network, OU=www.verisign.com/repository/RPA Incorp. by Ref.,LIAB.LTD(c)98, OU=Persona Not Validated, OU=Digital ID Class 1 - Netscape Full Service, CN=Richard Soderberg/emailAddress=rsoderberg@mozilla.com

I'm not entirely sure this is a bug. After all, you configured the cert - we are just assuming you know what you are doing :-) Gerv

(In reply to Gervase Markham [:gerv] from comment #1) > I'm not entirely sure this is a bug. After all, you configured the cert - we > are just assuming you know what you are doing :-) This is definitely a bug, as it violates how PGP encryption works. I would figure the same issue applies to S/MIME certificates.

You mean the PGP standard requires a client to refuse to encrypt a message to an expired key? Gerv

(In reply to Gervase Markham [:gerv] from comment #1) > I'm not entirely sure this is a bug. After all, you configured the cert - we > are just assuming you know what you are doing :-) I use S/MIME exclusively for Bugzilla secure mail and had no idea that my key expired months ago. Neither my OS, my mail client, nor my browsers offered any warning that the key had expired. (In reply to Gervase Markham [:gerv] from comment #3) > You mean the PGP standard requires a client to refuse to encrypt a message > to an expired key? I don't believe it's sensible for secure bugmail to be encrypted to a key that can be provably be verified as expired, even if we are permitted to for whatever technical/implementation reasons.

(In reply to Gervase Markham [:gerv] from comment #3) > You mean the PGP standard requires a client to refuse to encrypt a message > to an expired key? GPG at least enforces this. Not sure if the PGP standard actually states it. However, PGP != S/MIME, but I would figure the same thing applies.

Well... what would you like us to do when we hit this situation? We can't throw an error; the poor person modifying the bug is probably not the person with the bogus key. Would you like us to replace each bugmail with an unencrypted "please refresh your key" bugmail? Gerv

When Secure Mail doesn't have a key configured, it sends a message saying "A secure bug was updated. Click here to view it.". Adding "Your Secure Mail encryption key expired on YYYYMMDD, click here to update it." to that mail is an excellent idea, gerv++

> When Secure Mail doesn't have a key configured, AND the bug is in one of the security groups that refuses to send plaintext bugmail updates, such as infra-security or client-security.

I think the mail is a good solution. Additionally, I'm not sure if this warrant a new bug, and I haven't checked this, but gpg key revocation should also be checked for similar reasons. (ie not just expiration). The main reason is that users expect that a revoked or expired key is unusable - and not used. However, if the mail is encrypted regardless of revocation or expiration status, and sent, anybody with the key can decrypt it. (This is not a concern for signing, where confidentiality is not necessary, and the recipient will see the signature is incorrect. It is an issue for encryption.) If you want me to check-revoke a key and open a new bug for it, let me know.

Just an implementation comment: We could get this function by using Crypt::OpenSSL::X509 which can look at the expiration date in seconds and compare to the current date in seconds. This can then give us whether the cert has expired or not. -- use Crypt::OpenSSL::X509; my $cert = Crypt::OpenSSL::X509->new_from_string($cert_string_from_bugzilla); if (!$cert->checkend(time())) { # Add error to email stating cert has expired } -- What if we continued to encrypt the email with the expired cert but yet add a noticeable error message to the email stating it has expired and needs to be updated? If we wanted to go further, we could set a cut off date and then not encrypt after the cert has been expired for some length of time. The email would just be the prior error message stating the user needs to update their cert. dkl

(In reply to David Lawrence [:dkl] from comment #10) > What if we continued to encrypt the email with the expired cert but yet add > a noticeable error message to the email stating it has expired and needs to > be updated? i don't think this is a good idea; as soon as the certificate has expired we shouldn't use it anymore (ie. that date _is_ the cut off date). i think gerv's suggestion, summerised by comment 7, is the right way to go. to make this easier for people to manage, we should also show minimal certification information on the preferences tab -- we probably need just the email address, issuer, and expiry date.

(In reply to David Lawrence [:dkl] from comment #10) > What if we continued to encrypt the email with the expired cert but yet add > a noticeable error message to the email stating it has expired and needs to > be updated? I think this is a bad idea. It would encrypt secure content to expired certificates, and remove the sole compelling reason to update to a newer certificate. > If we wanted to go further, we could set a cut off date and then not encrypt > after the cert has been expired for some length of time. The email would > just be the prior error message stating the user needs to update their cert. When it's not a busy month, my average time between secure mails from Bugzilla varies from 1-3 months. Is it possible to add a one-line banner to secure messages starting a short time before expiration, rather than waiting until expiration to say anything to the user?

Crypt::SMIME, the library we are using, appears to provide no way of determining the expiry date of a key. http://search.cpan.org/~mikage/Crypt-SMIME/SMIME.mlpod Neither, as far as I can see, does Crypt::OpenPGP: http://search.cpan.org/~btrott/Crypt-OpenPGP-1.06/lib/Crypt/OpenPGP/Key.pm If anyone can show otherwise, I'd love to know. Otherwise fixing this would require either implementing our own parsing, or a complete re-engineering of SecureMail to use different crypto libraries, neither of which seems like a good idea. Gerv

I don't really care about this enough to pursue it further, closing.