Kathleen - Chris Bailey and I talked about this, and we think FF's rules on what kind of audit a CA should present to add a root to the FF keystore should be different depending on whether the root is new (no certs issued yet, in part because the root is not in FF), or is an existing root in other browsers that is issuing certs to customers.
We think FF should accept a simple PITRA audit if the CA is not using its root in any browser (and so has no customers). However, if the root is in other browsers and the CA has been using the root to issue certificates to customers, then a simple PITRA audit should not be accepted by FF and a full performance audit should be required - the CA is already issuing the certs, so why not make the CA show BR compliance over at least a 60-90 day period (which generally is sufficient under WebTrust as an initial period for a BR performance audit). Maybe certs issued prior to the start date of the (successful) performance audit should not be recognized in FF. If a CA applying to be include in the FF keystore can't provide FF the necessary audits (regular WebTrust/ETSI and BR audits, plus EV audit if the root is to be EV-enabled), then the CA should be moved to the back of the queue until the audits have been presented. On a related question, if a CA has a new root and is not issuing certificates yet, we think FF should allow the CA to continue presenting annual PITRA audits each year while waiting in the queue until the root is accepted by FF, then switch over to performance audits. Or perhaps one PITRA audit should be sufficient for more than a year waiting in the queue, if the new CA has been waiting in the FF queue for over a year like we did - it's not clear that a second PITRA audit really adds much, unless the applicable audit standards have changed since the first PITRA audit was presented the previous year. Kirk R. Hall Operations Director, Trust Services Trend Micro +1.503.753.3088 <table class="TM_EMAIL_NOTICE"><tr><td><pre> TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. </pre></td></tr></table> _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
