[cabfcert_policy] How chunky are our policy updates?

[Jeremy Rowley]

We can, of course, work on multiple of these at one time and ballot them separately. Personally, I'd like to see naming handed over to the validation working group as an assignment. They seem to go hand-in-hand. Beyond physical security, I'd still like the CAB Forum to consider the operational security requirements we previously drafted but put on hold pending the IR review. Now that the IR review is over, we should look at the operational requirements and see what we should adopt from there. After all, the security working group originally established the following order for adoption: Network security -> Operational security -> Physical security. I think this is a good order and one we should continue with. 

-----Original Message-----
From: policyreview-bounces at cabforum.org [mailto:policyreview-bounces at cabforum.org] On Behalf Of Tim Hollebeek
Sent: Wednesday, October 7, 2015 1:38 AM
To: 'policyreview at cabforum.org' (policyreview at cabforum.org)
Subject: [cabfcert_policy] How chunky are our policy updates?

Now that we have finally come to the conclusion that there is, in fact, a middle ground between waiting a few years and then submitting a 1000 line ballot, and balloting each and every word individually, I decided to take a quick look yesterday afternoon into whether the changes we have made so far can indeed be divided up cleanly.

My initial impression is that it looks pretty good.  Because of the reorganization to RFC 3647 format, related changes generally tend to be in the same section of the document.  Some examples of potential ballots:

- 3.1 Naming requirements.  The BRs are silent here; we already have five or six new requirements and Ryan would like lots more.  Probably not a good one to start with due to complexity.

- 3.4/4.9 Requirement to authenticate persons making revocation requests

- 4.7 Requirements for Re-key

- Section 5.1: Physical Security.  We have about 8 new requirements; the BRs are silent

- Section 5.2: Trusted Roles.  We have lots of requirements here too; the BRs are silent

- Section 5.3: Background checks, training, and personnel issues

- Section 5.4: Improved audit logging

- Section 6.1.3/6.1.4: public key delivery

- Section 8.3: Auditor's Independence

- Section 9.4: Privacy requirements

There may be other ways of pulling them together into larger or smaller batches.  But it appears to me that a naïve section by section process already does a pretty good job of "chunking" changes into related groups.

Note that the order here is the order that they appear in the RFC format.  It may make more sense to ballot them from less controversial to more controversial instead.

-Tim


________________________________

This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.
_______________________________________________
Policyreview mailing list
Policyreview at cabforum.org
https://cabforum.org/mailman/listinfo/policyreview