On Thu, Oct 25, 2018 at 10:11 PM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> On 26/10/2018 01:13, Ryan Sleevi wrote: > > On Thu, Oct 25, 2018 at 5:47 PM Jakob Bohm via dev-security-policy < > > dev-security-policy@lists.mozilla.org> 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 < > >>> dev-security-policy@lists.mozilla.org> 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. > > My response stating that I think this is okay was intended to include adding new subsections to the end of any of the existing sections. I do share some concern with this because it has and will continue to result in information being placed into new sections rather than appropriate existing sections. However, I also think there are legitimate reasons for adding sections, and it makes more sense to logically group them with similar content than at the end of the doc. > > > 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 > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
