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.
NEW 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, stating Mozilla’s intent to approve
the request and initiating a 3 week comment period. If no concerns are
raised during that time period, then the representative of Mozilla will
close the discussion and the request may proceed to the approval phase.
Step 6 - no change
Step 7 - add sub-bullet:
* A discussion may be extended beyond the initial comment period if
concerns or questions are raised that require further attention.
Steps 8-20 - no change
~~
I will appreciate constructive feedback on this.
Thanks,
Kathleen
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
