[cabfcert_policy] How chunky are our policy updates?

[Ben Wilson]

Thanks, Tim

Today we decided to divide up the proposed modifications to the Baseline
Requirements into the following 13 “chunks” to be presented in the following
order as ballots:

1. Sections 1 and 2 (General)
2. Section 4 (Certificate Life-cycle)
3. Section 5.1  (Physical Security)
4. Section 5.2 (Trusted Roles)
5. Section 5.3 (Background Checks)
6. Section 5.4 (Audit Logging)
7. Sections 6.1-6.4 (Key Management)
8. Section 6.6 (System Lifecycle Technical Controls)
9. Section 6.7 (Network Security Controls)
10. Section 7.1 and 7.2 (Profiles)
11. Sections 8 and 9 (Audit and Misc. Legal)
12. Section 6.5 (Computer Security Controls and Remaining items from the
Network and Certificate System Security Requirements)
13.  Section 3 (Identification, Authentication, and Naming)

I'll put these on the wiki under the Ballots page.
https://cabforum.org/wiki/Ballots 

Cheers,

Ben

-----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)
<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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4954 bytes
Desc: not available
Url : https://cabforum.org/pipermail/policyreview/attachments/20151105/a0091238/attachment.bin