Re: Audit Letter Validation (ALV) on intermediate certs in CCADB
On 10/8/19 12:50 PM, Kathleen Wilson wrote: 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. I have added the following wiki page to provide instructions about ALV. https://wiki.mozilla.org/CA/Audit_Letter_Validation As always, I will greatly appreciate your constructive feedback on it. Thanks, Kathleen ___ 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
I've modified the first question of the survey and added a response option for exceptions: https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J3waNOW On Tue, Dec 24, 2019 at 5:55 AM Nick Lamb wrote: > On Mon, 23 Dec 2019 14:20:16 -0700 > Wayne Thayer via dev-security-policy > wrote: > > > I suggest that we modify question #1 to require CAs > > to attest that they intend to FULLY comply with version 2.7 of the > > policy and if they won't fully comply, to list all non-conforrmities. > > In other words, define an exception as anything that isn't compliant > > with the current policy rather than something we granted in the past. > > Thanks Wayne, I believe this would achieve my broader goals without > being too onerous for you/ Mozilla or the CAs. > > I look forward to any discussions prompted by the modified question or > by non-comformities disclosed as a result. > > > Nick. > ___ 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 Mon, 23 Dec 2019 14:20:16 -0700 Wayne Thayer via dev-security-policy wrote: > I suggest that we modify question #1 to require CAs > to attest that they intend to FULLY comply with version 2.7 of the > policy and if they won't fully comply, to list all non-conforrmities. > In other words, define an exception as anything that isn't compliant > with the current policy rather than something we granted in the past. Thanks Wayne, I believe this would achieve my broader goals without being too onerous for you/ Mozilla or the CAs. I look forward to any discussions prompted by the modified question or by non-comformities disclosed as a result. Nick. ___ 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 Sat, Dec 21, 2019 at 11:30 AM Nick Lamb wrote: > On Thu, 19 Dec 2019 10:23:19 -0700 > Wayne Thayer via dev-security-policy > wrote: > > > We've included a question about complying with the intermediate audit > > requirements in the January survey, but not a more general question > > about exceptions. I feel that an open-ended question such as this > > will be confusing for CAs to answer, and moreover I don't want to > > create the impression that Mozilla grants exceptions for policy > > violations because, as a general rule, we don't. > > As a general rule you don't grant exceptions, and so exceptions are > let's say, an exception to that general rule? Hence the name. > > Nope. The point is that we have no systematic process for handling exceptions, and to the best of my knowledge no list of granted exceptions exists. It's not even clear what constitutes an exception. Is any policy violation an exception? Does a certificate that was misissued 23 months ago but not revoked constitute an exception? Are the Symantec subordinates that are allow-listed exceptions? Is an exception something that a Mozilla representative interpreted for a CA as being permitted? Is an exception narrowly defined as something that Mozilla agreed to in writing? We may have been more liberal in making exceptions in the past, but I have hopefully been consistent in stating that it is the CA's responsibility to decide what to do and inform us rather than ask for permission. So, to the same end as my original proposal, I recommend instead that > Mozilla personalizes any CA survey sent out to a CA which they believe > currently benefits from any such exceptions - setting out what those > exceptions to its rules are for that CA. And in all communications the > text should be clear that any exceptions the CA believed were in place > are in fact spent as far as Mozilla is concerned unless they are > enumerated in this communication. > > This is challenging because no list of exceptions exists and because I'm not aware of a way to perform this type of customization in our survey system (I'll confirm with Kathleen). In the event there are in fact NO exceptions, that's just one small > tweak to the text. > > But potentially a very confusing tweak, unless we define what we mean by an exception. I suggest that we modify question #1 to require CAs to attest that they intend to FULLY comply with version 2.7 of the policy and if they won't fully comply, to list all non-conforrmities. In other words, define an exception as anything that isn't compliant with the current policy rather than something we granted in the past. In the event that one or two CAs benefit from some minor exception > which still has force, it's a little bit of work, and in the process a > firm reminder to both Mozilla and the CA of the ongoing price of such > exceptions. > > Not to mention a good argument that exceptions are unfair. And in the event that it's actually dozens of exceptions across many or > most CAs I hope the realisation of the effort involved will cause Wayne > to reconsider his previous claim that "as a general rule, we don't". > > I agree that it would be valuable to know if this is the case. One valuable opportunity from m.d.s.policy is for CAs to learn from > each others mistakes and in doing so avoid making the same or similar > mistakes themselves. But Mozilla has opportunities to learn from > mistakes here too, and I feel as though the mismatch between Kathleen's > expectation (that a situation should have "resolved" since 2016) and > the CA's understanding (that this constituted an indefinite exception > to Mozilla policy) is such a mistake. > > I agree. > Nick. > ___ 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 Thu, Dec 19, 2019 at 9:23 AM Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Tue, Nov 26, 2019 at 6:10 PM Nick Lamb via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > On Mon, 25 Nov 2019 14:12:46 -0800 > > Kathleen Wilson via dev-security-policy > > wrote: > > > > > CAs should have been keeping track of and resolving their own known > > > problems in regards to not fully following the BRs and Mozilla > > > policy. For example, I expect that a situation in which I responded > > > with an OK in 2016 would have been corrected in the 3 years since > > > that email was written. > > > > Perhaps to this end it would be useful for Mozilla's periodic survey > > letters to always ask each CA to list any exceptional circumstances they > > believe currently apply to them? > > We've included a question about complying with the intermediate audit > requirements in the January survey, but not a more general question about > exceptions. I feel that an open-ended question such as this will be > confusing for CAs to answer, and moreover I don't want to create the > impression that Mozilla grants exceptions for policy violations because, as > a general rule, we don't. > This would act both as a reminder to Mozilla of any such exceptions > > which they granted but may have assumed meanwhile ceased to be > > relevant, AND to the CA of any such exceptions upon which they find > > themselves still relying. > > > > The publication of CA responses is an opportunity for Mozilla, Peers > > and the wider community to comment on any discrepancy. > Maybe rather than including it in the survey, Mozilla should make a requirement that exception information be included in the yearly reporting? It could simply be a separate letter from the CA management requesting a continuation of the exception or could be a statement of excluded topics in the auditor's report, depending on the situation and structure of the audit. Thanks, Peter ___ 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 Thu, 19 Dec 2019 10:23:19 -0700 Wayne Thayer via dev-security-policy wrote: > We've included a question about complying with the intermediate audit > requirements in the January survey, but not a more general question > about exceptions. I feel that an open-ended question such as this > will be confusing for CAs to answer, and moreover I don't want to > create the impression that Mozilla grants exceptions for policy > violations because, as a general rule, we don't. As a general rule you don't grant exceptions, and so exceptions are let's say, an exception to that general rule? Hence the name. So, to the same end as my original proposal, I recommend instead that Mozilla personalizes any CA survey sent out to a CA which they believe currently benefits from any such exceptions - setting out what those exceptions to its rules are for that CA. And in all communications the text should be clear that any exceptions the CA believed were in place are in fact spent as far as Mozilla is concerned unless they are enumerated in this communication. In the event there are in fact NO exceptions, that's just one small tweak to the text. In the event that one or two CAs benefit from some minor exception which still has force, it's a little bit of work, and in the process a firm reminder to both Mozilla and the CA of the ongoing price of such exceptions. And in the event that it's actually dozens of exceptions across many or most CAs I hope the realisation of the effort involved will cause Wayne to reconsider his previous claim that "as a general rule, we don't". One valuable opportunity from m.d.s.policy is for CAs to learn from each others mistakes and in doing so avoid making the same or similar mistakes themselves. But Mozilla has opportunities to learn from mistakes here too, and I feel as though the mismatch between Kathleen's expectation (that a situation should have "resolved" since 2016) and the CA's understanding (that this constituted an indefinite exception to Mozilla policy) is such a mistake. Nick. ___ 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 Tue, Nov 26, 2019 at 6:10 PM Nick Lamb via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Mon, 25 Nov 2019 14:12:46 -0800 > Kathleen Wilson via dev-security-policy > wrote: > > > CAs should have been keeping track of and resolving their own known > > problems in regards to not fully following the BRs and Mozilla > > policy. For example, I expect that a situation in which I responded > > with an OK in 2016 would have been corrected in the 3 years since > > that email was written. > > Perhaps to this end it would be useful for Mozilla's periodic survey > letters to always ask each CA to list any exceptional circumstances they > believe currently apply to them? > > We've included a question about complying with the intermediate audit requirements in the January survey, but not a more general question about exceptions. I feel that an open-ended question such as this will be confusing for CAs to answer, and moreover I don't want to create the impression that Mozilla grants exceptions for policy violations because, as a general rule, we don't. This would act both as a reminder to Mozilla of any such exceptions > which they granted but may have assumed meanwhile ceased to be > relevant, AND to the CA of any such exceptions upon which they find > themselves still relying. > > The publication of CA responses is an opportunity for Mozilla, Peers > and the wider community to comment on any discrepancy. > > > Nick. > > ___ 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 Mon, 25 Nov 2019 14:12:46 -0800 Kathleen Wilson via dev-security-policy wrote: > CAs should have been keeping track of and resolving their own known > problems in regards to not fully following the BRs and Mozilla > policy. For example, I expect that a situation in which I responded > with an OK in 2016 would have been corrected in the 3 years since > that email was written. Perhaps to this end it would be useful for Mozilla's periodic survey letters to always ask each CA to list any exceptional circumstances they believe currently apply to them? This would act both as a reminder to Mozilla of any such exceptions which they granted but may have assumed meanwhile ceased to be relevant, AND to the CA of any such exceptions upon which they find themselves still relying. The publication of CA responses is an opportunity for Mozilla, Peers and the wider community to comment on any discrepancy. Nick. ___ 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/29/19 12:46 PM, Kathleen Wilson wrote: When an intermediate certificate is not listed in all of the necessary audit reports, it is a violation of Mozilla’s Root Store Policy and an incident report[1] must be filed via a Bugzilla Bug which must list the steps your CA is taking to resolve the situation. For example, it is a violation of section 8 of the CA/Browser Forum Baseline Requirements (BRs) and of Mozilla's Root Store Policy when there have been no BR audits for an intermediate certificate that is not technically constrained[2] via Extended Key Usage (EKU) and Name Constraints (and chains up to a root certificate that has the Websites trust bit enabled in Mozilla’s program). Each copy or doppelganger (same Subject+SPKI) intermediate certificate must have their SHA-256 Fingerprint listed in appropriate audit statements, according to each of their EKU or inherited trust (Derived Trust Bits). Certificates that are cross-signed versions of a root certificate also must have their SHA-256 Fingerprints specifically listed in the applicable audit statements, because these are also intermediate certificates. All, Email that I wrote years ago should NOT be considered as granting anyone exceptions to following the current version of the BRs and Mozilla's root store policy. It is the CA's responsibility to resolve problems that they were aware of years ago, but which are no longer acceptable. Things have changed, policies have changed, ability to identify problems and enforce policy have changed. CAs should have been keeping track of and resolving their own known problems in regards to not fully following the BRs and Mozilla policy. For example, I expect that a situation in which I responded with an OK in 2016 would have been corrected in the 3 years since that email was written. Thanks, Kathleen ___ 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 11/19/19 4:59 PM, Kathleen Wilson wrote: Note: I will add a report to wiki.mozilla.org/CA/Intermediate_Certificates to list all of the intermediate certificates that have been added to OneCRL and their revocation status. This will enable the CA Community to identify which certificates have been added to OneCRL but are not actually revoked. The report is available now. https://wiki.mozilla.org/CA/Intermediate_Certificates ~~ The following reports list the intermediate certificates that have been added to OneCRL, and their revocation status as indicated by the CA in the CCADB. Intermediate CA Certificates in OneCRL (HTML) Intermediate CA Certificates in OneCRL (CSV) ~~ Direct links: https://ccadb-public.secure.force.com/mozilla/IntermediateCertsInOneCRLReport https://ccadb-public.secure.force.com/mozilla/IntermediateCertsInOneCRLReportCSV ___ 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
All, As Ryan points out, root store operators enforce the BRs in different ways. Ryan wrote: > (Writing in an official capacity for the Google/Chrome Root Program) > > Our expectation is that CAs will be filing incident reports for: > 1) The failure to include and document as in-scope within the relevant > audit > 2) If the CA fails to revoke within the time period required by the > BRs, > the failure to revoke within the BR time period > > As two separate reports. > > We encourage CAs to carefully examine these reports and provide > updates as > to their planned revocations. My understanding is that Google’s root store expectations differ from Mozilla’s root store expectations regarding handling of non-technically-constrained intermediate certificates missing BR audits in 2 ways. 1) Mozilla is currently okay with the incident report for not revoking the non-BR-audited non-technically-constrained intermediate certificates to be handled in the same Bugzilla bug as the missing-audits incident report. However, I interpret Ryan’s message to mean that Google would like those to be two separate Bugzilla Bugs. Note: I will add a report to wiki.mozilla.org/CA/Intermediate_Certificates to list all of the intermediate certificates that have been added to OneCRL and their revocation status. This will enable the CA Community to identify which certificates have been added to OneCRL but are not actually revoked. 2) From Mozilla’s perspective, adding a non-technically-constrained intermediate certificate to Mozilla’s OneCRL (only consumed by Firefox) means that the BRs become out of scope for that certificate. So Mozilla does not require that certificate to be revoked. Thanks, Kathleen ___ 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
(Writing in an official capacity for the Google/Chrome Root Program) There are still a remarkable number of CAs that have not filed incident reports and not yet remediated this issue. A reminder, the Baseline Requirements, Section 8.1, states: > Certificates that are capable of being used to issue new certificates MUST > either be Technically Constrained in line > with section 7.1.5 and audited in line with section 8.7 only, or > Unconstrained and fully audited in line with all > remaining requirements from this section. > > *A Certificate is deemed as capable of being used to issue new > certificatesif it contains an X.509v3 basicConstraints extension, with the > cA boolean set to true and is therefore by definition aRoot CA Certificate > or a Subordinate CA Certificate*. Section 8.6 requires that this audit report be public. Section 2.2 of the BRs includes the following: > The CA SHALL publicly give effect to these Requirements and represent that > it will adhere to the latest > published version Section 4.9.1.2 of the BRs includes the following: > The Issuing CA SHALL revoke a Subordinate CA Certificate within seven (7) > days if one or more of the > following occurs: 5. The Issuing CA is made aware that the Certificate was not issued in > accordance with or that > Subordinate CA has not complied with this document or the applicable > Certificate Policy or Certification > Practice Statement; The failure to provide public audit statements that give effect to the coverage of these certificates, in scope of the BRs by definition, is a violation of the BRs, and ergo a violation of a CA's CP/CPS, and *MUST* be revoked. Our expectation is that CAs will be filing incident reports for: 1) The failure to include and document as in-scope within the relevant audit 2) If the CA fails to revoke within the time period required by the BRs, the failure to revoke within the BR time period As two separate reports. We encourage CAs to carefully examine these reports and provide updates as to their planned revocations. ___ 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
CAs, Here's additional information based on questions I've received about what to do if you determine that an intermediate certificate is not listed in an audit statement that it should have been in. When an intermediate certificate is not listed in all of the necessary audit reports, it is a violation of Mozilla’s Root Store Policy and an incident report[1] must be filed via a Bugzilla Bug which must list the steps your CA is taking to resolve the situation. For example, it is a violation of section 8 of the CA/Browser Forum Baseline Requirements (BRs) and of Mozilla's Root Store Policy when there have been no BR audits for an intermediate certificate that is not technically constrained[2] via Extended Key Usage (EKU) and Name Constraints (and chains up to a root certificate that has the Websites trust bit enabled in Mozilla’s program). Each copy or doppelganger (same Subject+SPKI) intermediate certificate must have their SHA-256 Fingerprint listed in appropriate audit statements, according to each of their EKU or inherited trust (Derived Trust Bits). Certificates that are cross-signed versions of a root certificate also must have their SHA-256 Fingerprints specifically listed in the applicable audit statements, because these are also intermediate certificates. Acceptable remediation for an intermediate certificate missing BR audits may include one or more of the following: 1. Have your auditor issue a revised report that includes the intermediate certificate. Note that if the certificate has been in existence for multiple past audit periods, this will not be considered a full remediation unless new reports are supplied for all of those periods in which the certificate did not appear on the original reports. 2. Revoke the intermediate certificate in accordance with BR section 4.9. If your CA decides not to revoke the certificate within the timeline specified by the BRs, then that is another incident, which must also be addressed in an Incident Report. Note that this may be handled in the same Bugzilla bug regarding the missing audits. 3. If the intermediate certificate is technically capable but not intended for TLS issuance, and revocation is not imminent, you may request that Mozilla add it to OneCRL by adding a comment to the Bugzilla bug with the request and sending email to me. Note: While adding the certificate to OneCRL satisfies Mozilla's expectations for remediation, it may not satisfy other root store programs. You are advised to seek their guidance on this issue. Thanks, Kathleen [1] https://wiki.mozilla.org/CA/Responding_To_An_Incident [2] https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#531-technically-constrained ___ 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 Letter Validation (ALV) on intermediate certs in CCADB
All, I would like to remind everyone about when these requirements for non-technically-constrained intermediate certificates came into effect for CAs in Mozilla’s program according to previous versions of Mozilla’s Root Store Policy[1] and previous CA Communications[2]. February 2013: Mozilla published version 2.1 of its CA Certificate Inclusion Policy[3], which introduced clauses #8, 9, and 10 requiring that intermediate certificates must either be technically constrained or be audited and publicly disclosed. Clause 11 added the requirement for BR audits (ETSI: DVCP and OVCP certificate policies for publicly trusted certificates - baseline requirements, WebTrust: and "SSL Baseline Requirements Audit Criteria V1.1" (as applicable to SSL certificate issuance)). June 2017: Mozilla published version 2.5 of its Root Store Policy[4], which specified in section 3.1.4 that audit statements must contain the SHA256 fingerprint of each root and intermediate certificate that was in scope of the audit. The pre-existing requirement for public-facing audit statements (including BR audits) for non-technically-constrained intermediate certs continued to remain in effect as described in sections 3.1.2 and 5.3. April 2017: Mozilla sent a CA Communication requiring response from all CAs[5] that stated that all audit statements submitted to Mozilla must be public-facing (not confidential), provided in English, and must include the SHA1 or SHA256 fingerprint of each certificate issuer covered by the audit scope. November 2017: Mozilla sent a CA Communication requiring response from all CAs[6] that had action items to review and confirm compliance with version 2.5 of Mozilla's Root Store Policy and clarified that each audit statement must include the SHA-256 fingerprint for each root and intermediate certificate in scope of the audit. September 2018: : Mozilla sent a CA Communication requiring response from all CAs[7] that stated that Mozilla would start rejecting audit statements that did not contain the required information. The communication also noted that version 2.6.1 of Mozilla’s Root Store policy added clarification to section 5.3.2 that newly-issued intermediates that are not technically constrained that have a currently valid audit report at the time of creation of the certificate, must appear on the CA's next periodic audit reports. Thanks, Kathleen [1] https://wiki.mozilla.org/CA/Root_Store_Policy_Archive [2] https://wiki.mozilla.org/CA/Communications [3] https://wiki.mozilla.org/CA:CertInclusionPolicyV2.1 [4] https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md [5] https://wiki.mozilla.org/CA/Communications#April_2017 [6] https://wiki.mozilla.org/CA/Communications#November_2017_CA_Communication [7] https://wiki.mozilla.org/CA/Communications#September_2018_CA_Communication ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
