843274 - Bugzilla encrypts secure mail to expired S/MIME certificates

Status: RESOLVED INVALID

(bugzilla.mozilla.org :: Extensions, defect)

Description

[:Atoll]

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=[e-mail]

Comment 1

[Gervase Markham [:gerv]]

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

Comment 2

[Reed Loden [:reed]]

(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.

Comment 3

[Gervase Markham [:gerv]]

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

Gerv

Comment 4

[:Atoll]

(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.

Comment 5

[Reed Loden [:reed]]

(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.

Comment 6

[Gervase Markham [:gerv]]

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

Comment 7

[:Atoll]

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++

Comment 8

[:Atoll]

> 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.

Comment 9

[Guillaume Destuynder [:kang] [this account is no longer active]]

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.

Comment 10

[David Lawrence [:dkl]]

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

Comment 11

[:glob ✱]

(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.

Comment 12

[:Atoll]

(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?

Comment 13

[Gervase Markham [:gerv]]

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

Comment 14

[:Atoll]

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