RE: DRAFT January 2020 CA Communication
Should anything be mentioned about the allowed algorithms? That's the largest change to the policy and confirming the AlgorithmIdentifiers in each case may take some time. -Original Message- From: dev-security-policy On Behalf Of Wayne Thayer via dev-security-policy Sent: Thursday, December 19, 2019 10:10 AM To: mozilla-dev-security-policy Subject: DRAFT January 2020 CA Communication All, I've drafted a new email and survey that I plan to send to all CAs in the Mozilla program in early January. it focuses on compliance with the new (2.7) version of our Root Store Policy. I will appreciate your review and feedback on the draft: https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J3waNOW Note that two deadlines have been added to the communication: * Action 3 specifies that CAs must agree to update their CP/CPS, if needed to comply, prior to April 1, 2020. This is intended to prevent responses that we have found unacceptable in the past, e.g. waiting for an annual audit before updating the CP/CPS. * Action 5 requires CAs with failed Intermediate ALV results to publish a plan to correct these problems no later than Feb 15, 2020. Kathleen announced that we have begun validating audit letters for intermediate certificates back in October [1], and the requirement for audit statements to contain the SHA256 fingerprint of each root and intermediate certificate that was in scope of the audit dates back to 2017. CAs should have already taken action to resolve these issues, so this deadline is intended to convey the need for an immediate response. - Wayne [1] https://groups.google.com/d/msg/mozilla.dev.security.policy/M7NGwCh14DI/ZPDMRvDzBQAJ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DRAFT January 2020 CA Communication
On Thu, Dec 19, 2019 at 12:10 PM Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > All, > > I've drafted a new email and survey that I plan to send to all CAs in the > Mozilla program in early January. it focuses on compliance with the new > (2.7) version of our Root Store Policy. I will appreciate your review and > feedback on the draft: > > https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J3waNOW ## ACTION 1 ## One thing that I think came up from the past CA communications is that CAs assert this, but then end up failing to actually implement. Perhaps it may be worthwhile to be more explicit here about the expectations: """ Read version 2.7 of Mozilla's Root Store Policy. CAs are expected to review and abide by Version 2.7 of Mozilla's Root Store Policy. This includes a number of changes from previous versions. CAs MUST review this policy and ensure compliance, and CAs SHOULD carefully review the differences from previous versions of Mozilla's Policy. These changes have been discussed on mozilla.dev.security.policy and on GitHub. CAs that did not participate in these discussions or that have not yet reviewed these conversations should also review the discussions regarding these changes, to reduce the chance of confusion or misinterpretation. CAs are encouraged to raise any questions that they do not feel addressed in the Policy, or which the discussions and reasoning for the changes was not clear. """ There's probably a better way to word all of this, but where I'm trying to emphasize - The policy is the policy, and the ideal goal is that the policy stands by itself - That said, CAs understandably can misinterpret new policies when they use the logic of past policies or interpretations, while someone reading the policy fresh or which participated in the discussions about the policy would not be confused by - Even though CAs are required to follow m.d.s.p., the length of time for Policy 2.7 may mean they have had turnover or knowledge drain or simply forgot, so it's good to remind them that they can find information about each and every change discussed here or on GitHub, and they're expected to be familiar with it I'm trying to flag the "We didn't follow the discussion and continued to use our old interpretation" scenario, and see if there's something that can be done to remind folks to pay attention. ## ACTION 3 ## Would it make sense to add a third option, "All end-entity certificates that we issue or have issued after [date] and are within..." and let folks specify a date? I largely mention this because it's an existing Microsoft requirement as I understand it, and is somewhat enforced by Apple (at least for TLS) since July, so it may be that CAs are already compliant for new certificates, but also have unexpired old certificates that are not compliant. It may be that the answer is supposed to be "#1", but that wasn't immediately obvious to me when I first read. Alternatively, it might be clearer to reword that "Beginning on 1 July, 2020, *new* end-entity ...", to emphasize that it's not that Firefox/Mozilla will begin enforcing on 2020-07-01, but that certificates issued on/after that date will be required to be compliant (presumably, measured by notBefore) ## ACTION 5 ## I'm not sure if Salesforce forms allow it, but is it possible to have Action 5 include both a date selector and a comment field? It might make it easier to have consistency for options 3 & 4. Like "ACTION 5 Date" and "ACTION 5 Comments" Of course, if it doesn't, no worries. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Incident Reporting Guidance
Having received no comments on this proposal, I went ahead and added it to the wiki [1]. - Wayne [1] https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report On Wed, Dec 11, 2019 at 4:45 PM Wayne Thayer wrote: > While thinking about different ways to solve the problem of disclosing > missed revocation deadlines, we devised a solution for searching and > reporting on delayed revocations separately from other incidents. We've > begun to add a new Bugzilla "whiteboard" label to delayed revocation > incident bugs. We can then display those incidents separately on our > Incident Dashboard, as follows: > https://wiki.mozilla.org/CA/Incident_Dashboard#Revocation_Delays > > I've come to the conclusion that Mozilla should begin to require that CAs > submit a separate bug when a revocation deadline is missed. I dislike the > extra overhead of creating and managing more bugs, but doing so allows us > to provide clearer guidance to CAs, and it helps to ensure that we are > seeking out the root causes of revocation delays when they occur, rather > than potentially missing those learnings amongst the issue(s) that > triggered the revocation(s). To be clear, this proposal is not intended to > create more work or somehow punish CAs for missing revocation deadlines. > > This results in the following new guidance: > > CAs should submit a separate incident report when: > * Mozilla policy requires that the CA revoke one or more certificates by a > certain deadline, such as those in BR section 4.9, but that deadline is not > met by the CA > * In the process of researching one incident, another incident with a > distinct root cause and/or remediation is discovered > * After an incident bug is marked resolved, the incident reoccurs > > I will appreciate everyone's feedback on these proposed improvements to > the Incident Report section [1] of our Responding to an Incident wiki page. > If no responses are received over the next few days, I'll go ahead and make > these changes. > > - Wayne > > [1] https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report > > On Thu, Nov 21, 2019 at 10:48 AM Ryan Sleevi > wrote: > >> >> >> On Thu, Nov 21, 2019 at 10:54 AM Wayne Thayer via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >> >>> During the recent CA/Browser Forum meeting, I was asked to provide better >>> guidance on Mozilla's expectations for incident reporting. We're adding a >>> requirement for incident reporting to the new version of our policy [1], >>> but in this message I'm focused on the guidance provided on our wiki [2]. >>> The question was when to add information to an existing bug versus >>> creating >>> a new one. I'd like to propose adding the following guidance to the wiki >>> to >>> address this question: >>> >>> CAs should create a separate bug and file a new incident report when: >>> * In the process of researching one incident another incident with a >>> distinct root cause and/or remediation is discovered >>> * After an incident bug is marked resolved, the incident reoccurs >>> >>> A third possible addition would be: >>> * When a CA accidentally or intentionally misses a revocation deadline, a >>> separate bug should/must be filed examining the root cause and >>> remediation >>> for missing the deadline >>> >>> I believe the argument for this is that tracking revocation issues >>> separately will help us to focus on improving the agility of the web PKI. >>> On the other hand, Mozilla has not generally required separate reports in >>> the past, and doing so certainly creates more work for everyone involved. >>> It's not clear to me that the benefit of this outweighs the cost. >> >> >> Yeah, I've been thinking about this in light of the feedback Kathleen >> offered on >> https://groups.google.com/d/msg/mozilla.dev.security.policy/M7NGwCh14DI/jZft5ZH_AgAJ >> >> My primary objectives in treating it as two distinct issues are: >> 1) Ensuring the timely remediation of the root causes of whatever >> 'caused' the incident. In general, this should be 'sooner' than 'later' >> 2) Ensuring transparency about when CAs are having repeat "delayed >> revocation" issues; buried within issues themselves makes it difficult to >> track when there are repeat offenders, but also limits visibility into >> systemic issues that all CAs can/should be aware of when contemplating the >> design and maintenance of their PKI >> 3) Ensuring progress is made towards revocation, by not having bugs >> prematurely closed when the 'root' incident is resolved but the CA has >> taken no meaningful steps to bring their PKI back into compliance (yet) >> > ___ 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
DRAFT January 2020 CA Communication
All, I've drafted a new email and survey that I plan to send to all CAs in the Mozilla program in early January. it focuses on compliance with the new (2.7) version of our Root Store Policy. I will appreciate your review and feedback on the draft: https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J3waNOW Note that two deadlines have been added to the communication: * Action 3 specifies that CAs must agree to update their CP/CPS, if needed to comply, prior to April 1, 2020. This is intended to prevent responses that we have found unacceptable in the past, e.g. waiting for an annual audit before updating the CP/CPS. * Action 5 requires CAs with failed Intermediate ALV results to publish a plan to correct these problems no later than Feb 15, 2020. Kathleen announced that we have begun validating audit letters for intermediate certificates back in October [1], and the requirement for audit statements to contain the SHA256 fingerprint of each root and intermediate certificate that was in scope of the audit dates back to 2017. CAs should have already taken action to resolve these issues, so this deadline is intended to convey the need for an immediate response. - Wayne [1] https://groups.google.com/d/msg/mozilla.dev.security.policy/M7NGwCh14DI/ZPDMRvDzBQAJ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
