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?

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
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
              • Re:... Ryan Sleevi via dev-security-policy
              • Re:... Kathleen Wilson via dev-security-policy
              • Re:... Wayne Thayer via dev-security-policy
              • Re:... Kathleen Wilson via dev-security-policy
              • RE:... Tim Hollebeek via dev-security-policy
              • Re:... Jakob Bohm via dev-security-policy
              • RE:... Tim Hollebeek via dev-security-policy
              • Re:... Wayne Thayer via dev-security-policy
              • Re:... Joanna Fox via dev-security-policy
              • Re:... Wayne Thayer via dev-security-policy
              • Re:... Jakob Bohm via dev-security-policy
              • Re:... Ryan Sleevi via dev-security-policy
              • Re:... Jakob Bohm via dev-security-policy
              • Re:... Wayne Thayer via dev-security-policy
  • RE: What does "No Stipul... Brown, Wendy (10421) via dev-security-policy

Reply via email to