Closed Bug 413375 Opened 17 years ago Closed 8 years ago

define policy for certs in nssckbi that are expired, non-CA, non-root, and/or improperly encoded

Categories

(CA Program :: CA Certificate Root Program, task)

Product:
CA Program
Component:
CA Certificate Root Program
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: nelson, Assigned: hecker)

References

(
URL
)

Details

Attachments

(1 file)

Thunderbird message security with expired sign/crypt cert and missing root
52.48 KB, image/png
Details 
Mozilla.org's CA cert policy anticipates rejection/removal of CA certs for 
cause, that is, for CA malfeasance, but it does not explicitly address 
other more mundane issues that might be cause for modification of the 
existing certs presently in nssckbi.  Some of those issues are listed below.
Most of these issues occur in the course of "routine maintenance". 

In the absence of stated policy for these issues, Mozilla developers are left to wonder if contemplated maintenance actions will cause controversy or be 
seen as improper.  A stated policy would enable developers to act with 
relative confidence in many circumstances that are now murky.  So I request
that Mozilla's policy be extended to cover the following issues.

It is presently Mozilla.org's policy that only root CA certs may be added
to NSS's read-only cert store PKCS#11 module, nssckbi.   However, the policy published at http://www.mozilla.org/projects/security/certs/policy/index.html does not state this anywhere, and exceptions to that rule are presently being considered for EV.  

There are a number of non root-CA certs presently in nssckbi that were 
placed there before Mozilla's present policy was enacted. They include intermediate CA certs, OCSP responder certs, and perhaps others, that would 
not be accepted for inclusion into nssckbi if a request to do so was made today. The published policy does not address these "grandfathered" certificates.

Some certs in nssckbi have already expired.  We have no explicit policy 
governing the removal of certs due to their expiration.  Presently the
NSS developers (or some of us) wish to preserve expired root CA certs 
for some period of time after expiration, but we have not defined any 
time limit, so presently we are keeping expired root CA certs indefinitely.

There are some certificates in nssckbi that have been found to be improperly
encoded, that is, not strictly encoded according to the ASN encoding rules 
defined in the relevant standards (e.g. RFC 3280).  Some of these certs are
among the "grandfathered" certs, certs that would not be accepted for 
inclusion into nssckbi if such inclusion was requested today. 
Should they be removed? replaced?  The published policy does not address 
these questions.
Blocks: 413379
Nelson: would you and the NSS team care to propose a policy for each of these areas? I could dream one up, but it seems to make much more sense for you guys to suggest something sensible. (Even if we don't officially enshrine it in a document, the fact that we've all agreed on it will give some confidence.)

Gerv
I would also suggest to include a comment period just in case someone feels that the candidates for removal are still needed for some reason.
Regarding the issue of including non-root CA certs, I guess I'd like to better understand why the non-root CA certs in question were added in the first place, if anyone happens to know this. Was it simply to avoid the problem of misconfigured servers not sending full cert chains, or were there some other reasons?

Also, there are some edge cases we need to think about. For example, as I understand it the new VeriSign EV CA cert ("VeriSign Class 3 Public Primary Certification Authority - G5", proposed for inclusion per bug 402947) is intended to act as an intermediate CA cert in some contexts and as a root cert in others, in order to address certain legacy issues. Any policy change will have to address cases like this.

Regarding expired CA certs, what is the rationale for retaining them? Is this connected to the issue of verifying signatures on old email messages where the EE cert has expired, and possibly the CA cert as well?

Regarding improperly encoded CA certs, what technical problems (if any) might result from retaining them?
Status: NEW → ASSIGNED
CA certificate life cycle management is usually designed in such a way that no subscriber or subordinate CA remains valid after expiration of the CA root. Even if the root is removed, email messages can still be read, provided that the original key exists. In any case would have the digital signature be invalid (and produce a warning) because A) the CA root expired, B) the subscriber certificate expired or most likely both of them. The effect would be the same in any case.

In any case I'd suggest to have a small removal policy for these special cases in place outside of the current Mozilla CA policy. I also think that just an unwritten understanding as Gerv suggested isn't enough.

BTW, I wanted to ask, if there are CA roots from CAs which aren't active anymore?
In reply to comment 3:
good questions, Frank.

1. Why were the non-root CA certs included?
   Short answer: because the CAs asked us to do so, and we had no policy 
   regarding the subject.  IIRC, the servers in question were operated by
   the CAs themselves (they were OCSP responders), so perhaps it was to 
   workaround misconfiguration of the CAs' own servers.  That seems like 
   a bad reason to me.  Perhaps we should ask the CAs' rep's why.

2. There are some CAs whose public keys appear in multiple certs.  We might
see two separate certs, both with the same subject name and same public 
key, but one is a self-signed root and the other is an intermediate CA.
The CA appears to be both a root and an intermediate, in different certs,
but the certs themselves are unambiguous, either root or intermediate, but 
never both.  

