On Thu, Dec 19, 2019 at 3:12 PM Ryan Sleevi <r...@sleevi.com> wrote: > > 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=a051J00003waNOW > > > ## 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. > > I've incorporated these suggestions.
## 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) > > I made both of these changes as well. ## 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. > I added an optional date entry field to this question. All of these changes are now published at link I shared. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
