Closed Bug 333272 Opened 14 years ago Closed 13 years ago
List All Installed and Pending CA Certificates
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:184.108.40.206) Gecko/20060130 SeaMonkey/1.0 Mnenhy/0.7.3.0 Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:220.127.116.11) Gecko/20060130 SeaMonkey/1.0 Mnenhy/0.7.3.0 An official Web page is needed in place of the cited Web page to list all CA certificates that are installed in Mozilla products and those for which installation is pending, under evaluation, or requested. This information should be an official presentation of the Mozilla Foundation or Mozilla Corporation. Users should not have to depend on someone's personal Web page for this. I suggest a different format. The cited page uses a table that requires horizontal scrolling to read. Instead, it might be in the form of a bulleted list. Additional information is requested, beyond what is seen on the cited Web page. All legacy certificates should be listed. For each approved certificate, the basis of approval should be indicated (e.g., WebTrust audit, legacy). SHA1 and MD5 fingerprints of certificates should be listed for comparison with the display by the Certificate Manager. A link to each certificate in a Mozilla archive of approved certificates should be provided so that users whose Mozilla products do not yet have the latest approved certificates will indeed know they are downloading the same certificates that will appear in Mozilla products. The product versions in which a certificate first appears should be indicated. A separate listing of certificates that have been replaced or whose approval has been revoked by Mozilla is also required. These lists should be on secured Web pages. A notice should be posted on <news://news.mozilla.org:119/mozilla.dev.tech.crypto> each time these lists are updated. Reproducible: Always I see CA certificates in Certificate Manager that are listed in neither the cited Web page nor the WebTrust site. I have no way to tell if a conscious decision was ever made to include them. Thus, I have no basis for trusting them. In general, I clear all the checkboxes for such certificates, retaining them but as untrusted.
hecker: This is your domain. Please look into this.
hecker: I'll work on this if you think it would be something good to add to www.m.o
I;d be happy to have someone take this task on. I think there are really two separate tasks here. The first is to take the current list of pre-loaded CA certificates and make an official web page listing information about such certificates and the associated CAs. The second is to have a page keeping track of comparable information about CAs not yet approved for inclusion. For the record, I think at the moment the first task is a higher priority, since there is absolutely no web page right now that contains such a list. Regarding the list of already-included CA certificates, the ultimate source for such information is in the NSS source tree, e.g., http://lxr.mozilla.org/security/source/security/nss/lib/ckfw/builtins/certdata.txt (I think this is from the NSS trunk. Also, there is a separate file certdata.c that I believe is generated from certdata.txt. NSS developers can correct me if I'm wrong on either point.) As a previous commenter noted, one major issue is what information should be included for each CA certificate, and how it should be presented. Certain information, like the CA label within NSS, the "trust bits", and the actual cert data can be taken from certdata.txt. However other information -- URLs for CA information, pointers to WebTrust and other audits, CRL and OCSP information, etc. -- must be added separately by hand. The amount of information per CA is high enough that I agree that putting it all in a single table is not optimal. Perhaps a better approach would be a summary table listing all the CA certificates, with internal links pointing to list items within a bulleted list of the CA certs. In terms of where such a list should go, probably the best place would be within the NSS hierarchy on www.mozilla.org, for example at http://www.mozilla.org/projects/security/pki/nss/ca-certificate-list.html or a similar URL.
Assignee: nobody → nb
Component: www.mozilla.com → www.mozilla.org
Product: Websites → mozilla.org
QA Contact: www-mozilla-com → www-mozilla-org
Version: unspecified → other
-> www.mozilla.org and taking. I'm working on this.
Status: NEW → ASSIGNED
Creating and maintaining the CA certificate list will be significantly more complicated than maintaining the CA policy page, because there are much greater security implications. Here are some quick thoughts for how we might go about this, starting with the issue of creating: First, we already have two potentially conflicting sources of cert data: the NSS source code (certdata.txt) and the downloadable certs on the CAs' own web sites. Simply having a static CA list page would introduce a third potentially different source. Therefore I think the best approach would be to automatically generate the CA cert list page(s) using a script, and have the script do a cross-check between the NSS source code and the original cert data from the CA web sites. Additional data on CAs (e.g., URLs for CA info, policy documents, CRL and/or OCSP URLs) could then be maintained in a separate file (e.g., in CSV format or some other structured format) and merged in with the other data. The script could also compute SHA-1 and MD5 fingerprints on the cert data and cross-check those as well. (It appears that certdata.txt has values for these.) As David suggests, I think it would make sense to have each certificate stored in a separate file so that users could download them if needed. The CA list page would then have links to those files. In terms of maintaining the pages, clearly we want to have some type of access control to prevent changes to the list and the accompanying cert data. Perhaps the best approach will be to keep these on the www.mozillafoundation.org site, the CVS tree for which will have much more limited access than that for www.mozilla.org. Nicholas, if you want to work on this bug then I suggest that you start with two tasks: 1. Look at writing scripts to do page generation as discussed above. 2. Collect the additional CA metadata above and beyond what's in the NSS source. Once we have a way of auto-generating the page(s) then we can look at the question of where and how to publish them and control access to them.
What I'd suggest is to make a static webpage for now (I think it'll take a while for me to make a script), and then we can replace it if necessary later with a build script. In terms of access control, we (well, actually the admins) could make a separate despot partition for mozilla-org/html/projects/security/pki/nss/ca-certificates and set the owner/peers/members to be me, you, etc, thus limiting the people that could checkin to those people. IMHO, this would be more consistent with current placing of documents because this would be under the nss section of the webtree on m.o, which is where everything else is, instead of on mf.o which if I'm not mistaken is mostly for foundation-related stuff such as donations, etc. What do you think about these ideas? Also, I've committed http://www.mozilla.org/projects/security/pki/nss/ca-certiicates/cacertlist.csv in case anyone wants a work in progress/interim list of CA certificate information (I have quite a few of the blanks filled in, but am still working on it). The filename column refers to files in /ca-certificates/certfiles which contain the actual root certificates
The concept in comment #6 seems good. However, a script to maintain the list dynamically might be overkill. I see the list being updated only on occasion: 1. When a new bug report requests the addition of a certificate, the list would be updated by the developer to whom the bug is assigned. When there are several such bugs, updates to the list could be combined and done monthly. 2. When the evaluation of the bug concludes that the request should be approved or disapproved, the list would again be updated by the developer to whom the bug is assigned. And again, updates to the list for this could be combined and done monthly. 3. When an approved certificate actually appears in a newly released Mozill product, the list would be updated by QA or the release team. This might be only two or three times a year. 4. When a previously installed certificate has its approval revoked, the list would be updated by the security team. This update might not be suitable for automation. Of course, other events might require updating the list. And other schemes might be used to manage the list. This points out the need to have a formal, internal (i.e., not published externally) procedure for managing it.
http://www.mozilla.org/projects/security/pki/nss/ca-certificates/cacertlist.csv That is the correct link for the interim work-in-progress spreadsheet I am using to compile the information necessary to make the web list. I had made a minor typo in spelling ca-certificates in comment #7. re: comment #8 : FYI, I'm in favor of a plain list also. I think the work of making a script is probably unnecessary. If anyone has information to fill in any of the blanks on my spreadsheet, please email me or add a comment to this bug. When I get substantially done, I'll make the webpage. I'm going to try to work on it more next week, and hopefully get a draft of the html page(s) up.
Two bits of info that might be useful: * when was the root cert *added*? * does the CA offer free certificates for: * email * SSL * code signing (and if so does getting a free cert have conditions, like noncommercial use)?
I agree that the date on which a root certificate was added to Mozilla products would be useful, perhaps more useful than the date on which it was approved. The date -- and version -- for each product (including allied products such as SeaMonkey) should be indicated. Thus, there might be several dates, with Firefox having a different date than Camino, Thunderbird, or SeaMonkey. However, whether and under what conditions free certificates are available are issues best left to the CA's Web site. This is why a link to the CA's Web site is important on Mozilla's list. That way, if any of that information changes, Mozilla's list does not have to be updated. In any case, that information is not really relevant to the inclusion of a CA on Mozilla's list.
As frank noted, there are two distinct parts to this request: a) a list of currently approved CAs, and b) a list of reviews pending or in progress I submit that both of those are already available now. The list of currently approved CAs is shown in every mozilla product that uses that list, in the "certificate manager". The latest list of pending review requests may be seen with this Query URL: http://tinyurl.com/32ajht What else needs to be done to satisfy this RFE? Is it satisfied now?
I requested a Web page, not a Bugzilla query and not a view into the Certificate Manager. I know the results of the query are a Web page, but my intent was for a Web page that did not involve Bugzilla. I requested that the information be together, for both installed certificates, approved but not yet installed certificates, and certificates for which approval is still pending -- with an indicator on each as to which of those three states apply. And I requested that certain details be displayed without having to open individual bug reports in Bugzilla or certificates in the Certificate Manager. For certificates that are already installed, some details are not currently available (e.g., whether they were installed per a bug report or are a legacy from before the current policy was adopted, the Web address of the certificate authority, the bug numbers for non-legacy certificates, the dates or version numbers of the product in which the certificate was first installed). In any case, how is someone who does not yet have Firefox, SeaMonkey, or another Mozilla-based browser view the list of installed certificates if that list is available only via the Certificate Manager? (No, looking at the code is not acceptable for the average Web surfer.)
I agree with David Ross's position on this: I think there should be an authoritative web page (or pages) that someone could refer to without having to look at the source code or have a copy of Firefox available. Here are my current thoughts on this: * For now at least the page(s) should go on www.mozilla.org and be subject to standard access control for that site. This issue can be revisited later, for example, using Nicholas Bebout's idea of a separate despot partition for the CA-related area of www.mozilla.org. (I suggested above having the page(s) on a separate www.mozillafoundation.org site, but I have no idea if/when such a site will be in operation; hence I'm abandoning that idea for now.) * On www.mozilla.org the page(s) should go under the <http://www.mozilla.org/projects/security/pki/nss/ca-certificates/> hierarchy, where the official CA policy is currently located. * I agree that we should move from the current "one big table" approach to something more manageable. As noted above, one possibility is a bulleted list, with one item per CA; this puts everything on one page, with the disadvantage of having it be a very long page (given that we have on the order of a hundred CAs to deal with). Another possibility is having a separate page for each CA and then a page with a table listing the CAs and pointing to their individual pages. My inclination is to start with a big bulleted list, one item per CA, with sublists for the information for each CA; as noted by Nicholas above, that page can also contain a summary table with internal links to the list items for individual CAs. If we ever wanted to split the list into separate pages for each CA, that would be relatively straightforward to do: just keep the summary table and generate a page for each list item. * Should we have a single list for all CAs (whether approved or not approved), or one list for approved CAs and a separate list for CAs not yet approved. David Ross mentioned having a single list, but I think I disagree. I think it would be less confusing to have one page with a list of all approved CAs current in NSS, and a separate page with a list of all CAs currently being considered for inclusion. I think these lists have two slightly different audiences: The approved list is an authoritative reference of what CA certificates are actually in NSS, along with supporting information for how they got there. The "pending" list is more for people actually working on the approval process or otherwise interested in it. Once a CA is approved it would be moved from the pending page to the approved page. I think the two-list approach is also simpler and more consistent, since we may not keep exactly the same information for approved CAs vs. pending CAs. Having two lists means each list has the exact same internal format for all list items. Finally, note that as suggested by David we'd actually have a third list, namely CA certificates that have been removed from NSS. In my proposal this would go on a third page. * Assuming a three list scheme as discussed above, what should the URLs be for each list? Since the proposed directory within www.mozilla.org already is named "ca-certificates", I suggest simply appending "included", "pending", or "removed" as the filename: http://www.mozilla.org/projects/security/pki/nss/ca-certificates/included.html http://www.mozilla.org/projects/security/pki/nss/ca-certificates/pending.html http://www.mozilla.org/projects/security/pki/nss/ca-certificates/removed.html This comment is getting pretty long, and I have to do something else right now. I'll comment again later on what information should be included for each CA in each list.
The "pending" list should have the content currently available at <http://hecker.org/mozilla/ca-certificate-list> but (as already indicated) not in tabular form. The "included" list should have the following (not necessarily in this order): certificate name, version, SHA1 and MD5 fingerprints, and validity dates CA name trust indicators (the defaults as installed) authorization for inclusion (either bug number or "legacy") link to CA Web site Mozilla products and versions where installed (including "outside" products such as SeaMonkey) The "removed" list should have the following (again not necessarily in this order): certificate name, version, SHA1 and MD5 fingerprints, and validity dates CA name authorization for removal (bug number, US-CERT alert number, etc) date of removal decision (NOTE: Each removal should be announced immediately on news.mozilla.org, cross-posted to all relevant newsgroups.) The "included" and "removed" lists should be organized by certificates, not by CAs. This is because different individual root certificates from a given CA might be included or removed at different times.
Please don't design any more grand plans and specifications that can't/won't be staffed. The problem to date hasn't been an sbsence of grand specifications. It has been a lack of people to do the required work.
I've asked Gerv to spend some time on getting the CA request backlog processed, and as part of that to update the information we're keeping on CAs. At the moment I think it's a higher priority to get the "pending" list in order, but if/when Gerv has time I think it would be a good idea to work on the "included" list as well.
Yes, as Frank says, I'm going to be working on this. Frank wrote: > * On www.mozilla.org the page(s) should go under the > <http://www.mozilla.org/projects/security/pki/nss/ca-certificates/> hierarchy, > where the official CA policy is currently located. Can we take this opportunity to shift things? I have to keep sending this URL to people, and it's already wider than 80 chars. Could we move to: http://www.mozilla.org/projects/security/certs/ , and put some redirects in place for existing content? Other public-interest security documentation, such as the TLD IDN policy list and the security bugs policy are up at the projects/security level. Gerv
(In reply to comment #17) > Could we move to: > http://www.mozilla.org/projects/security/certs/ > , and put some redirects in place for existing content? I'm ok with this change. However, I would request that the actual CVS files be moved over to the new location in order to save history. Once the files are copied over, the originals can be removed and a redirect can be added.
Reed: it turned out that the documents had no history, and a CVS move was hassle (bug 369493) so I just checked them in again at the new location. Frank is still working on the exact format and layout of the data we want to track for each CA; when we have that, I'll put together the current and pending lists. Gerv
I think David's suggestions for included information are pretty close to what I'd want to see; I have some minor suggestions below. (In reply to comment #14) > The "pending" list should have the content currently available at > <http://hecker.org/mozilla/ca-certificate-list> but (as already indicated) not > in tabular form. One thing I'd like to see (but that isn't included in my current list) is some summary information on the CA: its general nature (e.g., commercial, government, academic/research, nonprofit), the primary geographical area(s) it serves, the types of certificates it issues, the number and type of subordinate CAs, and so on. This could be a one paragraph description included with the listing. > The "included" list should have the following (not necessarily in this order): I'd also like to see a summary paragraph here as well. > certificate name, version, SHA1 and MD5 fingerprints, and validity dates The certificate name should be exactly as listed in the NSS database. Also, regardless of what we decide to do about EV certificates, we should track whether a given cert is advertised as an EV cert or not. (This is true for all the lists: pending, installed, and removed.) > CA name > trust indicators (the defaults as installed) > authorization for inclusion (either bug number or "legacy") Note that typically there are at least two bug numbers that should be listed: the original bug for the request (which would include any approval comments) and the bug by which the cert is added to NSS. There may be other relevant bug numbers, and they should be included as well. > link to CA Web site > Mozilla products and versions where installed (including "outside" products > such as SeaMonkey) First and foremost we need to include the NSS versions in which the certificate is included; everything else follows from that. As for listing other products and their versions, I think this can safely be limited to Firefox, Thunderbird, SeaMonkey, and Camino, as these are the main products of interest for SSL and other PKI-enabled functionality. > The "removed" list should have the following (again not necessarily in this > order): > certificate name, version, SHA1 and MD5 fingerprints, and validity dates > CA name > authorization for removal (bug number, US-CERT alert number, etc) It would be useful to include a summary description of the removal reason. > date of removal decision > (NOTE: Each removal should be announced immediately on news.mozilla.org, > cross-posted to all relevant newsgroups.) > > The "included" and "removed" lists should be organized by certificates, not by > CAs. This is because different individual root certificates from a given CA > might be included or removed at different times. Correct. Overall I think the structure would look something like this: CA 1 - name, summary description, bug number(s), etc. CA 1 cert 1 - info as noted above CA 1 cert 2 - etc. CA 2 - etc. ... One final note: Since Gerv will be the primary person working on this, I suggest that the bug be re-assigned to him (instead of Nicholas Bebout).
Assigning to me. Gerv
Assignee: nb → gerv
Status: ASSIGNED → NEW
Some open questions: Frank: what sort of thing would you have in the "summary paragraph" for each certificate that you suggested? (I understand what would be in a CA's summary paragraph.) Does it make sense to have a separate "Removed" list? If a cert is removed because it's expired, for example, then it'll still be in shipped products for quite a while after it gets removed on the trunk. So which list should it be in? Would it make sense to combine the two lists, and just have pending and accepted? Should we store audit information per-CA or per-certificate? It seems that we will also require a list of Mozilla product versions and corresponding NSS versions, and a version tree diagram for NSS, to allow people to translate NSS version numbers to shipping product version numbers. Does that seem right? Gerv
(In reply to comment #22) > Frank: what sort of thing would you have in the "summary paragraph" for each > certificate that you suggested? (I understand what would be in a CA's summary > paragraph.) Note that in this context we are using the term "CA" in a double sense: the listing for the overall "CA" covers the entire organization, which might actually operate several root CAs, and the listing for each CA certificate covers each individual root CA. Having said that, the summary for an individual root CA certificate should include the following information: * Are end entity certs issued directly under the root, or from a subordinate CA under the root? * The general function of the CA hierarchy rooted in the root CA: Is it for issuing SSL certs? individual certs for S/MIME or SSL client auth? and so on. * The general "class" of the root CA and its hierarchy: domain-validated, identify-validated, EV, etc. * Modulus length (aka "key length") for the CA certificate. We should highlight this for all CAs in case we want to encourage upgrades to larger lengths. * Any other technical information about the CA worth noting. > Does it make sense to have a separate "Removed" list? If a cert is removed > because it's expired, for example, then it'll still be in shipped products for > quite a while after it gets removed on the trunk. So which list should it be > in? Would it make sense to combine the two lists, and just have pending and > accepted? Maybe so. > Should we store audit information per-CA or per-certificate? Typically audits are done at the level of the organization, what we are calling here the "CA". > It seems that we will also require a list of Mozilla product versions and > corresponding NSS versions, and a version tree diagram for NSS, to allow people > to translate NSS version numbers to shipping product version numbers. Does that > seem right? Yes. However note that in some cases Firefox and other products had their own custom NSS branches, which further complicates things. You really need to ask in m.d.t.crypto about this general issue.
Frank: all of those summary points except the first and last one now have individual entries in my list of data items. I now have a draft list of data items, which I will post here in a separate comment. Gerv
The plan: There will be two lists: pending and included, where included also has any certificates which have been removed at some point. This is because the boundary between the two is fuzzy. For each CA: Summary Paragraph General nature (e.g., commercial, government, academic/research, nonprofit) Primary geographical area(s) Types of certificates Number and type of subordinate CAs Website Audit Type Auditor Audit Documents For each cert from that CA: Certificate Name (exactly as listed in NSS) Summary Paragraph End entity certs issuance policy Any other technical information about the CA worth noting. Certificate Data URL Version SHA1 Fingerprint MD5 Fingerprint Modulus Length (a.k.a. "key length") Valid From Valid To CRL URL OCSP URL Class (domain-validated, identity-validated, EV) Certificate Policy URL CPS URL Default Trust Indicators (email, SSL, code) Inclusion Authorisation Bug: Database Change Bug: Included In NSS Version(s): For removed certificates, add: Date of Removal Removal Bug Removal Reason We will also require a list of Mozilla product versions and corresponding NSS versions, and a version tree diagram for NSS, to allow people to translate NSS version numbers to shipping product version numbers. Comments? Gerv
Status: NEW → ASSIGNED
Gerv, this looks good. A couple of minor points: Typically there's just one bug for all of a CA's root CA certificates, so this could be put at the CA level. However we do sometimes get inclusion requests that apply only to one or two of a CA's certificates, so putting this at the CA cert level is probably appropriate. Also, there are sometimes CA-related bugs that don't fall into the "inclusion authorization" or "database change" categories. You thus might want to have a "miscellaneous bug" category.
The format indicated in comment #25 is excellent. However, two points should be addressed: If installed and removed certificates are in the same list, removed certificates should be highlighted in some manner (e.g., text using italics or strikeout). Grouping of certificates under their CA should be done in a manner that accommodates situations such as bug #365281 (adding certificates where the CA already has a certificate installed in the Mozilla database) and bug #362304 (adding a new certificate that will eventually replace (remove) an existing certificate).
(In reply to comment #27) > If installed and removed certificates are in the same list, removed > certificates should be highlighted in some manner (e.g., text using italics or > strikeout). The problem with that is the same problem that caused us to combine the lists in the first place. "Removed" is not a binary flag. It may be in some products and not others; it may be in shipped products but not upcoming products. > Grouping of certificates under their CA should be done in a manner that > accommodates situations such as bug #365281 (adding certificates where the CA > already has a certificate installed in the Mozilla database) The "pending" list can have an "existing roots" link for a particular CA, linking to the "installed" list. Frank: your second sentence seems to contradict your first. Can you clarify? Gerv
(In reply to comment #28) > Frank: your second sentence seems to contradict your first. Can you clarify? Which sentences are you referring to? Or were you thinking of David's comments and not mine? In any case, here are my views on how to treat "removed" certificates. You (Gerv) are correct that it's not necessarily a binary question regarding whether a certificate is in the installed list or not, since different products will have different lists. However at the same time I think it's very important to highlight the fact that a decision has been made to remove a particular certificate, and the reason(s) why such a decision was made. My suggestion is as follows: Have a separate "to be removed" list that lists all CA/certificate combinations which we've decided to remove. At the same time, continue to list those CAs and certificates in the installed list, but with a special indicator that notes they are in the process of being removed. (For example, we could have a "Status" field with "Active" or "Included" (or some other suitable value) for certificates in "good standing", and "Being Removed" (or some other value) for certificates being removed; in the latter case the status value could link to the corresponding listing in the "to be removed" list. Also, for certs in the "installed" list that we've decided to remove, the associated NSS versions would be listed as, e.g., "NSS 3.11-3.13" instead of "NSS 3.11 and later" as they would be for a certificate in good standing. (Ditto for other products, e.g., "Firefox 1.5-2.0" as opposed to "Firefox 1.5 or later".)
I have been tracking the activity of pending requests to add new certificates. From recent comments, I found <http://www.mozilla.org/projects/security/certs/pending/>, which looks good. Will a link to this be added to the Site Map or other high-level page? However, I have not yet been able to see a page of installed certificates. Is that completed? Based on earlier comments in this bug report, I tried <http://www.mozilla.org/projects/security/pki/nss/ca-certificates/>; however, that page is 403 (restricted).
I will add a link to the "pending" list at a higher level soon. There is no page of installed certificates; that's a really big project and not as urgent as dealing with the backlog of inclusion requests. Of course, if someone else wants to take it on, that would be wonderful. Gerv
I've now linked the pages in to http://www.mozilla.org/projects/security/ (it may take a few minutes for the live website to update). I've linked to the file which defines the existing store in lieu of a list like the pending one. Gerv
Because issues relating to certificates are of interest to users (at least to the more knowledgeable users), links to the Pending and Installed pages should also appear on the <http://www.mozilla.org/sitemap.html> page. I suggest adjacent to the link "CA certificate policy" with the header changed from "Policies" to "Certificates". The Pending page should indicate its latest update date (as the Policy page does already). I looked at the page's Page Info. The Modified date is "Thursday, January 01, 1970 12:00:00 AM", which indicates to me that it's actually zero. I realize that implementing this RFE might be considered by some developers as a waste of time. However, this is a user-oriented issue that will help answer such questions as "Why do I get a warning about a certificate not available when I go to a certain Web site?" or "Why is my friend's home-made root certificate not in Firefox?" So far, the plan for implementing this RFE is far superior to what is currently available at <http://support.microsoft.com/kb/931125>.
I've put up a placeholder "included" page and changed sitemap.html. That should show up on the main site inside the hour. > The Pending page should indicate its latest update date (as the Policy page > does already). I'd like the webserver to serve the right date, but it doesn't seem to be doing so (as you saw in Page Info). And I don't think there's any way to get XSLT to write the last-mod date into the page automatically. So I can either maintain it by hand, or add a link in the footer to this URL: http://bonsai-www.mozilla.org/cvslog.cgi?file=mozilla-org/html/projects/security/certs/pending/index.xml&rev=&root=/www/ Would that do? Gerv
On the "Pending Certificate List" page, I suggest a fifth color-coded state: Installation Pending. This would divide "Public discussion/inclusion" into two states, one for "Public discussion" and one for inclusion (under the new name). Pending certs that are "Installation Pending" are merely waiting for a new NSS store version and a subsequent new Firefox, Thunderbird, or other application version. Since these certs have passed all examinations, reviews, and comment periods, users should feel comfortable in downloading and installing them into existing application versions without waiting for new versions. This would be the same as acquiring certs from the "Included Certificate List" page (as yet to be populated).
The idea is that we don't stay in that state too long :-) There are already enough states to manage. OK, we now have both lists, and the included list has been populated with the four CAs completed so far. I'm going to call this done. If you want yet more, file another bug. :-) http://www.mozilla.org/projects/security/certs/pending/ http://www.mozilla.org/projects/security/certs/included/ (Note: these may take an hour or two to update.) Gerv
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org
You need to log in before you can comment on or make changes to this bug.