Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?
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 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 dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?
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? For example, some CA may want to add a section like the following examples (these are numbers in the same overall sections as related standard sections) (The sections below are arbitrary and not proposed as any kind of standard): 1.1.2 Categories of root CA certificates under this policy 1.1.2.1 Application-trusted General roots 1.1.2.2 Browser-trusted WebPKI roots 1.1.2.3 Mail-application trusted email roots 1.1.2.4 System trusted code signing roots 1.1.2.5 Time stamping roots 1.1.2.6 Compatibility roots for use with older software 1.1.2.7 Historic roots used for historic signatures 1.1.2.8 Discontinued roots 1.1.2.9 Test roots 1.1.2.10 Experimental roots 1.6.5 Non-Normative references 3.1.7 Territorial name restrictions 4.9.17 Availability of historic revocation information 4.9.17.3 Historic revocation information for e-mail certificates. etc. 4.13 Intermediary CA certificate rotation procedures. 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
Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?
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 - Wayne ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?
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? Also, what is the opinion on adding sections to the CP/CPS that are not included in the RFC? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
