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 can see quite a bit of harm from your hypothetical, and have seen it in the policies reviewed, so it would be useful to understand why you would like to do this and what you see the purpose for CP/CPS that this would benefit. If you’re merely posing it as “someone” might want to, it seems like it would be better to let those “someones” speak to their needs and use cases. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
