RE: Mozilla Policy Requirements CA Incidents
I like this approach. You could either add a page in the policy document or include the information in the management assertion letter (or auditor letter) that gives information about the auditor’s credentials and background. I also like the idea of summary on what the auditor followed up on from the previous year. This could be helpful to document where an auditor changed between years to see what they reviewed that another auditor noted or to see where the auditor had concerns from year to year. It can track where the CA may have a re-occurring issue instead of something that is a one-off concern. From: Ryan Sleevi Sent: Monday, October 14, 2019 4:12 PM To: Ryan Sleevi Cc: Jeremy Rowley ; Wayne Thayer ; mozilla-dev-security-policy Subject: Re: Mozilla Policy Requirements CA Incidents In the spirit of improving transparency, I've gone and filed https://github.com/mozilla/pkipolicy/issues/192 , which is specific to auditors. However, I want to highlight this model (the model used by the US Federal PKI), because it may also provide a roadmap for dealing with issues like this / those called by policy changes. Appendix C of those annual requirements for the US Federal PKI includes a number of useful requirements (really, all of them are in line with things we've discussed here), but two particularly relevant requirements are: Guidance: Previous year findings Did the auditor review findings from previous year and ensure all findings were corrected as proposed during the previous audit? Commentary: Often, the auditor sees an Audit Correction Action Plan, POA, or other evidence that the organization has recognized audit findings and intends to correct them, but the auditor is not necessarily engaged to assess the corrections at the time they are applied. The auditor should review that all proposed corrections have addressed the previous year’s findings. Guidance: Changes Because the FPKI relies on a mapped CP and/or CPS for comparable operations, has the auditor been apprised of changes both to documentation and operations from the previous audit? Commentary: CPs change over time and each Participating PKI in the FPKI has an obligation to remain in synch with the changing requirements of the applicable FPKI CP (either FBCA or COMMON Policy) – has the participating PKI’s CP and CPS been updated appropriately? If there have been other major changes in operations, has a summary since the last year’s audit been provided or discussed with the auditor? This might be a model to further include/require within the overall audit package. This would likely only make sense if also adding "Audit Operational Findings" (which Illustrative Guidance for WebTrust now includes guidance on, but which ETSI continues to refuse to add) and "Audit MOA Findings" (for which "MOA" may be instead seen as "Mozilla Root Certificate Policy" - i.e. the things above/beyond the BRs). We've already seen WebTrust similarly developing reporting for "Architectural Overview", and they've already updated reporting for "Assertion of Audit Scope", thus showing in many ways, WebTrust already has the tools available to meet these requirements. It would similarly be possible for ETSI-based audits to meet these requirements, since the reports provided to browsers need not be as limited as a Certification statement; they could include more holistic reporting, in line with the eIDAS Conformity Assessment Reports. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Audit Letter Validation (ALV) on intermediate certs in CCADB
On 10/8/19 12:50 PM, Kathleen Wilson wrote: CAs, There is now an "Audit Letter Validation (ALV)" button on intermediate certificate records in the CCADB. There is also a new task list item on your home page. In the summary section you will see a line item like the following. "Intermediate Certs with Failed ALV Results: 8" When that is non-zero, you will see a section that can be opened called "Check failed Audit Letter Validation (ALV) results" CAs, We have added a report called "My Certs Failed Audit Letter Validation" that is available to CAs via the 'Reports' tab in the 'CA Community Reports' folder. It is the same report as the "Check failed Audit Letter Validation (ALV) results" task list item. Filtered By:((1 AND 2 AND 3 AND 4 AND (5 OR 6) AND (7 OR 8)) AND 9) AND 10 1. CA Owner/Certificate Record Type equals Intermediate Certificate 2. Revocation Status equals Not Revoked 3. OneCRL Status not equal to Added to OneCRL 4. Valid To (GMT) greater than TODAY 5. Standard Audit ALV Found Cert equals FAIL 6. BR Audit ALV Found Cert equals FAIL 7. Mozilla Root Status equals Change Requested,Included 8. Microsoft Root Status equals Included,Change Requested 9. Technically Constrained equals False 10. Match Running User's Owner equals True Columns: Certificate Name, SHA-256 Fingerprint, Audits Same as Parent, Mozilla Root Status, Microsoft Root Status, Standard Audit ALV Results, Standard Audit ALV Comments, BR Audit ALV Results, BR Audit ALV Comments Thanks to those of you who have been proactively looking into the ALV results for your intermediate certificates. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Audit Reminder Email Summary
Forwarded Message Subject: Summary of October 2019 Audit Reminder Emails Date: Tue, 15 Oct 2019 19:00:07 + (GMT) Mozilla: Audit Reminder CA Owner: E-Tugra Root Certificates: E-Tugra Certification Authority Standard Audit: https://www.e-tugra.com.tr/Portals/6/Documents/LSTIAL_ETugra_2018.pdf Standard Audit Period End Date: 2018-08-03 BR Audit: https://www.e-tugra.com.tr/Portals/6/Documents/LSTIAL_ETugra_2018.pdf BR Audit Period End Date: 2018-08-03 EV Audit: https://www.e-tugra.com.tr/Portals/6/Documents/LSTIAL_ETugra_2018.pdf EV Audit Period End Date: 2018-08-03 CA Comments: null Mozilla: Audit Reminder CA Owner: NetLock Ltd. Root Certificates: NetLock Arany (Class Gold) Főtanúsítvány Standard Audit: https://netlock.hu/download/etsi-certification-netlock/?wpdmdl=57340 Standard Audit Period End Date: 2018-09-03 BR Audit: https://netlock.hu/download/etsi-certification-netlock/?wpdmdl=57340 BR Audit Period End Date: 2018-09-03 CA Comments: null Mozilla: Audit Reminder CA Owner: China Financial Certification Authority (CFCA) Root Certificates: CFCA EV ROOT Standard Audit: https://www.cpacanada.ca/generichandlers/aptifyattachmenthandler.ashx?attachmentid=223505 Standard Audit Period End Date: 2018-07-31 BR Audit: https://www.cpacanada.ca/generichandlers/aptifyattachmenthandler.ashx?attachmentid=223506 BR Audit Period End Date: 2018-07-31 EV Audit: https://www.cpacanada.ca/generichandlers/aptifyattachmenthandler.ashx?attachmentid=223507 EV Audit Period End Date: 2018-07-31 CA Comments: null ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Request to Include 4 Microsoft Root CAs
(Replying for the correct address this time) On Fri, Aug 16, 2019 at 4:28 PM Jason via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi All, > > This is Jason from the Microsoft PKI Services team. I’d like to add some > context to the note about the certs issued from the Microsoft RSA Root > Certificate Authority 2017. As you can see, these were all issued to a > domain registered to Microsoft. While these clearly violate the Subject > profile requirements in Section 7 of the BRs, nearly all the certs listed > meet the requirements for Test Certificate as listed in Section 1.6.1 of > the BRs, including the presence of the “Test” OID (2.23.140.2.1) in a > critical extension. A few of the test issuances did not meet the > requirements of 1.6.1 and we have adjusted our policy enforcement > mechanisms accordingly as a result. That said, we have created an incident > around this for purposes of reporting to our auditors. Please feel free to > let me know if you have questions. > > Thanks, > Jason Cooper > While this thread has closed, and Microsoft's roots have been included, I want to circle back on this, as recently another CA brought this up. Microsoft's answer here is not correct, and is actually quite concerning. Microsoft included the "Test" OID ( 2.23.140.2.1 ) not as a critical /extension OID/, but as the contents within an extension (specifically, certificatePolicies). This is actually quite concerning. The purpose of the "Test" OID was to be a 'poison' extension - i.e. an unrecognized critical extension that prevents the certificate from being usable - not a general "you can stick this anywhere in the cert" (e.g. within a QCStatements, for example). However, equally important is that while the term "Test Certificate" is included within the BRs, it's actually part of a specific reference to a particular validation method, within 3.2.2.4.9, which MUST NOT be used. So there's nothing in the BRs that authorize this Test Certificate, and the certificate does not contain "an extension with the specified Test Certificate CABF OID (2.23.140.2.1)" - i.e. an extension with the OID "2.23.140.2.1" is not present. I felt it important to correct this, on the thread, since this was the first occurrence of this misinterpretation. It also represents a Serious Misissuance by Microsoft, as it not only missed the requirements for Test Certificate, but also missed where they were explicitly forbidden from use. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