3. rationale for retaining expired root certs.  I see two:
a) verifying signatures on old emails, 
b) retroactively investigating problems reported with certs, after the 
issuer has expired (a convenience to NSS developers).

I think the right solution to the issue of signatures on old emails is for 
Thunderbird to record in the message itself, in the folder, that the siganture
was verified while the cert was unexpired, and to rely on that local record,
rather than on the signature itself, after the cert chain expires.  But that
change won't happen soon, and until it does, I'd like to keep the old roots.
This rationalle would apply only to roots that are trusted for email.

4. improperly encoded certs.  In the immediate case, the improper encoding is 
in the extension used to identify the OCSP responder.  So, one might expect
OCSP validation failures because of it.  I think having an incorrectly encoded
extension may be worse than having no extension at all in that respect. 
Eddy, IIRC, presently Thunderbird does not decrypt messages if the encryption
cert is invalid.  So encrypted messages cannot be read after the issuer 
expires unless the issuer is renewed, IIRC.  I'm not sure about that.
With invalid cert you mean also expired subscriber certs? I can read mail of expired certificates at least.
Actually I tried to yank my own roots from TB but annoyingly the builtin tokens come back after restart. Pretty persistent this stuff ;-)
In reply to comment 1, here is a proposal for some policy refinements.
This is a strawman, a starting point for further proposals.

1) regarding addition of certs to nssckbi: The policy will state that 
only certs that are to be used as "trust anchors" may be added to the list.
This includes self-signed roots, and may include certain "bridge CA" certs, 
intermediate CA certs that bear the same public key and subject name as 
other trusted root CA certs, which we choose to treat like roots for 
purposes of enforcing certificate policy extensions.

2) regarding removal of certs for no cause other than expiration, the policy will state that:
a) removal of expired non-root CA certs may commence at any time after the date/time of their expiration plus 24 hours.  That is, removal may commence 
24 hours after the date/time of expiration,  
b) removal of expired root CA certs that were NOT trusted for email may 
commence 1 calendar year after the date/time of expiration,
c) removal of expired root CA certs that were trusted for email may commence
5 calendar years after the date/time of expiration

3) regarding certs that are disqualified for causes other than expiration or other technical reasons such as improper encoding (e.g. causes such as CA malfeasance), the policy will state that certs will not be immediately removed, but rather will be marked as explicitly and expressly DIStrusted.  

This is a stronger response than merely removing a cert, because a merely 
absent root cert can easily be replaced by importing it into the cert DB.  

Expressly distrusted certs would be kept, with the mark of explicit distrust, 
for at least 5 years after the date of expiration.

4) regarding certs that are found to have a technical problem, such as improper encoding that interferes with proper cert validation, the policy would state that:
a) non-root CA certs may be removed (and not replaced) at any time that their
presence is deemed to cause a problem for the proper operation of Mozilla 
products.
b) root CA certs may be removed at any time that their presence is deemed to cause a problem for the proper operation of Mozilla products.  Replacement 
with newer root CA certs may be handled the same as any application for the
inclusion of a new root CA cert.
Let me attempt to clarify point 3 in comment 8.  I meant to describe certs 
that we wish to remove at some time after they have been accepted and 
included in the root list, for reasons of "cause", such as CA malfeasance, 
but excluding these reasons:
a) expiration
b) improper encoding, or other mere technical problems.
Concerning 4b, I think in that case Mozilla should work with the CA in question and establish a plan and time frame for a replacement, i.e. go through the proper channels for a new CA root certificate and discontinuation of the offending root thereafter. Obviously it somewhat depends on the severity of "the problem to the Mozilla product" and if the CA root was accepted according to the Mozilla CA policy.
Nelson: looks good to me.

Gerv

(In reply to comment #6)
> Eddy, IIRC, presently Thunderbird does not decrypt messages if the encryption
> cert is invalid.  So encrypted messages cannot be read after the issuer 
> expires unless the issuer is renewed, IIRC.  I'm not sure about that.

I just went through my old sent messages and found one I sent in April 2006 that is both signed and encrypted.  The signature is shown as invalid but the message is still completely readable as I still have the old private key.  The cert expired in Aug 2006.  So just to be clear, you can still read old signed and encrypted messages, provided you still have the private key.


Yes, this is what I know, however Nelson said, that if the CA root is removed than one can't read encrypted messages even when you have keys. I can't confirm either behavior right now.
I deleted the CACert root CA certificate and then viewed an old signed and encrypted message.  The image shows the results from various Thunderbird dialogs.  It's interesting how in one dialog it says the signature doesn't validate because the root is missing/untrusted and then on another because the cert is expired.
That's what I expected. If this is confirmed, than remove of expired CA roots don't have to be dragged for 5 years and one year is sufficient (preferred in my opinion).
(In reply to comment #8)
> In reply to comment 1, here is a proposal for some policy refinements.
> This is a strawman, a starting point for further proposals.

Thanks for writing this proposal.
 
> 1) regarding addition of certs to nssckbi: The policy will state that 
> only certs that are to be used as "trust anchors" may be added to the list.

This sounds reasonable, as long as we have a suitable definition of the term "trust anchor". Speaking of which...

> This includes self-signed roots, and may include certain "bridge CA" certs, 
> intermediate CA certs that bear the same public key and subject name as 
> other trusted root CA certs, which we choose to treat like roots for 
> purposes of enforcing certificate policy extensions.

...does the above define "trust anchor" in your opinion, or do we need some additional and/or different language?

> 2) regarding removal of certs for no cause other than expiration, the policy
> will state that:
> a) removal of expired non-root CA certs may commence at any time after the
> date/time of their expiration plus 24 hours.  That is, removal may commence 
> 24 hours after the date/time of expiration,

