Re: DRAFT January 2020 CA Communication
On 1/7/20 7:00 PM, Wayne Thayer wrote: Please note that the responses for questions 2, 3, and 5 do not yet properly display the date fields that were recently added. This has been fixed, so now the responses to questions 2, 3, and 5 are provided in one report each. Thanks, Kathleen ___ 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 1/7/20 7:00 PM, Wayne Thayer wrote: The email has been sent to all CAs in the Mozilla program requesting that they respond to the survey by the end of this month. This communication should have been received by the Primary POC(s) and CA email alias as recorded in the CCADB for CAs with included root certs. Please let me know if this communication did not make it to your CA's Primary POC and email alias. Thanks, Kathleen ___ 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 1/8/20 5:12 AM, Malcolm Doody wrote: AFAICS, for Q5 it looks as if it's *only* displaying the date, and not the associated free-format comments field. This caused me to realize that we have a very simple solution... For Actions 2, 3, and 5, I added separate links to show the Dates that have been provided in response. Thanks, Kathleen ___ 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 Wednesday, 8 January 2020 03:01:00 UTC, Wayne Thayer wrote: > Responses will be published on the wiki [1] as they are received. Please > note that the responses for questions 2, 3, and 5 do not yet properly > display the date fields that were recently added. AFAICS, for Q5 it looks as if it's *only* displaying the date, and not the associated free-format comments field. //M ___ 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
The email has been sent to all CAs in the Mozilla program requesting that they respond to the survey by the end of this month. Responses will be published on the wiki [1] as they are received. Please note that the responses for questions 2, 3, and 5 do not yet properly display the date fields that were recently added. - Wayne [1] https://wiki.mozilla.org/CA/Communications#January_2020_CA_Communication On Mon, Jan 6, 2020 at 12:41 PM Wayne Thayer wrote: > Thank you Malcolm, that is a good suggestion for consistency. I have > updated the survey and am still planning to send it out tomorrow (Tuesday). > > - Wayne > > On Mon, Jan 6, 2020 at 1:14 AM Malcolm Doody via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On Friday, January 3, 2020 at 10:27:26 AM UTC-5, Wayne Thayer wrote: >> > I've made some additional improvements to the survey based on feedback >> from >> > Kathleen: >> > >> https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J3waNOW >> >> Perhaps Action 2 should be split into Action 2 Date and Action 2 >> Comments, as per 3 & 5? >> >> //Malcolm >> >> ___ 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
Thank you Malcolm, that is a good suggestion for consistency. I have updated the survey and am still planning to send it out tomorrow (Tuesday). - Wayne On Mon, Jan 6, 2020 at 1:14 AM Malcolm Doody via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Friday, January 3, 2020 at 10:27:26 AM UTC-5, Wayne Thayer wrote: > > I've made some additional improvements to the survey based on feedback > from > > Kathleen: > > > https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J3waNOW > > Perhaps Action 2 should be split into Action 2 Date and Action 2 Comments, > as per 3 & 5? > > //Malcolm > > ___ 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 Friday, January 3, 2020 at 10:27:26 AM UTC-5, Wayne Thayer wrote: > I've made some additional improvements to the survey based on feedback from > Kathleen: > https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J3waNOW Perhaps Action 2 should be split into Action 2 Date and Action 2 Comments, as per 3 & 5? //Malcolm ___ 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 Fri, Jan 3, 2020 at 12:49 PM Corey Bonnell via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Friday, January 3, 2020 at 10:27:26 AM UTC-5, Wayne Thayer wrote: > > I've made some additional improvements to the survey based on feedback > from > > Kathleen: > > > > > https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J3waNOW > > > > I'm planning to send this out to CAs on Tuesday. > > > > On Mon, Dec 23, 2019 at 12:39 PM Wayne Thayer > wrote: > > > > > On Thu, Dec 19, 2019 at 3:59 PM Jeremy Rowley < > jeremy.row...@digicert.com> > > > wrote: > > > > > >> 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. > > >> > > >> > > > I'd argue that this is a clarification rather than a change, and > depending > > > on the CA, confirming compliance with the updates in section 5.1 may > not > > > take as long as the CPS updates. I'm not strongly opposed to calling > this > > > out but I'd argue that it's hard to miss when reviewing all of the > updates > > > as required by question #1. > > > > > Perhaps a minor question/nit, but it's better to raise it to remove all > doubt: for Action Item 3, if there exists revoked (but still unexpired) > end-entity certificates w/o a EKU but the CA has already switched to > universally including the EKU in end-entity certificates, should the CA > select "All unexpired end-entity certificates that we issue or have issued > and are within the scope of Mozilla’s policy currently comply with this > requirement" (which loosely interprets the meaning of "unexpired" to > encompass "non-revoked" as well), or should the CA select one of the other > options? > > Thank you Corey. I have explicitly added "non-revoked" to the option that you quoted above. I believe the intent of the discussion in > https://groups.google.com/d/msg/mozilla.dev.security.policy/5lAI-8lkQbM/1D392GR1BQAJ > indicates that Mozilla doesn't care about revoked certificates in this > case, so perhaps the language for option 1 should be clarified to specify > "unexpired, non-revoked" to better convey the intent. > > Thanks, > Corey > > ___ 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 Friday, January 3, 2020 at 10:27:26 AM UTC-5, Wayne Thayer wrote: > I've made some additional improvements to the survey based on feedback from > Kathleen: > > https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J3waNOW > > I'm planning to send this out to CAs on Tuesday. > > On Mon, Dec 23, 2019 at 12:39 PM Wayne Thayer wrote: > > > On Thu, Dec 19, 2019 at 3:59 PM Jeremy Rowley > > wrote: > > > >> 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. > >> > >> > > I'd argue that this is a clarification rather than a change, and depending > > on the CA, confirming compliance with the updates in section 5.1 may not > > take as long as the CPS updates. I'm not strongly opposed to calling this > > out but I'd argue that it's hard to miss when reviewing all of the updates > > as required by question #1. > > Perhaps a minor question/nit, but it's better to raise it to remove all doubt: for Action Item 3, if there exists revoked (but still unexpired) end-entity certificates w/o a EKU but the CA has already switched to universally including the EKU in end-entity certificates, should the CA select "All unexpired end-entity certificates that we issue or have issued and are within the scope of Mozilla’s policy currently comply with this requirement" (which loosely interprets the meaning of "unexpired" to encompass "non-revoked" as well), or should the CA select one of the other options? I believe the intent of the discussion in https://groups.google.com/d/msg/mozilla.dev.security.policy/5lAI-8lkQbM/1D392GR1BQAJ indicates that Mozilla doesn't care about revoked certificates in this case, so perhaps the language for option 1 should be clarified to specify "unexpired, non-revoked" to better convey the intent. Thanks, Corey ___ 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
I've made some additional improvements to the survey based on feedback from Kathleen: https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J3waNOW I'm planning to send this out to CAs on Tuesday. On Mon, Dec 23, 2019 at 12:39 PM Wayne Thayer wrote: > On Thu, Dec 19, 2019 at 3:59 PM Jeremy Rowley > wrote: > >> 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. >> >> > I'd argue that this is a clarification rather than a change, and depending > on the CA, confirming compliance with the updates in section 5.1 may not > take as long as the CPS updates. I'm not strongly opposed to calling this > out but I'd argue that it's hard to miss when reviewing all of the updates > as required by question #1. > ___ 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 3:59 PM Jeremy Rowley wrote: > 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. > > I'd argue that this is a clarification rather than a change, and depending on the CA, confirming compliance with the updates in section 5.1 may not take as long as the CPS updates. I'm not strongly opposed to calling this out but I'd argue that it's hard to miss when reviewing all of the updates as required by question #1. ___ 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 3:12 PM Ryan Sleevi 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=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. > > 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
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
