Nelson Bolyard: > Eddy, I haven't pushed for the inclusion of any CA or any CA cert. > OK Nelson, again I apologize for any inconvenience my previous post may have caused you. > Then I went and looked at the "pending" page, > http://www.mozilla.org/projects/security/certs/pending/index.xml > And saw lots of color coded information there. Personally, I found the > particular presentation on that page to be difficult to quickly grasp. > Mhhh, I like it actually... > 1) When I look at the bugzilla bug list of open root CA requests, at > https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&product=mozilla.org&component=CA+Certificates&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=enhancement&chfieldfrom=2004-04-01&chfieldto=Now&chfield=%5BBug+creation%5D&cmdtype=doit > > > I added this to my saved searches, really useful! > 3) It had the predictable effect of causing a number of those CAs to respond > saying (in effect) "Oh, our application is incomplete? What are > we missing?" IMO, that was useful to get the process moving for them > again. > That's most likely due to missing manpower (from Mozilla side) and them not following up on their bugs.... > 4) It also had the effect of causing Frank to notice that some of that info > was out of date, and so there were some immediate updates to the Pending > page. I then carried those updates to the bugzilla bugs. > OK > 5) I think there are still some discrepancies. For example, the Pending > page says that bug 335197 "Add KISA root CA Certificate" is in "public > discussion" state, but after studying the bug, I conclude that it is NOT > yet in that state. Frank's most recent comment suggests he has more > review to do on it. I think the "Information Probably Complete" state > is more accurate for that request. > Yes, it might be that this bug needs to be tagged differently now. I'm not sure, since we are either waiting for them or for Frank...? > > Apart from this "book keeping" task that I have done, I have no more > control over the request evaluation process than you do. > :-) > I think Mozilla desires to maximize the number of issued certs that will be > recognized as valid by FF3 when it ships, in order to minimize the number > of complaints from FF3 users about their favorite site's certs being > unrecognized. I think that has led to an approximate ordering of the > requests from biggest (most certs issued) to smallest (least certs issued), > and from requests that take the least time to evaluate to those that take > the most time to evaluate. > Yes, this makes sense... > It appears to me that each request to add a new cert (or certs) for a CA > whose certs are not already in the list takes roughly the same amount of > time to evaluate, whether that CA serves tens of certs or thousands of > certs. It appears to me that the requests to give EV approval to certs > already in FF's root list takes much less time to evaluate than requests > for certs not yet included in the list. Correct. > So, it wouldn't surprise me at > all to see that priority is given to the requests for upgrading certs that > are already in the list. > I think this is what Frank actually did. The upgrades were preferred over the ones which had new roots to include. > > If I'm right that Mozilla has chosen to order the requests in decreasing > order by number of certs issued (or equivalently, https server market share) > I think it would be good for Mozilla to publish that fact. No, generally speaking I don't believe that this is the case...I think that would be a wrong statement and Mozilla doesn't have to publish something like this.
-- Regards Signer: Eddy Nigg, StartCom Ltd. <http://www.startcom.org> Jabber: [EMAIL PROTECTED] <xmpp:[EMAIL PROTECTED]> Blog: Join the Revolution! <http://blog.startcom.org> Phone: +1.213.341.0390 _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
