298664 - Firefox installs signed xpi although certificate is expired

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Installer: XPInstall Engine, enhancement)

Description

[Karsten]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

I tried the 'Simple Signed XPI Testcases' on
http://www.mozilla.org/projects/xpinstall/signed/testcases/. The certificate
used for signing is valid from Nov 2002 up to Feb 2003.

When I set my windows system date to Jan 2003, everything works at it should.
The xpi file gets installed properly.
But when I change my windows date to today (June 2005) the signed.xpi still gets
installed although the certificate is expired. There's no warning.

Reproducible: Always

Steps to Reproduce:
1. Go to http://www.mozilla.org/projects/xpinstall/signed/testcases/
2. Install the x509.cacert and set it to "certificate can identify software
markers" and "certificate can identify websited"
3. Make sure your system date is later than Feb 2003 (Normally it is.)
4. Install signed.xpi from the above website. It will be installed although the
certificate is expired.



Expected Results:  
At least there shoud be a warning that the certificate is expired or the
installation should not be done.

Comment 1

[Daniel Veditz [:dveditz]]

Ben cc'd the wrong NelsonB

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

Two nelsonb's ?!?  Oh no!  :)

Presently, when verifying a signature, NSS checks to see if the cert was 
valid on the date of the signature, not on today's date.  This behavior
is intentional, that is, is as designed, and therefore is not a "bug"
per se.  

One can argue that this is a bad design choice.  There is generally no way
to check for revocation of expired certs.  So, after the date of expiration,
one generally cannot check to see if the cert was already revoked as of the
date of the signature.  (And of course, signature dates can be falsified.)

The alternative, of always checking to see if the cert is expired as of 
today's date (that is, on whatever date the signature is being verified)
will cause all signatures to have no validity past the cert's expiration 
date.   

The design choice was made with signed email in mind.  The thought was that
if someone receives a signed email whose signature is bad while the cert is
unexpired, one will likely not preserve the email.  An email preserved long
after the cert has expired is likely one the user has previously chosen to 
treat as valid upon seeing it the first time, whether or not the signature
is valid at that time.  Perhaps this logic is less applicable to signed 
objects (downloaded JAR/XPI files).

In any case, this "bug" is essentially a request to reconsider the design
choice, and as such is an enhancement request (RFE).  I confirm that it's
an enhancement request, but pass no judgement on the worthiness of the 
request.  The decision rests with the owner(s) of PSM and/or FireFox.  

Note that no NSS code change is required to implement this RFE.  
The application that uses NSS tells NSS what date to use for verification
purposes.  It may choose to use PR_Now (present date/time) or another date 
of its choosing.  Presently (IINM) PSM's email code uses the date/time in 
the message.  

Comment 3

[Robert Strong (they/them - no direct email)]

Core -> XPInstall

Comment 4

[Mike Kaply [:mkaply]]

Just found this bug and I humbly disagree.

Whether or not a cert is currently expired has no bearing when the XPI is installed.

Signing an XPI is about a point in time.

When the XPI was signed, the cert was valid.

Taking this outside of XPIs, if I sign an installer and my company goes out of business, it doesn't mean people shouldn't be able to install my old software just because I didn't renew my cert.

Comment 5

[Dave Townsend [:mossop]]

(In reply to Michael Kaply (mkaply) from comment #4)
> Just found this bug and I humbly disagree.
> 
> Whether or not a cert is currently expired has no bearing when the XPI is
> installed.

It means we can no longer trust that the signer is who they appear to be.

> Signing an XPI is about a point in time.
> 
> When the XPI was signed, the cert was valid.

We have no way to know that. I can sign an XPI with an outdated cert quite easily.

> Taking this outside of XPIs, if I sign an installer and my company goes out
> of business, it doesn't mean people shouldn't be able to install my old
> software just because I didn't renew my cert.

But it does mean that the name presented may not be accurate. Imagine if some other company started operating under the same name as your old company. If you present the outdated cert name as valid then the user wouldn't know which company signed it (and would probably assume the current company).

Comment 6

[[Baboo]]

(In reply to Michael Kaply (mkaply) from comment #4)
> 
> Taking this outside of XPIs, if I sign an installer and my company goes out
> of business, it doesn't mean people shouldn't be able to install my old
> software just because I didn't renew my cert.

I could see this as a counter-argument: If a company goes out of business, can you trust it to protect the private key? After all, nobody there might care what happens with it, nobody might feel obliged.

Comment 7

[Mike Kaply [:mkaply]]

In wonder what Windows does with an EXE install with an expired cert? I guess i've never encountered that.

I guess the question becomes does expired cert == invalid cert == incorrectly signed cert.

Should I user not be able to install with an expired cert? Or just told it is expired? Or should it just show the standard "unknown" since the identify can't be verified.