By "non-root CA certs" are you really referring to certs that are not "trust anchors"?
  
> b) removal of expired root CA certs that were NOT trusted for email may 
> commence 1 calendar year after the date/time of expiration,

This sounds reasonable to me (although, again, I presume you mean "trust anchors", not just root certs). Clearly with SSL certs there is no need for a grace period. With object signing certs I guess there's at least the theoretical possibility of a signed object being downloaded at some point after expiration of the CA cert; I don't see this as a major issue that would warrant extending a grace period. 

> c) removal of expired root CA certs that were trusted for email may commence
> 5 calendar years after the date/time of expiration

I'll defer comment on this until we have a truly definitive answer on what the impact is on reading of old email after an expired CA cert is removed.

> 3) regarding certs that are disqualified for causes other than expiration or
> other technical reasons such as improper encoding (e.g. causes such as CA
> malfeasance), the policy will state that certs will not be immediately removed,
> but rather will be marked as explicitly and expressly DIStrusted.  
> 
> This is a stronger response than merely removing a cert, because a merely 
> absent root cert can easily be replaced by importing it into the cert DB.  
> 
> Expressly distrusted certs would be kept, with the mark of explicit distrust, 
> for at least 5 years after the date of expiration.

So, just to be clear on this point: What you are proposing is that if we disable a root CA cert/trust anchor for malfeasance or other factors that might have an impact on user security, users would have no option to override that decision, except to build their own version of NSS, Firefox, etc., with the trust flags re-enabled. Is this correct? If so, I think we need to discuss this further.

> 4) regarding certs that are found to have a technical problem, such as improper
> encoding that interferes with proper cert validation, the policy would state
> that:
> a) non-root CA certs may be removed (and not replaced) at any time that their
> presence is deemed to cause a problem for the proper operation of Mozilla 
> products.
> b) root CA certs may be removed at any time that their presence is deemed to
> cause a problem for the proper operation of Mozilla products.  Replacement 
> with newer root CA certs may be handled the same as any application for the
> inclusion of a new root CA cert.

I think for the second case (removal followed by replacement) we need to explicitly allow for some sort of transition plan to minimize impact on the change. I'm not exactly sure of the best way to approach this.

With regard to expired certificates involved in either E-mail or code-signing, they should be retained indefinitely.  This would follow the practice followed with OpenPGP in which public key servers retain both expired and revoked keys.  That is because (as indicated in the comments on this bug) such keys can still be used to verify signatures and decrypt messages that were signed or encrypted when the keys were still valid.  

You have no real basis for setting a five-year threshold for E-mail certs.  I have archived some E-mail messages that are now more than seven years old.  

The same is true for code-signing.  Some of the software versions that I am currently using are more than ten years old and are still available from the Web.  Of course, those older versions were never signed.  But how do you create a threshold that will not impact newer (but still old) software that was code-signed?  
Nelson, could you positively confirm that the CA roots aren't needed in order to read encrypted mail, only the user certificate?

Concerning 4b I wanted to add, that this implies that the NSS developers have a critical look at CA roots which are proposed for inclusion, at least during the comment period. I guess means a little bit more than just installing it and see if it works. In short, 4b isn't something which should happen in first place.
Things that "shouldn't happen in the first place" happen all the time.
And when they do, developers have to fix them.
This policy extension is to clearly empower the relevant developers to do so.
(In reply to comment #19)
> Things that "shouldn't happen in the first place" happen all the time.
> And when they do, developers have to fix them.
> This policy extension is to clearly empower the relevant developers to do so.
> 

Correct! I'm not saying "don't fix it". Obviously since this could have some farer reaching consequences for a CA and might affect other software vendors as well, I just suggest to change the approach a little bit as per comment 10 from me.
Blocks: 416684
Even though this bug requests an enhancement to Mozilla's CA cert policy,
I'm changing this bug from "enhancement" to "normal" severity, to 
differentiate it from the myriad cert addition requests, and keep it 
out of search results for cert addition requests.
Severity: enhancement → normal
No longer blocks: 413379
Is this still relevant?
Hopefully the concerns in this bug have all been resolved.

If there are still policy updates needed, please check to see if the issue is listed here:
https://github.com/mozilla/pkipolicy/issues/
And please add it if needed.
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Product: mozilla.org → NSS
Product: NSS → CA Program
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: