Re: Changes to CA Program - Q1 2018
On 1/9/18 4:23 PM, Kathleen Wilson wrote: I will be re-assigning all of the root inclusion/update Bugzilla Bugs back to me, Done and I will take back responsibility for the high-level verification of the CA-provided data for root inclusion/update requests. I hope to begin work on this by next week. It will take me a few weeks to catch up, so I appreciate your patience. I will also take back responsibility for verifying CA annual updates, Done. and we will continue to work to improve that process and automation via the CCADB. We have added buttons to Audit Cases, in an effort to make it easier for CAs to enter all of their annual update information: 'Add/Update Root Cases', 'Edit Test Websites', etc. CAs, please let me know if you have other ideas about how to make your data entry for annual updates easier. Note that the buttons above were added based on feedback from CAs entering their data. http://ccadb.org/cas/updates I propose that we make the following changes to https://wiki.mozilla.org/CA/Application_Process#Process_Overview The wiki page has been updated, and the supporting wiki pages have also been updated. As always, I will appreciate your constructive feedback on the changes. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Changes to CA Program - Q1 2018
On 1/10/18 10:52 AM, Doug Beattie wrote: Thanks Kathleen. I only asked because you are trying to reduce the manpower for processing applications, and if a CA was already in the program there might not be a need to do as much. But on the other hand, this forces us to all comply with those pesky set of questions in "CA/Forbidden or Problematic Practices" that we've ignored and forces a formal review of the CPS. Correct, the root inclusion/update process is this way on purpose, so that CAs have to evaluate their practices and documentation, and fix their problems with compliance to Mozilla's policy and the BRs. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Changes to CA Program - Q1 2018
Thanks Kathleen. I only asked because you are trying to reduce the manpower for processing applications, and if a CA was already in the program there might not be a need to do as much. But on the other hand, this forces us to all comply with those pesky set of questions in "CA/Forbidden or Problematic Practices" that we've ignored and forces a formal review of the CPS. Doug > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of > Kathleen Wilson via dev-security-policy > Sent: Wednesday, January 10, 2018 1:45 PM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: Changes to CA Program - Q1 2018 > > > Is the same process used for existing CAs that need to add a new root and > new CAs applying for the first time? > > Yes. > > From > https://wiki.mozilla.org/CA/Application_Process#Process_Overview > "" > The same process is used to request: > - Root certificate inclusion for all CAs, even if the CA already has root > certificates included in Mozilla's root store > - Turning on additional trust bits for an already-included root certificate > - Enabling EV treatment for an already-included root certificate > - Including a renewed version of an already-included root certificate "" > > Kathleen > ___ > 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: Changes to CA Program - Q1 2018
Is the same process used for existing CAs that need to add a new root and new CAs applying for the first time? Yes. From https://wiki.mozilla.org/CA/Application_Process#Process_Overview "" The same process is used to request: - Root certificate inclusion for all CAs, even if the CA already has root certificates included in Mozilla's root store - Turning on additional trust bits for an already-included root certificate - Enabling EV treatment for an already-included root certificate - Including a renewed version of an already-included root certificate "" Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Changes to CA Program - Q1 2018
On 10/01/18 00:23, Kathleen Wilson wrote: > I would like to thank Aaron Wu for all of his help on our CA Program, > and am sorry to say that his last day at Mozilla will be January 12. I > have appreciated all of Aaron’s work, and it has been a pleasure to work > with him. Seconded. > I think this is a good time for us to make some changes to Mozilla’s > Root Inclusion Process to improve the effectiveness of the public > discussion phase by performing the detailed CP/CPS review prior to the > public discussion. The goal of this change is to focus the discussion > period on gathering community input and to allow the process to continue > when no objections are raised. This seems fine to me. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Changes to CA Program - Q1 2018
Hi Kathleen, Is the same process used for existing CAs that need to add a new root and new CAs applying for the first time? Doug > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of Kathleen > Wilson via dev-security-policy > Sent: Tuesday, January 9, 2018 7:24 PM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Changes to CA Program - Q1 2018 > > All, > > I would like to thank Aaron Wu for all of his help on our CA Program, and am > sorry to say that his last day at Mozilla will be January 12. I have > appreciated all > of Aaron’s work, and it has been a pleasure to work with him. > > I will be re-assigning all of the root inclusion/update Bugzilla Bugs back to > me, > and I will take back responsibility for the high-level verification of the CA- > provided data for root inclusion/update requests. > I will also take back responsibility for verifying CA annual updates, and we > will > continue to work to improve that process and automation via the CCADB. > > Wayne Thayer, Gerv Markham, and Ryan Sleevi have already taken > responsibility for the CA Incident bugs > (https://wiki.mozilla.org/CA/Incident_Dashboard). Thankfully, many of you > members of the CA Community are helping with this effort. > > Wayne and Devon O’Brien will take responsibility for ensuring that thorough > reviews of CA root inclusion/update requests happen (see below), and Wayne > will be responsible for the discussion phase of CA root inclusion/update > requests. We greatly appreciate all of the input that you all provide during > the > discussions of these requests, and are especially grateful for the thorough > reviews that have been performed and documented, with special thanks to > Ryan Sleevi, Andrew Whalley, and Devon O’Brien. > > I think this is a good time for us to make some changes to Mozilla’s Root > Inclusion Process to improve the effectiveness of the public discussion phase > by > performing the detailed CP/CPS review prior to the public discussion. The > goal of > this change is to focus the discussion period on gathering community input and > to allow the process to continue when no objections are raised. > > As such, I propose that we make the following changes to > https://wiki.mozilla.org/CA/Application_Process#Process_Overview > > ~~ PROPOSED CHANGES ~~ > > Step 1: A representative of the CA submits the request via Bugzilla and > provides > the information a listed in https://wiki.mozilla.org/CA/Information_Checklist. > > * Immediate change: None > > * Future change: CAs will directly input their Information Checklist data > into the > CCADB. > All root inclusion/update requests will begin with a Bugzilla Bug, as we do > today. > However, we will create a process by which CAs will be responsible for > entering > and updating their own data in the CCADB for their request. > > Step 2: A representative of Mozilla verifies the information provided by the > CA. > > * Immediate change: None > This will continue to be a high-level review to make sure that all of the > required > data has been provided, per the Information Checklist, and that the required > tests have been performed. > > * Future change: Improvements/automation in CCADB for verifying this data. > > Step 3: A representative of Mozilla adds the request to the queue for public > discussion. > > * Immediate change: Replace this step as follows. > NEW Step 3: A representative of Mozilla or of the CA Community (as agreed by a > Mozilla representative) thoroughly reviews the CA’s documents, and adds a > Comment in the Bugzilla Bug about their findings. > If the CA has everything in order, then the Comment will be that the request > may proceed, and the request will be added to the queue for public discussion. > Otherwise the Comment will list actions that the CA must complete. This may > include, but is not limited to fixing certificate content, updating process, > updating the CP/CPS, and obtaining new audit statements. The list of actions > will > be categorized into one of the following 3 groups: >--- 1: Must be completed before this request may proceed. >--- 2: Must be completed before this request may be approved, but the > request > may continue through the public discussion step in parallel with the CA > completing their action items. >--- 3: Must be completed before the CA’s next annual audit, but the request > may continue through the rest of the approval/inclusion process. > > Step 4: Anyone interested in the CA's application participates in discussions > of CA > requests currently in disc
Changes to CA Program - Q1 2018
All, I would like to thank Aaron Wu for all of his help on our CA Program, and am sorry to say that his last day at Mozilla will be January 12. I have appreciated all of Aaron’s work, and it has been a pleasure to work with him. I will be re-assigning all of the root inclusion/update Bugzilla Bugs back to me, and I will take back responsibility for the high-level verification of the CA-provided data for root inclusion/update requests. I will also take back responsibility for verifying CA annual updates, and we will continue to work to improve that process and automation via the CCADB. Wayne Thayer, Gerv Markham, and Ryan Sleevi have already taken responsibility for the CA Incident bugs (https://wiki.mozilla.org/CA/Incident_Dashboard). Thankfully, many of you members of the CA Community are helping with this effort. Wayne and Devon O’Brien will take responsibility for ensuring that thorough reviews of CA root inclusion/update requests happen (see below), and Wayne will be responsible for the discussion phase of CA root inclusion/update requests. We greatly appreciate all of the input that you all provide during the discussions of these requests, and are especially grateful for the thorough reviews that have been performed and documented, with special thanks to Ryan Sleevi, Andrew Whalley, and Devon O’Brien. I think this is a good time for us to make some changes to Mozilla’s Root Inclusion Process to improve the effectiveness of the public discussion phase by performing the detailed CP/CPS review prior to the public discussion. The goal of this change is to focus the discussion period on gathering community input and to allow the process to continue when no objections are raised. As such, I propose that we make the following changes to https://wiki.mozilla.org/CA/Application_Process#Process_Overview ~~ PROPOSED CHANGES ~~ Step 1: A representative of the CA submits the request via Bugzilla and provides the information a listed in https://wiki.mozilla.org/CA/Information_Checklist. * Immediate change: None * Future change: CAs will directly input their Information Checklist data into the CCADB. All root inclusion/update requests will begin with a Bugzilla Bug, as we do today. However, we will create a process by which CAs will be responsible for entering and updating their own data in the CCADB for their request. Step 2: A representative of Mozilla verifies the information provided by the CA. * Immediate change: None This will continue to be a high-level review to make sure that all of the required data has been provided, per the Information Checklist, and that the required tests have been performed. * Future change: Improvements/automation in CCADB for verifying this data. Step 3: A representative of Mozilla adds the request to the queue for public discussion. * Immediate change: Replace this step as follows. NEW Step 3: A representative of Mozilla or of the CA Community (as agreed by a Mozilla representative) thoroughly reviews the CA’s documents, and adds a Comment in the Bugzilla Bug about their findings. If the CA has everything in order, then the Comment will be that the request may proceed, and the request will be added to the queue for public discussion. Otherwise the Comment will list actions that the CA must complete. This may include, but is not limited to fixing certificate content, updating process, updating the CP/CPS, and obtaining new audit statements. The list of actions will be categorized into one of the following 3 groups: --- 1: Must be completed before this request may proceed. --- 2: Must be completed before this request may be approved, but the request may continue through the public discussion step in parallel with the CA completing their action items. --- 3: Must be completed before the CA’s next annual audit, but the request may continue through the rest of the approval/inclusion process. Step 4: Anyone interested in the CA's application participates in discussions of CA requests currently in discussion in the mozilla.dev.security.policy forum. * Immediate Change: Delete this step from the wiki page, because it is a general statement that does not belong here. Step 5: When the application reaches the head of the queue, a representative of Mozilla starts the public discussion for the CA in the mozilla.dev.security.policy forum. We prefer that at least two independent parties review and comment upon each application. * Immediate change: Due to the change in Step 3, this step becomes more of a time-limited comment period, during which CA Community members may raise concern or questions. But if no one posts any concerns in the discussion forum, then that will be interpreted as meaning that the CA Community does not have concern about the request. So, after the specified time, if no concerns are raised, then the discussion will be closed, and the request will move on to the approval phase.
