Re: The case for point in time readiness audits (PITRAs)
On 9/3/2014 4:26 AM, Kathleen Wilson wrote: > I updated the wiki page some more, here's the text... > > https://wiki.mozilla.org/CA:BaselineRequirements#BR_Point_in_Time_Readiness_Assessment_.28BR_PITRA.29 > > == BR Point in Time Readiness Assessment (BR PITRA) == > > We previously said: "Any Certificate Authority being considered for > root inclusion after February 15, 2013 must comply with Version 2.1 or > later of Mozilla's CA Certificate Policy. This includes having a > Baseline Requirements audit performed if the websites trust bit is to > be enabled. *Note that the CA's first Baseline Requirements audit may > be a Point in Time audit.*" > > There are two cases when a Point in Time Readiness Assessment of BR > compliance (BR PITRA) may be used: > > 1.The CA has created a new root certificate, which is not yet in > operation producing real certificates. In this case a BR PITRA prior > to inclusion may be used, but the next annual audit after inclusion > would need to be a full performance audit. Note: If the inclusion > process spans more than one annual audit cycle, then more than one BR > PITRA may be used, until the root certificate has been included or the > root certificate is put into operation producing real certificates, > whichever comes first. CAs should have their self-assessment on their readiness to comply with BRs before performing the BR PITRA. In fact, I will not surprise that you will only get "clean" report from those CAs. If not, why the CA bother to submit to Mozilla? Then I suppose that the root certificate should be included in trust store based on the "clean" PITRA report. Finally the CA put the root certificate into operation to produce real certificates. No "whichever comes first" because CA may not have real customers of certificates if the root certificate has not been included yet. Mozilla should then expect the first performance audit within 12 months. > > 2.The CA did not know about the BRs, so did not get audited > according to the BRs during their previous audit cycle. However, the > CA does have a current valid audit statement indicating compliance > with WebTrust Principles and Criteria for Certification Authorities or > ETSI TS 102 042. > -- The BR PITRA option was initially provided for CAs to use > for their first BR audit, so they would not have to go through another > full audit until their next regularly scheduled annual audit. > -- The BR PITRA shall include a performance audit covering at > least one month, or more as determined by the auditor. If it is a performance audit, it is not a PITRA by definition. In some conversations with auditors, they are quite confused at this point. > -- However, it means that an untold number of the previously > issued certificates might not conform to the BRs. This could be > serious, depending on which BRs the CA did not previously comply with, > the number of BRs the CA did not previously comply with, and the > quantity of such certificates issued. Depending on the situation, the > CA may be asked to create a new root certificate for inclusion. Understood that's why you can expect a BR PITRA which may not be a "clean" report. > -- The CA and/or auditor shall provide a list of the BRs that > the previously issued certificates did not comply with. > -- The CA's next annual audit must include a full BR > performance audit. CAs usually perform annual audit over a 12 months period in the past. For example, an audit report dated in January 2015 shows the audit result of the period January - December 2014. If the first BR PITRA audit is performed now in 2014, which may contains a list of the BRs that yet to be complied with, CA must fix the issues on the list in 2015. If so, the first annual audit that include a full BR performance audit should be in January 2016. Is my understanding correct? > == > > As always, I will appreciate thoughtful and constructive feedback on > this. > > Kathleen > > > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > smime.p7s Description: S/MIME Cryptographic Signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
The case for point in time readiness audits (PITRAs) and performance audits
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 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. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CFCA Root Inclusion Request
On 6/19/14, 4:20 PM, Kathleen Wilson wrote: This begins the discussion of the request from CFCA to include the “CFCA GT CA” and “CFCA EV ROOT” root certificates, turn on all three trust bits for the “CFCA GT CA” root certificate, turn on the websites trust bit for the “CFCA EV ROOT” root certificate, and enable EV treatment for the ““CFCA EV ROOT” certificate. At the conclusion of this discussion I will provide a summary of issues noted and action items. If there are outstanding issues, then an additional discussion may be needed as follow-up. During the course of this discussion, this request was changed to only be for inclusion of the "CFCA EV Root" certificate, turn on all three trust bits, and enable EV for that root certificate. In this timeframe we also created and discussed a new wiki page: https://wiki.mozilla.org/CA:BaselineRequirements Currently https://wiki.mozilla.org/CA:BaselineRequirements#Audit_Mistakes says: "When egregious mistakes were overlooked by the auditor or there are a significant number of oversights, then the CA must resolve the issues and be re-audited. For the re-audit the CA can either get re-audited by a different auditor, or have the current auditor provide an immediate plan for correction and compliance, and then present a mid-term partial audit following that plan. ..." I propose to close this discussion with the following action items: ACTION CFCA: state (in the bug) their plan for remediation of all of the issues noted in this discussion. ACTION CFCA: Decide if they will be re-audited by the same auditor, or by a different auditor. ACTION PwC: If CFCA's decision is to use the same auditor, then provide a plan to improve audits so that the oversights that were found during this discussion will not be missed in future audits. ACTION Kathleen: After new audit statement has been received, start a second round of discussion for CFCA's root inclusion request. Does that sound reasonable? Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: The case for point in time readiness audits (PITRAs)
On Tue, Sep 2, 2014 at 1:26 PM, Kathleen Wilson wrote: > -- The BR PITRA shall include a performance audit covering at least > one month, or more as determined by the auditor. Does this make sense? A point in time audit would seem to intrinsically not cover a period of time. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Removal of 1024 bit roots - Thawte and GTE CyberTrust
On 9/2/14, 10:53 AM, Hubert Kario wrote: I've finally found some time to analyse the data from last months scan to see what happens when additional roots are removed[1,2]. The scan took place between 11th and 19th of July 2014. Sites scanned are taken from Alexa top 1 million sites as of 11th of July. Hubert, Thank you for doing this analysis and sharing your findings. Removing the Thawte 1024 bit roots[1] causes following changes: Untrusted: +33 sites. Incomplete chain: +153, -2 sites. Complete chain: -184 sites. Sites that become untrusted: aclens.com@199.242.144.30 brillenplatz.de@83.141.56.30 copagloja.com.br@54.225.100.66 cqccms.com.cn@124.207.135.23 datatilsynet.no@80.232.122.99 drewag.de@77.75.249.212 easy-forex.com@64.14.56.6 fachverlag-computerwissen.de@78.111.65.215 foreverwedstore.com@208.77.51.191 gold-super-markt.de@94.186.152.196 gold-to-go.com@94.186.152.196 golf.de@194.97.154.131 gumball3000.com@134.0.19.106 jokerit.com@89.250.52.17 loytec.com@88.198.4.4 madeindesign.de@194.213.124.118 meventi.com@78.47.246.235 motor-talk.de@94.198.62.121 nct.ie@193.120.166.32 ncts.ie@193.120.166.32 now.cn@119.146.222.146 pctonline.com@66.181.99.28 recyclingtoday.com@66.181.99.26 santander.be@212.78.166.49 showoffimports.nl@91.216.34.51 slotastic.com@54.204.19.24 tcd.ie@134.226.14.90 todaynic.com@119.146.222.146 whitireia.ac.nz@202.2.11.59 www.cqccms.com.cn@125.35.1.213 www.now.cn@119.146.222.153 www.todaynic.com@119.146.222.153 www.uri.edu@131.128.1.19 Looks like those SSL certs are 5 year certs that were issued in 2010, so those site administrators will be needing to update their certs within the next year. The change is currently targeted for Firefox 35 (early January). That gives Thawte/Symantec time to contact these customers, and get their certs updated. Removal of the GTE root has bigger impact: complete -86 incomplete +17, -8 untrusted +77 since the list is so large I won't be quoting it here. Would you please attach the list to the bug? Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: The case for point in time readiness audits (PITRAs)
I updated the wiki page some more, here's the text... https://wiki.mozilla.org/CA:BaselineRequirements#BR_Point_in_Time_Readiness_Assessment_.28BR_PITRA.29 == BR Point in Time Readiness Assessment (BR PITRA) == We previously said: "Any Certificate Authority being considered for root inclusion after February 15, 2013 must comply with Version 2.1 or later of Mozilla's CA Certificate Policy. This includes having a Baseline Requirements audit performed if the websites trust bit is to be enabled. *Note that the CA's first Baseline Requirements audit may be a Point in Time audit.*" There are two cases when a Point in Time Readiness Assessment of BR compliance (BR PITRA) may be used: 1.The CA has created a new root certificate, which is not yet in operation producing real certificates. In this case a BR PITRA prior to inclusion may be used, but the next annual audit after inclusion would need to be a full performance audit. Note: If the inclusion process spans more than one annual audit cycle, then more than one BR PITRA may be used, until the root certificate has been included or the root certificate is put into operation producing real certificates, whichever comes first. 2.The CA did not know about the BRs, so did not get audited according to the BRs during their previous audit cycle. However, the CA does have a current valid audit statement indicating compliance with WebTrust Principles and Criteria for Certification Authorities or ETSI TS 102 042. -- The BR PITRA option was initially provided for CAs to use for their first BR audit, so they would not have to go through another full audit until their next regularly scheduled annual audit. -- The BR PITRA shall include a performance audit covering at least one month, or more as determined by the auditor. -- However, it means that an untold number of the previously issued certificates might not conform to the BRs. This could be serious, depending on which BRs the CA did not previously comply with, the number of BRs the CA did not previously comply with, and the quantity of such certificates issued. Depending on the situation, the CA may be asked to create a new root certificate for inclusion. -- The CA and/or auditor shall provide a list of the BRs that the previously issued certificates did not comply with. -- The CA's next annual audit must include a full BR performance audit. == As always, I will appreciate thoughtful and constructive feedback on this. Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Removal of 1024 bit roots - Thawte and GTE CyberTrust
I've finally found some time to analyse the data from last months scan to see what happens when additional roots are removed[1,2]. The scan took place between 11th and 19th of July 2014. Sites scanned are taken from Alexa top 1 million sites as of 11th of July. Overall, the certificate stats look like this: Statistics from 440559 chains provided by 585568 hosts Server provided chainsCount Percent -+-+--- complete 36329662.0416 incomplete29441 5.0278 untrusted 19283132.9306 Trusted chain statistics Chain length Count Percent -+-+--- 2 2385 0.5414 3 42883997.3397 4 9314 2.1141 5 210.0048 CA key size in chains Count -+- ECDSA 256 3 ECDSA 384 3 RSA 1024 1718 RSA 2045 1 RSA 2048 868749 RSA 4096 17615 Chains with CA keyCount Percent -+-+--- ECDSA 256 3 0.0007 ECDSA 384 3 0.0007 RSA 1024 1708 0.3877 RSA 2045 1 0.0002 RSA 2048 43888999.6209 RSA 4096 17235 3.9121 Signature algorithm (ex. root) Count --+- ecdsa-with-SHA384 3 sha1WithRSAEncryption 384856 sha256WithRSAEncryption49903 sha384WithRSAEncryption12768 Eff. host cert chain LoS Count Percent -+-+--- 8038570487.5488 112 54852 12.4505 128 3 0.0007 Removing the Thawte 1024 bit roots[1] causes following changes: Untrusted: +33 sites. Incomplete chain: +153, -2 sites. Complete chain: -184 sites. Sites that become untrusted: aclens.com@199.242.144.30 brillenplatz.de@83.141.56.30 copagloja.com.br@54.225.100.66 cqccms.com.cn@124.207.135.23 datatilsynet.no@80.232.122.99 drewag.de@77.75.249.212 easy-forex.com@64.14.56.6 fachverlag-computerwissen.de@78.111.65.215 foreverwedstore.com@208.77.51.191 gold-super-markt.de@94.186.152.196 gold-to-go.com@94.186.152.196 golf.de@194.97.154.131 gumball3000.com@134.0.19.106 jokerit.com@89.250.52.17 loytec.com@88.198.4.4 madeindesign.de@194.213.124.118 meventi.com@78.47.246.235 motor-talk.de@94.198.62.121 nct.ie@193.120.166.32 ncts.ie@193.120.166.32 now.cn@119.146.222.146 pctonline.com@66.181.99.28 recyclingtoday.com@66.181.99.26 santander.be@212.78.166.49 showoffimports.nl@91.216.34.51 slotastic.com@54.204.19.24 tcd.ie@134.226.14.90 todaynic.com@119.146.222.146 whitireia.ac.nz@202.2.11.59 www.cqccms.com.cn@125.35.1.213 www.now.cn@119.146.222.153 www.todaynic.com@119.146.222.153 www.uri.edu@131.128.1.19 Adding certificate from comment 13 from bugzilla[1] changes the stats compared to above results in very small way, only 6 hosts loose untrusted status: aclens.com@199.242.144.30 cqccms.com.cn@124.207.135.23 easy-forex.com@64.14.56.6 madeindesign.de@194.213.124.118 santander.be@212.78.166.49 www.cqccms.com.cn@125.35.1.213 So in total, removal of certificates referenced in [1] makes at least 27 hosts untrusted. Removal of the GTE root has bigger impact: complete -86 incomplete +17, -8 untrusted +77 since the list is so large I won't be quoting it here. As such, I'd say that removing those roots now would be premature. 1 - https://bugzilla.mozilla.org/show_bug.cgi?id=986014 2 - https://bugzilla.mozilla.org/show_bug.cgi?id=1047011 -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Email: hka...@redhat.comg Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
