On 26/10/2018 01:13, Ryan Sleevi wrote:
On Thu, Oct 25, 2018 at 5:47 PM Jakob Bohm via dev-security-policy <
[email protected]> wrote:
On 25/10/2018 23:10, Wayne Thayer wrote:
On Thu, Oct 25, 2018 at 11:17 AM Joanna Fox via dev-security-policy <
[email protected]> wrote:
Questions about blank sections, thinking of a potential future
requirement. Sections such as 1.INTRODUCTION would remain blank as they
are
more titles than components, correct?
If no sections are allowed to be blank does this include both levels of
components such as 1.4 and 1.4.1?
I would argue that higher level sections (e.g. 1.4) aren't blank if
they
include subsections (e.g. 1.4.1). If there are no subsections under a
section (e.g. 1.1 or 2), then the section should not be blank.
Also, what is the opinion on adding sections to the CP/CPS that are not
included in the RFC?
Good question. My opinion is that it's okay to add sections as long as
they come after RFC 3647 defined sections and thus don't change the RFC
numbering. I've noted this in the policy issue -
https://github.com/mozilla/pkipolicy/issues/158
Would it be OK (I think it should) to place new sublevel sections under
appropriate higher level sections, after the RFC section numbers run out
at that level?
Can you explain why that is valuable?
What purpose do you believe the CP/CPS structure serves? One of the goals
of developing the structure in the RFC was to identify the common sections
applicable to all CAs, with a consistent structure, to allow easy
comparison between policies. Indeed, early audit processes proposed making
these policies machine readable and templated, to expedite comparisons.
I is quite obvious that the 15 year old RFC3647 doesn't cover all the
issues that need to be covered in a modern CP/CPS, the BRs already add
many subsections not in the RFC. I was giving concrete examples about
what kinds of sections to add.
However my question wasn't if additional sections could be added, this
was already asked by someone obviously intending to do so.
I was asking if such new sections could be placed where they would make
the most logical sense rather than being confined to a section 10
appendix. I then gave examples of how some commonly occurring issues
(such as a single CP/CPS covering both WebPKI and non-WebPKI roots)
would fit more neatly earlier in a policy document.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
