I have tried to delete a root cert from Fx and have found that the cert comes back and appears FULLY FUNCTIONAL rather than being disabled. So, I don't understand your statement.
I would like to ask why are there root certs for Fx that cannot be verified because, according to Fx, the issuer is NOT trusted? It makes me nervous having certs that cannot be verified and that, when deleted, promptly return to the list and appear functional. Those certs are not even on the list that is on your web page. I assume they are legacy certs but why are certs that cannot be verified there at all? I am referring to beTRUSTed Root CCA Baltimore Implementation, beTRUSTEed Root CA RSA Implementation, and beTRUSTed Root CA Entrust Implementation. I am unable to delete the GTE CyberTrust Root CA that expired in February. That one also comes back. Why? I also deleted the GoDaddy cert and it comes back. If these are actually disabled then why are they back in the list and not at least grayed out or have "disabled" beside them? Should I not be informed that they are disabled if they truly are? I have another question regarding Fx certs that is not directly related to PSC's findings but would like to ask it. Why does Fx not have any certs from Microsoft? It is very irritating every time I go to a secure Microsoft site on Fx to have Fx tell me that the certificate cannot be trusted (Microsoft Secure Server Authority which is an intermediate cert). Along these lines, I also would like to know why Fx jumbles up the intermediate and root certs all on one tab? They should be on separate tabs. "Frank Hecker" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Julien Pierre wrote: > <snip> >> This site makes a lot of unsubstantiated and bogus allegations . >> I am only responding to show how little the author knows about Mozilla. > > Julien, thanks for responding to this. > > Here's my own summary of the situation, in response to the material > published in the Privacy Software Corporation Newsletter dated July 24, > 2006: > > 1. The file NSSCKBI.DLL mentioned in the PSC newsletter contains the > pre-loaded root CA certificate list shipped with Mozilla-based products, > including Firefox, Thunderbird, Mozilla Suite, Seamonkey, and Camino. It > is part of the Network Security Services (NSS) cryptographic library that > provides SSL and other support for Mozilla-based products. NSSCKBI.DLL > contains only the root CA certificate data; it does not actually perform > any certificate-related operations. > > > 2. The Windows registry key referenced by the PSC newsletter: > > HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates > > is associated with Microsoft Windows, and contains data associated with > pre-loaded root CA certificates used by Internet Explorer and other > Windows applications. > > This registry key has nothing to do with Mozilla-based products, NSS, or > NSSCKBI.DLL. NSS and other Mozilla code do not use this key or write to > it; as noted above NSS stores pre-loaded root CA certificate data in > NSSCKBI.DLL. > > Other parts of the Mozilla code do read and write the Windows registry, > but they do so in a separate section of the registry, under > > HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla\... > > > 3. Contrary to the assertion in the PSC newsletter, the root CA > certificates used by Mozilla-based products (including the certificates > stored in NSSCKBI.DLL) can be viewed and edited from within the > preferences dialogs of those various products. For example, with Firefox > 1.5 Under Windows the user can view and edit certificate data as follows: > > 1. From the "Tools" menu, select the "Options..." menu item. > 2. In the resulting dialog box, click on the "Advanced" toolbar > button. > 3. Select the "Security" tab. > 4. Click on the "View Certificates" button. > 5. In the resulting dialog box, select the "Authorities" tab. > 6. Click on a CA certificate to select it. > 7. Click on the "View" button to view the certificate and related > information, on the "Edit" button to modify settings for the > CA and its certificate, and on the "Delete" button to delete > the certificate. > > Other Mozilla-based products have similar features. > > Note that "deleting" a pre-loaded CA certificate doesn't actually delete > it from the file NSSCKBI.DLL, but rather disables use of that CA and its > certificate within the Mozilla-based product in question. > > > 4. Although it's not relevant to Mozilla (as discussed above), note that > (contrary to the assertion of the PSC newsletter) the pre-loaded set of CA > certificates for Microsoft Windows as stored in the registry key mentioned > above can in fact be viewed and edited as well. For Windows XP and > Internet Explorer 6, the steps are as follows: > > 1. From the "Tools" menu select the "Internet Options..." menu item. > 2. In the resulting dialog box select the "Content" tab. > 3. Click on either the "Certificates" button (for CA certificates > related to SSL) or the "Publishers" button (for CA certificates > related to ActiveX code signing). > 4. In the resulting dialog box select the "Trusted Root Certification > Authorities" tab. > 5. Click on a CA certificate to select it. > 6. Click on the "View" button to view the certificate and related > information, on the "Advanced" button to modify settings for the > CA and its certificate, and on the "Remove" button to delete > the certificate. > > > 5. The Mozilla Foundation selects CA certificates for pre-loading into > Mozilla-based products based on its policy as described at > > https://www.mozilla.org/projects/security/pki/nss/ca-certificates/policy.html > > As part of this policy we evaluate the benefits and risks of including a > particular CA's certificate in our pre-loaded list, including looking at > independent evaluations of the CA in question. For CAs included since the > policy was officially adopted, we maintain in the Mozilla project's > Bugzilla bug database a public record of discussions related to the > decision to include or not include a particular CA; see > > http://www.hecker.org/mozilla/ca-certificate-list > > for references to such records (in the "Related Bugs" column). > > If anyone, including PSC, has reason to believe that including a > particular CA's certificate poses a security risk to users of > Mozilla-based products then they are free to submit a bug report providing > evidence to that effect and we'll look into it. Such reports can be > submitted directly into the Mozilla bug database at > <http://bugzilla.mozilla.org/> or can be sent to the email address > [EMAIL PROTECTED] > > Again, though it's not directly relevant to Mozilla-based products, other > browser vendors (e.g., Microsoft, Apple, Opera, etc.) maintain similar > pre-loaded CA certificate lists and have similar policies related to > including new CA certificates in the list. Note that there is substantial > (though not 100%) overlap between the various lists; for example, the > Thawte, USERtrust, and Quo Vadis CAs mentioned in the PSC newsletter are > in both the Mozilla list and the Windows list. > > > I hope this answers the questions raised by the PSC newsletter. If anyone > has any further questions please feel free to post in this forum or email > me directly. > > Frank > > -- > Frank Hecker > Executive Director > [EMAIL PROTECTED] _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
