Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?
2,520 views
Skip to first unread message
Kathleen Wilson
Oct 9, 2018, 12:48:37 PM10/9/18
to mozilla-dev-s...@lists.mozilla.org
All,
I would like to create some written rules about using "No Stipulation"
in CP and CPS documents; e.g. what it means, and when it is OK to be used.
First, I will appreciate your thoughts about what the term "No
Stipulation" means. e.g. does it mean one or all of the following?
"No rules defined for this section"
"This section is not applicable"
"This section is not allowed"
"This section is not used"
Can "No Stipulation" mean different things based on the context of the
section?
For example
"1.3.5 Other Participants
No stipulation."
Does that mean “no other participants are allowed”?
Here is what RFC 3647 says about the term:
""
While many topics are identified, it is not necessary for a CP or a
CPS to include a concrete statement for every such topic. Rather, a
particular CP or CPS may state "no stipulation" for a component,
subcomponent, or element on which the particular CP or CPS imposes no
requirements or makes no disclosure. In this sense, the list of
topics can be considered a checklist of topics for consideration by
the CP or CPS writer.
It is recommended that each and every component and subcomponent be
included in a CP or CPS, even if there is "no stipulation"; this will
indicate to the reader that a conscious decision was made to include
or exclude a provision concerning that topic. This drafting style
protects against inadvertent omission of a topic, while facilitating
comparison of different certificate policies or CPSs, e.g., when
making policy mapping decisions.
""
It seems a little ambiguous to me, so I would like to have a written
statement about what "No Stipulation" means within CP and CPS documents,
especially in regards to SSL certificate issuance.
Here are two examples that I've seen recently.
== Example 1 ==
In this situation, the CA has one CP that covers different types of
roots, so the CPS for the different roots has the details. There is no
further detailed public documentation beyond the CPS.
In the CA's CP:
3.1.2 Need for Names to be Meaningful
No Stipulation
3.1.5 Uniqueness of Names
No Stipulation
3.2.2.1 Identity
No Stipulation
3.2.2.2 DBA/Tradename
No Stipulation
3.2.2.3 Verification of Country
No Stipulation
3.2.2.4 Validation of Domain Authorization or Control
No Stipulation
3.2.2.4.1 Validating the Applicant as a Domain Contact
No Stipulation
3.2.2.4.2 Email, Fax, SMS, or Postal Mail to Domain Contact
No Stipulation
3.2.2.4.3 Phone Contact with Domain Contact
No Stipulation
3.2.2.4.4 Constructed Email to Domain Contact
No Stipulation
3.2.2.4.5 Domain Authorization Document
No Stipulation
3.2.2.4.6 Agreed-Upon Change to Website
No Stipulation
3.2.2.4.7 DNS Change
No Stipulation
3.2.2.4.8 IP Address
No Stipulation
3.2.2.4.9 Test Certificate
No Stipulation
3.2.2.4.10 TLS Using a Random Number
No Stipulation
3.2.2.4.11 Any Other Method
This method has been retired and MUST NOT be used.
3.2.2.4.12 Validating Applicant as a Domain Contact
No Stipulation
3.2.2.5 Authentication for an IP Address
No Stipulation
3.2.2.6 Wildcard Domain Validation
No Stipulation
3.2.2.7 Data Source Accuracy
No Stipulation
3.2.2.8 CAA Records
No Stipulation
3.2.3 Authentication of Individual Identity
No Stipulation
3.2.4 Non-Verified Subscriber Information
No Stipulation
4.7.4 Notification of New Certificate Issuance to Subscriber
No stipulation
4.9.7 CRL Issuance Frequency
No Stipulation.
4.9.10 On-Line Revocation Checking Requirements
No Stipulation
5.4.6 Audit Log Accumulation System (Internal vs. External)
No Stipulation
6.1.5 Key Sizes
No Stipulation
6.2.3 Private Key Escrow
No Stipulation
6.2.5 Private Key Archival
No Stipulation
6.2.6 Private Key Transfer into or from a Cryptographic Module
No Stipulation
6.2.9 Deactivating Private Keys
No Stipulation
6.3.2 Certificate Operational Periods and Key Pair Usage Periods
No Stipulation
6.7 NETWORK SECURITY CONTROLS
No stipulation
The relevant CPS has the following sections with No Stipulation:
3.1.5 Uniqueness of Names
No Stipulation
3.2.2.5 Authentication for an IP Address
No Stipulation
3.2.2.6 Wildcard Domain Validation
No Stipulation
4.7.4 Notification of New Certificate Issuance to Subscriber
No Stipulation
5.4.6 Audit Log Accumulation System (Internal vs. External)
No Stipulation
6.2.3 Private Key Escrow
No Stipulation
6.2.5 Private Key Archival
No Stipulation
6.2.6 Private Key Transfer into or from a Cryptographic Module
No Stipulation
6.2.9 Deactivating Private Keys
No Stipulation
In this example you can see that the CA clarifies in the CPS which
domain validation methods can be used.
I'm not sure how to interpret the sections listed above that have "No
Stipulation" in both the CP and the CPS.
For instance, when I see "3.2.2.5 Authentication for an IP Address" with
"No Stipulation" in the CPS, it is not clear to me if the CA does not
allow for IP Addresses to be included in SSL certs, or if the CA just
allows any form of verification of IP Addresses.
== Example 2 ==
In the following situation, the CA does not have a separate CP document.
This one CPS document is the only public document about the CA's
policies/practices.
1.3.5 Other Participants
No stipulation.
3.2.2.4.1 Validating the Applicant as a Domain Contact
No stipulation.
3.2.2.4.5 Domain Authorization Document
No stipulation.
3.2.2.4.9 Test Certificate
No stipulation
3.2.2.4.10 TLS Using a Random Number
No stipulation
3.2.2.4.11 Any Other Method
No stipulation
3.2.2.4.12 Validating Applicant as a Domain Contact
No stipulation
3.2.4 Non-verified Subscriber Information
No stipulation.
4.2.2 Approval or Rejection of Certificate Applications
No stipulation.
4.4.1 Conduct Constituting Certificate Acceptance
No stipulation.
4.4.2 Publication of the Certificate by the CA
No stipulation.
4.5 Key Pair and Certificate Usage
No stipulation.
4.5.1 Subscriber Private Key and Certificate Usage
No stipulation.
4.5.2 Relying Party Public Key and Certificate Usage
No stipulation.
4.7 Certificate Re-key
No stipulation.
4.7.1 Circumstance for Certificate Re-key
No stipulation.
4.7.2 Who May Request Certification of a New Public Key
No stipulation.
4.7.3 Processing Certificate Re-keying Requests
No stipulation.
4.7.4 Notification of New Certificate Issuance to Subscriber
No stipulation.
4.7.5 Conduct Constituting Acceptance of a Re-keyed Certificate
No stipulation.
4.7.6 Publication of the Re-keyed Certificate by the CA
No stipulation.
4.7.7 Notification of Certificate Issuance by the CA to Other Entities
No stipulation.
4.9.8 Maximum Latency for CRLs
No stipulation.
4.9.13 Circumstances for Suspension
No stipulation.
4.9.14 Who Can Request Suspension
No stipulation.
4.9.15 Procedure for Suspension Request
No stipulation.
4.9.16 Limits on Suspension Period
No stipulation.
4.12 Key Escrow and Recovery
No stipulation.
4.12.1 Key Escrow and recovery Policy Practices
No stipulation.
5.2.4 Roles Requiring Separation of Duties
No stipulation.
5.4.4 Protection of Audit Log
No stipulation.
5.4.5 Audit Log Backup Procedures
No stipulation.
5.4.6 Audit Collection System
No stipulation.
5.7.3 Entity Private Key Compromise Procedures
No stipulation.
6.5.2 Computer Security Rating
No stipulation.
7.1.5 Name Constraints
No stipulation.
In this situation, is it reasonable to assume that the domain validation
procedures that have "No Stipulation" are not used? Or should the CA be
required to use specific language to indicate that?
Is it OK for the CA to say "No Stipulation" in all of the sections
listed above?
What does "No Stipulation" mean in each of the sections listed above?
==
As always, I will greatly appreciate your thoughtful and constructive
input on this discussion.
Thanks,
Kathleen
I would like to create some written rules about using "No Stipulation"
in CP and CPS documents; e.g. what it means, and when it is OK to be used.
First, I will appreciate your thoughts about what the term "No
Stipulation" means. e.g. does it mean one or all of the following?
"No rules defined for this section"
"This section is not applicable"
"This section is not allowed"
"This section is not used"
Can "No Stipulation" mean different things based on the context of the
section?
For example
"1.3.5 Other Participants
No stipulation."
Does that mean “no other participants are allowed”?
Here is what RFC 3647 says about the term:
""
While many topics are identified, it is not necessary for a CP or a
CPS to include a concrete statement for every such topic. Rather, a
particular CP or CPS may state "no stipulation" for a component,
subcomponent, or element on which the particular CP or CPS imposes no
requirements or makes no disclosure. In this sense, the list of
topics can be considered a checklist of topics for consideration by
the CP or CPS writer.
It is recommended that each and every component and subcomponent be
included in a CP or CPS, even if there is "no stipulation"; this will
indicate to the reader that a conscious decision was made to include
or exclude a provision concerning that topic. This drafting style
protects against inadvertent omission of a topic, while facilitating
comparison of different certificate policies or CPSs, e.g., when
making policy mapping decisions.
""
It seems a little ambiguous to me, so I would like to have a written
statement about what "No Stipulation" means within CP and CPS documents,
especially in regards to SSL certificate issuance.
Here are two examples that I've seen recently.
== Example 1 ==
In this situation, the CA has one CP that covers different types of
roots, so the CPS for the different roots has the details. There is no
further detailed public documentation beyond the CPS.
In the CA's CP:
3.1.2 Need for Names to be Meaningful
No Stipulation
3.1.5 Uniqueness of Names
No Stipulation
3.2.2.1 Identity
No Stipulation
3.2.2.2 DBA/Tradename
No Stipulation
3.2.2.3 Verification of Country
No Stipulation
3.2.2.4 Validation of Domain Authorization or Control
No Stipulation
3.2.2.4.1 Validating the Applicant as a Domain Contact
No Stipulation
3.2.2.4.2 Email, Fax, SMS, or Postal Mail to Domain Contact
No Stipulation
3.2.2.4.3 Phone Contact with Domain Contact
No Stipulation
3.2.2.4.4 Constructed Email to Domain Contact
No Stipulation
3.2.2.4.5 Domain Authorization Document
No Stipulation
3.2.2.4.6 Agreed-Upon Change to Website
No Stipulation
3.2.2.4.7 DNS Change
No Stipulation
3.2.2.4.8 IP Address
No Stipulation
3.2.2.4.9 Test Certificate
No Stipulation
3.2.2.4.10 TLS Using a Random Number
No Stipulation
3.2.2.4.11 Any Other Method
This method has been retired and MUST NOT be used.
3.2.2.4.12 Validating Applicant as a Domain Contact
No Stipulation
3.2.2.5 Authentication for an IP Address
No Stipulation
3.2.2.6 Wildcard Domain Validation
No Stipulation
3.2.2.7 Data Source Accuracy
No Stipulation
3.2.2.8 CAA Records
No Stipulation
3.2.3 Authentication of Individual Identity
No Stipulation
3.2.4 Non-Verified Subscriber Information
No Stipulation
4.7.4 Notification of New Certificate Issuance to Subscriber
No stipulation
4.9.7 CRL Issuance Frequency
No Stipulation.
4.9.10 On-Line Revocation Checking Requirements
No Stipulation
5.4.6 Audit Log Accumulation System (Internal vs. External)
No Stipulation
6.1.5 Key Sizes
No Stipulation
6.2.3 Private Key Escrow
No Stipulation
6.2.5 Private Key Archival
No Stipulation
6.2.6 Private Key Transfer into or from a Cryptographic Module
No Stipulation
6.2.9 Deactivating Private Keys
No Stipulation
6.3.2 Certificate Operational Periods and Key Pair Usage Periods
No Stipulation
6.7 NETWORK SECURITY CONTROLS
No stipulation
The relevant CPS has the following sections with No Stipulation:
3.1.5 Uniqueness of Names
No Stipulation
3.2.2.5 Authentication for an IP Address
No Stipulation
3.2.2.6 Wildcard Domain Validation
No Stipulation
4.7.4 Notification of New Certificate Issuance to Subscriber
No Stipulation
5.4.6 Audit Log Accumulation System (Internal vs. External)
No Stipulation
6.2.3 Private Key Escrow
No Stipulation
6.2.5 Private Key Archival
No Stipulation
6.2.6 Private Key Transfer into or from a Cryptographic Module
No Stipulation
6.2.9 Deactivating Private Keys
No Stipulation
In this example you can see that the CA clarifies in the CPS which
domain validation methods can be used.
I'm not sure how to interpret the sections listed above that have "No
Stipulation" in both the CP and the CPS.
For instance, when I see "3.2.2.5 Authentication for an IP Address" with
"No Stipulation" in the CPS, it is not clear to me if the CA does not
allow for IP Addresses to be included in SSL certs, or if the CA just
allows any form of verification of IP Addresses.
== Example 2 ==
In the following situation, the CA does not have a separate CP document.
This one CPS document is the only public document about the CA's
policies/practices.
1.3.5 Other Participants
No stipulation.
3.2.2.4.1 Validating the Applicant as a Domain Contact
No stipulation.
3.2.2.4.5 Domain Authorization Document
No stipulation.
3.2.2.4.9 Test Certificate
No stipulation
3.2.2.4.10 TLS Using a Random Number
No stipulation
3.2.2.4.11 Any Other Method
No stipulation
3.2.2.4.12 Validating Applicant as a Domain Contact
No stipulation
3.2.4 Non-verified Subscriber Information
No stipulation.
4.2.2 Approval or Rejection of Certificate Applications
No stipulation.
4.4.1 Conduct Constituting Certificate Acceptance
No stipulation.
4.4.2 Publication of the Certificate by the CA
No stipulation.
4.5 Key Pair and Certificate Usage
No stipulation.
4.5.1 Subscriber Private Key and Certificate Usage
No stipulation.
4.5.2 Relying Party Public Key and Certificate Usage
No stipulation.
4.7 Certificate Re-key
No stipulation.
4.7.1 Circumstance for Certificate Re-key
No stipulation.
4.7.2 Who May Request Certification of a New Public Key
No stipulation.
4.7.3 Processing Certificate Re-keying Requests
No stipulation.
4.7.4 Notification of New Certificate Issuance to Subscriber
No stipulation.
4.7.5 Conduct Constituting Acceptance of a Re-keyed Certificate
No stipulation.
4.7.6 Publication of the Re-keyed Certificate by the CA
No stipulation.
4.7.7 Notification of Certificate Issuance by the CA to Other Entities
No stipulation.
4.9.8 Maximum Latency for CRLs
No stipulation.
4.9.13 Circumstances for Suspension
No stipulation.
4.9.14 Who Can Request Suspension
No stipulation.
4.9.15 Procedure for Suspension Request
No stipulation.
4.9.16 Limits on Suspension Period
No stipulation.
4.12 Key Escrow and Recovery
No stipulation.
4.12.1 Key Escrow and recovery Policy Practices
No stipulation.
5.2.4 Roles Requiring Separation of Duties
No stipulation.
5.4.4 Protection of Audit Log
No stipulation.
5.4.5 Audit Log Backup Procedures
No stipulation.
5.4.6 Audit Collection System
No stipulation.
5.7.3 Entity Private Key Compromise Procedures
No stipulation.
6.5.2 Computer Security Rating
No stipulation.
7.1.5 Name Constraints
No stipulation.
In this situation, is it reasonable to assume that the domain validation
procedures that have "No Stipulation" are not used? Or should the CA be
required to use specific language to indicate that?
Is it OK for the CA to say "No Stipulation" in all of the sections
listed above?
What does "No Stipulation" mean in each of the sections listed above?
==
As always, I will greatly appreciate your thoughtful and constructive
input on this discussion.
Thanks,
Kathleen
(RS) Tyler Schroder
Oct 9, 2018, 2:34:42 PM10/9/18
to dev-secur...@lists.mozilla.org
The legal definition that I came acrosss is " In United States law<https://en.wikipedia.org/wiki/United_States_law>, a stipulation is a formal legal acknowledgment and agreement made between opposing parties before a pending hearing<https://en.wikipedia.org/wiki/Hearing_%28law%29> or trial<https://en.wikipedia.org/wiki/Trial_%28law%29>. For example, both parties might stipulate to certain facts and so not have to argue them in court. After the stipulation is entered into, it is presented to the judge." [1]
On 10/9/2018 12:48 PM, Kathleen Wilson via dev-security-policy wrote:
CAUTION: This message was sent from outside the company.
With no other policy document defined, I would prefer clear language to be used describing validation methods to prevent a misinterpretation.
Is it OK for the CA to say "No Stipulation" in all of the sections
listed above?
Several of those sections such as 5.X would worry me if no situational is used as in "not defined". I would prefer to see a clear separator between "this does not apply", "this section is intentionally left blank". The RFC leads me to believe that in the two examples they would be intentionally written without being defined. I would expect if those provisions apply to be found in a separate CP document for each root.
What does "No Stipulation" mean in each of the sections listed above?
==
As always, I will greatly appreciate your thoughtful and constructive
input on this discussion.
Thanks,
Kathleen
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy
R. Tyler Schroder
redo...@redcoded.com<mailto:redo...@redcoded.com>
[1] https://en.wikipedia.org/wiki/Stipulation
On 10/9/2018 12:48 PM, Kathleen Wilson via dev-security-policy wrote:
CAUTION: This message was sent from outside the company.
Is it OK for the CA to say "No Stipulation" in all of the sections
listed above?
What does "No Stipulation" mean in each of the sections listed above?
==
As always, I will greatly appreciate your thoughtful and constructive
input on this discussion.
Thanks,
Kathleen
dev-security-policy mailing list
dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy
R. Tyler Schroder
redo...@redcoded.com<mailto:redo...@redcoded.com>
[1] https://en.wikipedia.org/wiki/Stipulation
Brown, Wendy (10421)
Oct 9, 2018, 2:55:07 PM10/9/18
to dev-secur...@lists.mozilla.org
Kathleen -
My interpretation of a "No Stipulation" in a CP is that the Policy has "No rules defined for this section"
In these cases, I expect the CPS to state what is actually done in support of that section and therefore "No Stipulation" is not appropriate in a CPS. The CPS should instead state whether or not they implement anything in response to that section or if they consider that section Not Applicable because there are no stated requirements.
It can mean slightly different things in different sections so for example
1.3.5 Other Participants - I would expect the CPS to list what other participants might be involved
Where as
3.1.5 Uniqueness of Names - I would expect the CPS to state whether or not they enforce Uniqueness of names and if they do - how this is enforced
In a TLS CP/CPS that adheres to the BRs, I would expect the CPS to clearly state which of the validation methods is supported and how, where the CP may leave this up to individual subordinate CAs by having No Stipulation at the CP level. For these sections I would expect the CPS to either state the method is not supported or it is and how. "Not applicable" would not be appropriate.
Thanks, (just my personal opinion)
Wendy Brown
Protiviti Government Services
703-299-4705 (office) 703-965-2990 (cell)
wendy...@protiviti.com
-----------------------------
Date: Tue, 9 Oct 2018 09:48:26 -0700
From: Kathleen Wilson <kwi...@mozilla.com>
To: mozilla-dev-s...@lists.mozilla.org
Subject: What does "No Stipulation" mean, and when is it OK to use it
in CP/CPS?
Message-ID: <n5SdneEd28pGRiHG...@mozilla.org>
Content-Type: text/plain; charset=utf-8; format=flowed
All,
I would like to create some written rules about using "No Stipulation"
in CP and CPS documents; e.g. what it means, and when it is OK to be used.
First, I will appreciate your thoughts about what the term "No Stipulation" means. e.g. does it mean one or all of the following?
"No rules defined for this section"
"This section is not applicable"
"This section is not allowed"
"This section is not used"
Can "No Stipulation" mean different things based on the context of the section?
For example
"1.3.5 Other Participants
No stipulation."
Does that mean ?no other participants are allowed??
My interpretation of a "No Stipulation" in a CP is that the Policy has "No rules defined for this section"
In these cases, I expect the CPS to state what is actually done in support of that section and therefore "No Stipulation" is not appropriate in a CPS. The CPS should instead state whether or not they implement anything in response to that section or if they consider that section Not Applicable because there are no stated requirements.
It can mean slightly different things in different sections so for example
1.3.5 Other Participants - I would expect the CPS to list what other participants might be involved
Where as
3.1.5 Uniqueness of Names - I would expect the CPS to state whether or not they enforce Uniqueness of names and if they do - how this is enforced
In a TLS CP/CPS that adheres to the BRs, I would expect the CPS to clearly state which of the validation methods is supported and how, where the CP may leave this up to individual subordinate CAs by having No Stipulation at the CP level. For these sections I would expect the CPS to either state the method is not supported or it is and how. "Not applicable" would not be appropriate.
Thanks, (just my personal opinion)
Wendy Brown
Protiviti Government Services
703-299-4705 (office) 703-965-2990 (cell)
wendy...@protiviti.com
-----------------------------
Date: Tue, 9 Oct 2018 09:48:26 -0700
From: Kathleen Wilson <kwi...@mozilla.com>
To: mozilla-dev-s...@lists.mozilla.org
Subject: What does "No Stipulation" mean, and when is it OK to use it
in CP/CPS?
Message-ID: <n5SdneEd28pGRiHG...@mozilla.org>
Content-Type: text/plain; charset=utf-8; format=flowed
All,
I would like to create some written rules about using "No Stipulation"
in CP and CPS documents; e.g. what it means, and when it is OK to be used.
First, I will appreciate your thoughts about what the term "No Stipulation" means. e.g. does it mean one or all of the following?
"No rules defined for this section"
"This section is not applicable"
"This section is not allowed"
"This section is not used"
Can "No Stipulation" mean different things based on the context of the section?
For example
"1.3.5 Other Participants
No stipulation."
Is it OK for the CA to say "No Stipulation" in all of the sections listed above?
What does "No Stipulation" mean in each of the sections listed above?
==
As always, I will greatly appreciate your thoughtful and constructive input on this discussion.
Thanks,
Kathleen
NOTICE: Protiviti is a global consulting and internal audit firm composed of experts specializing in risk and advisory services. Protiviti is not licensed or registered as a public accounting firm and does not issue opinions on financial statements or offer attestation services. This electronic mail message is intended exclusively for the individual or entity to which it is addressed. This message, together with any attachment, may contain confidential and privileged information. Any views, opinions or conclusions expressed in this message are those of the individual sender and do not necessarily reflect the views of Protiviti Inc. or its affiliates. Any unauthorized review, use, printing, copying, retention, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email message to the sender and delete all copies of this message. Thank you.
==
As always, I will greatly appreciate your thoughtful and constructive input on this discussion.
Thanks,
Kathleen
Tim Hollebeek
Oct 9, 2018, 3:03:11 PM10/9/18
to dev-secur...@lists.mozilla.org
RFC 3647 disagrees:
"Rather, a particular CP or CPS may state "no stipulation" for a component,
subcomponent, or element on which the particular CP or CPS imposes no
requirements or makes no disclosure."
"Rather, a particular CP or CPS may state "no stipulation" for a component,
subcomponent, or element on which the particular CP or CPS imposes no
requirements or makes no disclosure."
" It is recommended that each and every component and subcomponent be
included in a CP or CPS, even if there is "no stipulation"; this will
indicate to the reader that a conscious decision was made to include
or exclude a provision concerning that topic. This drafting style
protects against inadvertent omission of a topic, while facilitating
comparison of different certificate policies or CPSs, e.g., when
making policy mapping decisions."
-Tim
included in a CP or CPS, even if there is "no stipulation"; this will
indicate to the reader that a conscious decision was made to include
or exclude a provision concerning that topic. This drafting style
protects against inadvertent omission of a topic, while facilitating
comparison of different certificate policies or CPSs, e.g., when
making policy mapping decisions."
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
Kathleen Wilson
Oct 11, 2018, 8:27:49 PM10/11/18
to mozilla-dev-s...@lists.mozilla.org
Based on the input into this discussion so far, I propose to add the
following section to the Required part of this wiki page:
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices
We can consider adding text about this directly to Mozilla's Root Store
Policy later. (I'll file the request/issue in github.)
-- Proposed Text --
Section Heading: CP/CPS Structured According to RFC 3647
CP/CPS documents must be structured according to RFC 3647. This
requirement is stated in section 2.2 of the CA/Browser Forum Baseline
Requirements, with the effective of 31 May 2018. Further, CP/CPS
documents should include every component and subcomponent, and the
placement of information should be aligned with the BRs; e.g. domain
validation practices should be documented in section 3.2.2.4 of the CA’s
CP/CPS.
The words "No Stipulation" mean that the particular document imposes no
requirements related to that section.
Any CPS that falls within the scope of Mozilla’s program must not use
the words “No stipulation” unless the corresponding section in the
CA/Browser Forum Baseline Requirements state “No stipulation”, “Not
applicable”, or is blank. The words “Not applicable” are acceptable to
indicate that the CA’s policies forbid the practice that is the title of
the section. Language similar to “We do not perform <subject of the
section>” is preferred. If a full description of a section is repeated
elsewhere in the document, language similar to “Refer to Section 1.2.3”
is preferred.
Examples:
- If your CA does not allow a particular domain validation method to be
used, then the CP or CPS should say that, e.g. "This method of domain
validation is not used".
- The BRs do not allow certificate suspension, so the CA’s CPS must
state that certificate suspension is not allowed, and then the other
sections related to suspension should say “Not applicable”.
- If your CA does not issue SSL certs containing IP addresses, then
section 3.2.2.5, ‘Authentication for an IP Address’ in your CP or CPS
should say that such certificate issuance is not allowed; e.g. “No IP
address certificates are issued under this CPS.”
----
I will appreciate your constructive feedback on this.
Thanks,
Kathleen
following section to the Required part of this wiki page:
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices
We can consider adding text about this directly to Mozilla's Root Store
Policy later. (I'll file the request/issue in github.)
-- Proposed Text --
Section Heading: CP/CPS Structured According to RFC 3647
CP/CPS documents must be structured according to RFC 3647. This
requirement is stated in section 2.2 of the CA/Browser Forum Baseline
Requirements, with the effective of 31 May 2018. Further, CP/CPS
documents should include every component and subcomponent, and the
placement of information should be aligned with the BRs; e.g. domain
validation practices should be documented in section 3.2.2.4 of the CA’s
CP/CPS.
The words "No Stipulation" mean that the particular document imposes no
requirements related to that section.
Any CPS that falls within the scope of Mozilla’s program must not use
the words “No stipulation” unless the corresponding section in the
CA/Browser Forum Baseline Requirements state “No stipulation”, “Not
applicable”, or is blank. The words “Not applicable” are acceptable to
indicate that the CA’s policies forbid the practice that is the title of
the section. Language similar to “We do not perform <subject of the
section>” is preferred. If a full description of a section is repeated
elsewhere in the document, language similar to “Refer to Section 1.2.3”
is preferred.
Examples:
- If your CA does not allow a particular domain validation method to be
used, then the CP or CPS should say that, e.g. "This method of domain
validation is not used".
- The BRs do not allow certificate suspension, so the CA’s CPS must
state that certificate suspension is not allowed, and then the other
sections related to suspension should say “Not applicable”.
- If your CA does not issue SSL certs containing IP addresses, then
section 3.2.2.5, ‘Authentication for an IP Address’ in your CP or CPS
should say that such certificate issuance is not allowed; e.g. “No IP
address certificates are issued under this CPS.”
----
I will appreciate your constructive feedback on this.
Thanks,
Kathleen
Pedro Fuentes
Oct 15, 2018, 3:48:38 AM10/15/18
to mozilla-dev-s...@lists.mozilla.org
Hello,
I've a question closely related to this. I'd appreciate guidance.
I'm refactoring our CP & CPS documents considering that a CA can issue different types of certificates, so there would be multiple CP and one CPS.
My strategy is that if the stipulation is defined in one of the document (CP or CPS), then the other document can refer to the other (CPS or CP).
So, for example, as the CPS will support/implement different CP, for certain aspects (i.e. suspension), I'd like to refer to the CP as source, with the text "As stipulated in the appropriate CP". Like wise, in certain cases the stipulation could be defined in the CPS, so the CP would have the text "As stipulated in the CPS". This means that someone evaluating the practices for SSL certificates would have to consider jointly the CP of SSL certificates and the CPS, while someone evaluating personal certificates for email should consider the CP for S/MIME certificates and the CPS.
I used this in the past while writing some docs for customers... Would this be cross-referencing still acceptable?
Thanks,
Pedro
I've a question closely related to this. I'd appreciate guidance.
I'm refactoring our CP & CPS documents considering that a CA can issue different types of certificates, so there would be multiple CP and one CPS.
My strategy is that if the stipulation is defined in one of the document (CP or CPS), then the other document can refer to the other (CPS or CP).
So, for example, as the CPS will support/implement different CP, for certain aspects (i.e. suspension), I'd like to refer to the CP as source, with the text "As stipulated in the appropriate CP". Like wise, in certain cases the stipulation could be defined in the CPS, so the CP would have the text "As stipulated in the CPS". This means that someone evaluating the practices for SSL certificates would have to consider jointly the CP of SSL certificates and the CPS, while someone evaluating personal certificates for email should consider the CP for S/MIME certificates and the CPS.
I used this in the past while writing some docs for customers... Would this be cross-referencing still acceptable?
Thanks,
Pedro
Kathleen Wilson
Oct 15, 2018, 1:45:25 PM10/15/18
to mozilla-dev-s...@lists.mozilla.org
On 10/15/18 12:48 AM, Pedro Fuentes wrote:
> Hello,
> I've a question closely related to this. I'd appreciate guidance.
>
> I'm refactoring our CP & CPS documents considering that a CA can issue different types of certificates, so there would be multiple CP and one CPS.
>
> My strategy is that if the stipulation is defined in one of the document (CP or CPS), then the other document can refer to the other (CPS or CP).
>
> So, for example, as the CPS will support/implement different CP, for certain aspects (i.e. suspension), I'd like to refer to the CP as source, with the text "As stipulated in the appropriate CP". Like wise, in certain cases the stipulation could be defined in the CPS, so the CP would have the text "As stipulated in the CPS". This means that someone evaluating the practices for SSL certificates would have to consider jointly the CP of SSL certificates and the CPS, while someone evaluating personal certificates for email should consider the CP for S/MIME certificates and the CPS.
>
> I used this in the past while writing some docs for customers... Would this be cross-referencing still acceptable?
>
> Thanks,
> Pedro
Yes, cross-referencing is still acceptable, as long as it is very clear
> Hello,
> I've a question closely related to this. I'd appreciate guidance.
>
> I'm refactoring our CP & CPS documents considering that a CA can issue different types of certificates, so there would be multiple CP and one CPS.
>
> My strategy is that if the stipulation is defined in one of the document (CP or CPS), then the other document can refer to the other (CPS or CP).
>
> So, for example, as the CPS will support/implement different CP, for certain aspects (i.e. suspension), I'd like to refer to the CP as source, with the text "As stipulated in the appropriate CP". Like wise, in certain cases the stipulation could be defined in the CPS, so the CP would have the text "As stipulated in the CPS". This means that someone evaluating the practices for SSL certificates would have to consider jointly the CP of SSL certificates and the CPS, while someone evaluating personal certificates for email should consider the CP for S/MIME certificates and the CPS.
>
> I used this in the past while writing some docs for customers... Would this be cross-referencing still acceptable?
>
> Thanks,
> Pedro
which root certificates each CP and CPS document governs.
Thanks,
Kathleen
Kathleen Wilson
Oct 15, 2018, 2:01:11 PM10/15/18
to mozilla-dev-s...@lists.mozilla.org
I have added the following section to the Required Practices wiki page:
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#BR_Commitment_to_Comply_statement_in_CP.2FCPS
I will continue to appreciate feedback on this update.
Thanks,
Kathleen
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#BR_Commitment_to_Comply_statement_in_CP.2FCPS
I will continue to appreciate feedback on this update.
Thanks,
Kathleen
Jakob Bohm
Oct 15, 2018, 2:22:37 PM10/15/18
to mozilla-dev-s...@lists.mozilla.org
On 15/10/2018 20:01, Kathleen Wilson wrote:
> I have added the following section to the Required Practices wiki page:
>
> https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#BR_Commitment_to_Comply_statement_in_CP.2FCPS
>
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CP.2FCPS_Structured_According_to_RFC_3647
> I have added the following section to the Required Practices wiki page:
>
> https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#BR_Commitment_to_Comply_statement_in_CP.2FCPS
>
links directly to the edited section.
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
Kathleen Wilson
Oct 15, 2018, 2:23:05 PM10/15/18
to mozilla-dev-s...@lists.mozilla.org
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CP.2FCPS_Structured_According_to_RFC_3647
Joanna Fox
Oct 18, 2018, 5:03:49 PM10/18/18
to mozilla-dev-s...@lists.mozilla.org
Is the intent to use No stipulation”, “Not applicable”, or blank interchangeably?
Thank you,
Joanna Fox
Kathleen Wilson
Oct 18, 2018, 6:44:57 PM10/18/18
to mozilla-dev-s...@lists.mozilla.org
On 10/18/18 2:03 PM, Joanna Fox wrote:
>> https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CP.2FCPS_Structured_According_to_RFC_3647
>
> For clarification on this statement, "Any CPS that falls within the scope of Mozilla’s program must not use the words “No stipulation” unless the corresponding section in the CA/Browser Forum Baseline Requirements state “No stipulation”, “Not applicable”, or is blank."
>
> Is the intent to use No stipulation”, “Not applicable”, or blank interchangeably?
No. The intent of that statement was to limit the sections for which the
>> https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CP.2FCPS_Structured_According_to_RFC_3647
>
> For clarification on this statement, "Any CPS that falls within the scope of Mozilla’s program must not use the words “No stipulation” unless the corresponding section in the CA/Browser Forum Baseline Requirements state “No stipulation”, “Not applicable”, or is blank."
>
> Is the intent to use No stipulation”, “Not applicable”, or blank interchangeably?
CA's CP/CPS may use the words "No stipulation".
Do you have a suggestion about how to make this more clear?
Note that just before that sentence is:
"The words "No Stipulation" mean that the particular document imposes no
requirements related to that section."
requirements related to that section."
And the following sentence says:
"The words “Not applicable” are acceptable to indicate that the CA’s
policies forbid the practice that is the title of the section."
To me, those mean very different things.
"The words “Not applicable” are acceptable to indicate that the CA’s
policies forbid the practice that is the title of the section."
We did not define what a blank section means...
I think that a blank section means the same thing as "No stipulation".
Should we require that sections not be left blank?
Thanks,
Kathleen
Matt Palmer
Oct 18, 2018, 7:56:35 PM10/18/18
to dev-secur...@lists.mozilla.org
On Thu, Oct 18, 2018 at 03:44:44PM -0700, Kathleen Wilson via dev-security-policy wrote:
> I think that a blank section means the same thing as "No stipulation".
> Should we require that sections not be left blank?
I think that for the avoidance of any sort of doubt or confusion, it would
> I think that a blank section means the same thing as "No stipulation".
> Should we require that sections not be left blank?
be best to require that sections not be left blank.
- Matt
Jakob Bohm
Oct 18, 2018, 8:47:14 PM10/18/18
to mozilla-dev-s...@lists.mozilla.org
On 15/10/2018 20:01, Kathleen Wilson wrote:
in the BRs are things for which Mozilla would probably want explicit
statements, even though there are no specific BR requirements.
For example:
1.5.1 Organization Administering this document (CP/CPS)
1.5.3 Person Determining CPS suitability for the Policy
1.5.4 CPS Approval procedures
4.3.2 (Mostly relevant to customer relationship)
4.4.1 (Only relevant to customer relationship)
4.4.2 Publication of the certificate by the CA
4.4.3 Notification of certificate issuance by the CA to other entities
(This would cover CT or other mechanisms suitable for CRLset
generation by Mozilla).
4.5.2 Relying party public key and certificate usage
(This would typically cover disclaiming responsibility if users turn
off revocation checking or interpret the certificate as meaning
something other than a proof of identity of the private key holder).
4.6 CERTIFICATE RENEWAL
This has been the subject of many discussions about appropriateness of
CA procedures.
Except:
4.6.4 (Mostly relevant to customer relationship)
4.6.5 (Only relevant to customer relationship)
4.7 CERTIFICATE RE-KEY
This has been the subject of many discussions about appropriateness of
CA procedures.
Except:
4.7.4 (Mostly relevant to customer relationship)
4.7.5 (Only relevant to customer relationship)
4.8 CERTIFICATE MODIFICATION
This has much relevance to situations of later discoveries of
discrepancies of changes in circumstances. It is a recurring theme in
discussions about revoking such certificates.
Except:
4.8.4 (Mostly relevant to customer relationship)
4.8.5 (Only relevant to customer relationship)
4.9.4 Revocation Request Grace Period
4.9.6 Revocation Checking Requirements for Relying Parties
This interacts closely with the features implemented in Mozilla products.
4.9.8 Maximum Latency for CRLs
4.10.3 Optional Features (for certificate status services)
This would for example indicate if the OCSP servers provide ways to
distinguish OCSP status for a real certificate and a fake certificate
with the same serial number. If there are OCSP privacy features etc.
4.11 (Mostly relevant to customer relationship)
4.12 Key escrow and recovery policy and practices
This is the subject of a Mozilla requirement (not to provide such).
Joanna Fox
Oct 19, 2018, 1:39:11 PM10/19/18
to mozilla-dev-s...@lists.mozilla.org
It should be acceptable to leave items blank if they mirror the BR's.
Example: 3.2.4 Non-verified Subscriber Information
Similarly, when the BR's state "No stipulation" and the CP or CPS corresponds to that same section in that same manner with the agreed definition of no requirements for that section.
Example: 4.2.3 Time to Process Certificate Applications
No stipulation.
Thank you, Joanna
Tim Hollebeek
Oct 19, 2018, 8:19:05 PM10/19/18
to Joanna Fox, mozilla-dev-s...@lists.mozilla.org
I think blank sections should be disallowed. The entire purpose of "No stipulation" is to make it clear that the omission of content was intentional.
With regards to some of these sections being useful, I agree that a good CPS contains more than the minimum content required from the BRs. I personally view the use of a "minimal CPS" (lightly modified version of the BRs) by some organizations as a cause for concern. From the discussion at CABF Shanghai, it sounds like many people share my concern.
-Tim
> -----Original Message-----
> From: dev-security-policy <dev-security-...@lists.mozilla.org> On
> Behalf Of Joanna Fox via dev-security-policy
> Sent: Friday, October 19, 2018 1:39 PM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: What does "No Stipulation" mean, and when is it OK to use it in
> CP/CPS?
>
> > > jHbhT4MfRQ=?d=L_e81rE8kYCYgIlLjCzed5rAyhZvhU9-
> WfrdxJja_havwHFfcaC7Z5
> > > faQ8DCy5VncpZl1CphyvBJ8dTo3Ml-RY9dLRX4wfNVPbx50CV7AZO-
> rBXKETGeFpAXd_
> > >
> O0TIYHZceBVPHbT24andbjyZvaQBHcPsoC62d0MAYDjoe9YrPnuAg2i15Z3SCJk
> mVn4u
> > >
> HGorLgZriWMT1D9ae_3pUEAwdLQCdG5DeTh_XQuRfy6nkCNqdu33T21ke5AHr
> kv4ynQk
> > > rYfWuuUGTWbKXPcvTlLrtTXVRAHns1t0OUFp5gA-pXrw_2a-
> YKf2C3IkEFjzQ1KM07-g
> > > 8GY5W2f-
> L8l3AVEwYckAMj7BuG5f3ZntpsITX9xYav31NhE_3hQCFHyuuoC89KtOt1cq
> > > -
> 0hOXZSjQMhd9U8HPl2InCYHhLLGeW2jqa_qXR5wk2SwKC9ecK3MSN7EWKQ7Z
> FNQGGj8
> > >
> 9SqBMmPojMgjHEhA%3D%3D&u=https%3A%2F%2Fwiki.mozilla.org%2FCA%2
> FRequi
> > >
> red_or_Recommended_Practices%23BR_Commitment_to_Comply_statement
> _in_
> https://clicktime.symantec.com/a/1/qg1xJznChxmyUV0biuQ9q261sKYl0pswb3
> 9
> > gsDU-SoA=?d=L_e81rE8kYCYgIlLjCzed5rAyhZvhU9-
> WfrdxJja_havwHFfcaC7Z5faQ8
> > DCy5VncpZl1CphyvBJ8dTo3Ml-RY9dLRX4wfNVPbx50CV7AZO-
> rBXKETGeFpAXd_O0TIYH
> >
> ZceBVPHbT24andbjyZvaQBHcPsoC62d0MAYDjoe9YrPnuAg2i15Z3SCJkmVn4uH
> GorLgZr
> >
> iWMT1D9ae_3pUEAwdLQCdG5DeTh_XQuRfy6nkCNqdu33T21ke5AHrkv4ynQkr
> YfWuuUGTW
> > bKXPcvTlLrtTXVRAHns1t0OUFp5gA-pXrw_2a-YKf2C3IkEFjzQ1KM07-
> g8GY5W2f-L8l3
> > AVEwYckAMj7BuG5f3ZntpsITX9xYav31NhE_3hQCFHyuuoC89KtOt1cq-
> 0hOXZSjQMhd9U
> >
> 8HPl2InCYHhLLGeW2jqa_qXR5wk2SwKC9ecK3MSN7EWKQ7ZFNQGGj89SqBM
> mPojMgjHEhA
> > %3D%3D&u=https%3A%2F%2Fwww.wisemo.com
> XY03vc6hnnA=?d=L_e81rE8kYCYgIlLjCzed5rAyhZvhU9-
> WfrdxJja_havwHFfcaC7Z5faQ8DCy5VncpZl1CphyvBJ8dTo3Ml-
> RY9dLRX4wfNVPbx50CV7AZO-
> rBXKETGeFpAXd_O0TIYHZceBVPHbT24andbjyZvaQBHcPsoC62d0MAYDjoe9YrP
> nuAg2i15Z3SCJkmVn4uHGorLgZriWMT1D9ae_3pUEAwdLQCdG5DeTh_XQuRfy
> 6nkCNqdu33T21ke5AHrkv4ynQkrYfWuuUGTWbKXPcvTlLrtTXVRAHns1t0OUFp5
> gA-pXrw_2a-YKf2C3IkEFjzQ1KM07-g8GY5W2f-
> L8l3AVEwYckAMj7BuG5f3ZntpsITX9xYav31NhE_3hQCFHyuuoC89KtOt1cq-
> 0hOXZSjQMhd9U8HPl2InCYHhLLGeW2jqa_qXR5wk2SwKC9ecK3MSN7EWKQ7Z
> FNQGGj89SqBMmPojMgjHEhA%3D%3D&u=https%3A%2F%2Flists.mozilla.org
> %2Flistinfo%2Fdev-security-policy
With regards to some of these sections being useful, I agree that a good CPS contains more than the minimum content required from the BRs. I personally view the use of a "minimal CPS" (lightly modified version of the BRs) by some organizations as a cause for concern. From the discussion at CABF Shanghai, it sounds like many people share my concern.
-Tim
> -----Original Message-----
> From: dev-security-policy <dev-security-...@lists.mozilla.org> On
> Behalf Of Joanna Fox via dev-security-policy
> Sent: Friday, October 19, 2018 1:39 PM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: What does "No Stipulation" mean, and when is it OK to use it in
> CP/CPS?
>
> On Thursday, October 18, 2018 at 5:47:14 PM UTC-7, Jakob Bohm wrote:
> > On 15/10/2018 20:01, Kathleen Wilson wrote:
> > > I have added the following section to the Required Practices wiki page:
> > >
> > >
> https://clicktime.symantec.com/a/1/7p3XgkAIErb9F2a7I0h79owDFBAc5ICeK
> > > I have added the following section to the Required Practices wiki page:
> > >
> > >
> > > jHbhT4MfRQ=?d=L_e81rE8kYCYgIlLjCzed5rAyhZvhU9-
> WfrdxJja_havwHFfcaC7Z5
> > > faQ8DCy5VncpZl1CphyvBJ8dTo3Ml-RY9dLRX4wfNVPbx50CV7AZO-
> rBXKETGeFpAXd_
> > >
> O0TIYHZceBVPHbT24andbjyZvaQBHcPsoC62d0MAYDjoe9YrPnuAg2i15Z3SCJk
> mVn4u
> > >
> HGorLgZriWMT1D9ae_3pUEAwdLQCdG5DeTh_XQuRfy6nkCNqdu33T21ke5AHr
> kv4ynQk
> > > rYfWuuUGTWbKXPcvTlLrtTXVRAHns1t0OUFp5gA-pXrw_2a-
> YKf2C3IkEFjzQ1KM07-g
> > > 8GY5W2f-
> L8l3AVEwYckAMj7BuG5f3ZntpsITX9xYav31NhE_3hQCFHyuuoC89KtOt1cq
> > > -
> 0hOXZSjQMhd9U8HPl2InCYHhLLGeW2jqa_qXR5wk2SwKC9ecK3MSN7EWKQ7Z
> FNQGGj8
> > >
> 9SqBMmPojMgjHEhA%3D%3D&u=https%3A%2F%2Fwiki.mozilla.org%2FCA%2
> FRequi
> > >
> red_or_Recommended_Practices%23BR_Commitment_to_Comply_statement
> _in_
> 9
> > gsDU-SoA=?d=L_e81rE8kYCYgIlLjCzed5rAyhZvhU9-
> WfrdxJja_havwHFfcaC7Z5faQ8
> > DCy5VncpZl1CphyvBJ8dTo3Ml-RY9dLRX4wfNVPbx50CV7AZO-
> rBXKETGeFpAXd_O0TIYH
> >
> ZceBVPHbT24andbjyZvaQBHcPsoC62d0MAYDjoe9YrPnuAg2i15Z3SCJkmVn4uH
> GorLgZr
> >
> iWMT1D9ae_3pUEAwdLQCdG5DeTh_XQuRfy6nkCNqdu33T21ke5AHrkv4ynQkr
> YfWuuUGTW
> > bKXPcvTlLrtTXVRAHns1t0OUFp5gA-pXrw_2a-YKf2C3IkEFjzQ1KM07-
> g8GY5W2f-L8l3
> > AVEwYckAMj7BuG5f3ZntpsITX9xYav31NhE_3hQCFHyuuoC89KtOt1cq-
> 0hOXZSjQMhd9U
> >
> 8HPl2InCYHhLLGeW2jqa_qXR5wk2SwKC9ecK3MSN7EWKQ7ZFNQGGj89SqBM
> mPojMgjHEhA
> > %3D%3D&u=https%3A%2F%2Fwww.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
>
> The definition of blank could be integrated into the statement "The words "No
> > public discussion message is non-binding and may contain errors.
> > WiseMo - Remote Service Management for PCs, Phones and Embedded
>
> Stipulation" mean that the particular document imposes no requirements
> related to that section."
>
> related to that section."
>
> It should be acceptable to leave items blank if they mirror the BR's.
> Example: 3.2.4 Non-verified Subscriber Information
>
> Similarly, when the BR's state "No stipulation" and the CP or CPS corresponds
> to that same section in that same manner with the agreed definition of no
> requirements for that section.
> Example: 4.2.3 Time to Process Certificate Applications
> No stipulation.
>
> Thank you, Joanna
> Example: 3.2.4 Non-verified Subscriber Information
>
> Similarly, when the BR's state "No stipulation" and the CP or CPS corresponds
> to that same section in that same manner with the agreed definition of no
> requirements for that section.
> Example: 4.2.3 Time to Process Certificate Applications
> No stipulation.
>
> Thank you, Joanna
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://clicktime.symantec.com/a/1/u49v5OVN_9xGhZ5hvzqQF62t7Nd_Oup7
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> XY03vc6hnnA=?d=L_e81rE8kYCYgIlLjCzed5rAyhZvhU9-
> WfrdxJja_havwHFfcaC7Z5faQ8DCy5VncpZl1CphyvBJ8dTo3Ml-
> RY9dLRX4wfNVPbx50CV7AZO-
> rBXKETGeFpAXd_O0TIYHZceBVPHbT24andbjyZvaQBHcPsoC62d0MAYDjoe9YrP
> nuAg2i15Z3SCJkmVn4uHGorLgZriWMT1D9ae_3pUEAwdLQCdG5DeTh_XQuRfy
> 6nkCNqdu33T21ke5AHrkv4ynQkrYfWuuUGTWbKXPcvTlLrtTXVRAHns1t0OUFp5
> gA-pXrw_2a-YKf2C3IkEFjzQ1KM07-g8GY5W2f-
> L8l3AVEwYckAMj7BuG5f3ZntpsITX9xYav31NhE_3hQCFHyuuoC89KtOt1cq-
> 0hOXZSjQMhd9U8HPl2InCYHhLLGeW2jqa_qXR5wk2SwKC9ecK3MSN7EWKQ7Z
> FNQGGj89SqBMmPojMgjHEhA%3D%3D&u=https%3A%2F%2Flists.mozilla.org
> %2Flistinfo%2Fdev-security-policy
Ryan Sleevi
Oct 20, 2018, 10:46:44 PM10/20/18
to Tim Hollebeek, Joanna Fox, mozilla-dev-s...@lists.mozilla.org
I’m not sure that is at all an accurate representation - of the discussions
or of the practiced use of “no stipulation.”
The use of “minimal CPS” is highly desirable from an audit and
documentation practice. The concerns raised during such discussions are the
concerns captured here originally - CAs documenting what “could” be
possible (up to anything they want, at a no stipulation level) rather than
documenting what they actually practice.
However, that discussion is not to be confused with “copy/paste CPS”. At
best, you could say that “some” (i.e. two people beyond yourself) shared
that view initially, and the subsequent discussion and clarification on
those concerns led to a different result than what you’re saying here. This
discussion is far more productive, with the goal of making explicit that
something is NOT practiced or implemented, rather than no restrictions made
(no stipulation) or no documentation provided (blank).
On Sat, Oct 20, 2018 at 8:19 AM Tim Hollebeek via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
> I think blank sections should be disallowed. The entire purpose of "No
> stipulation" is to make it clear that the omission of content was
> intentional.
>
> With regards to some of these sections being useful, I agree that a good
> CPS contains more than the minimum content required from the BRs. I
> personally view the use of a "minimal CPS" (lightly modified version of the
> BRs) by some organizations as a cause for concern. From the discussion at
> CABF Shanghai, it sounds like many people share my concern.
>
> -Tim
>
> > -----Original Message-----
> > From: dev-security-policy <dev-security-...@lists.mozilla.org>
> On
> > Behalf Of Joanna Fox via dev-security-policy
> > Sent: Friday, October 19, 2018 1:39 PM
> > To: mozilla-dev-s...@lists.mozilla.org
> > Subject: Re: What does "No Stipulation" mean, and when is it OK to use
> it in
> > CP/CPS?
> >
> > On Thursday, October 18, 2018 at 5:47:14 PM UTC-7, Jakob Bohm wrote:
> https://lists.mozilla.org/listinfo/dev-security-policy
>
or of the practiced use of “no stipulation.”
The use of “minimal CPS” is highly desirable from an audit and
documentation practice. The concerns raised during such discussions are the
concerns captured here originally - CAs documenting what “could” be
possible (up to anything they want, at a no stipulation level) rather than
documenting what they actually practice.
However, that discussion is not to be confused with “copy/paste CPS”. At
best, you could say that “some” (i.e. two people beyond yourself) shared
that view initially, and the subsequent discussion and clarification on
those concerns led to a different result than what you’re saying here. This
discussion is far more productive, with the goal of making explicit that
something is NOT practiced or implemented, rather than no restrictions made
(no stipulation) or no documentation provided (blank).
On Sat, Oct 20, 2018 at 8:19 AM Tim Hollebeek via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
> I think blank sections should be disallowed. The entire purpose of "No
> stipulation" is to make it clear that the omission of content was
> intentional.
>
> With regards to some of these sections being useful, I agree that a good
> CPS contains more than the minimum content required from the BRs. I
> personally view the use of a "minimal CPS" (lightly modified version of the
> BRs) by some organizations as a cause for concern. From the discussion at
> CABF Shanghai, it sounds like many people share my concern.
>
> -Tim
>
> > -----Original Message-----
> > From: dev-security-policy <dev-security-...@lists.mozilla.org>
> On
> > Behalf Of Joanna Fox via dev-security-policy
> > Sent: Friday, October 19, 2018 1:39 PM
> > To: mozilla-dev-s...@lists.mozilla.org
> > Subject: Re: What does "No Stipulation" mean, and when is it OK to use
> it in
> > CP/CPS?
> >
> > On Thursday, October 18, 2018 at 5:47:14 PM UTC-7, Jakob Bohm wrote:
> > > On 15/10/2018 20:01, Kathleen Wilson wrote:
> > > > I have added the following section to the Required Practices wiki
> page:
> > > >
> > > >
> > > > I have added the following section to the Required Practices wiki
> page:
> > > >
> > > >
> > https://clicktime.symantec.com/a/1/7p3XgkAIErb9F2a7I0h79owDFBAc5ICeK
> > > > jHbhT4MfRQ=?d=L_e81rE8kYCYgIlLjCzed5rAyhZvhU9-
> > WfrdxJja_havwHFfcaC7Z5
> > > > faQ8DCy5VncpZl1CphyvBJ8dTo3Ml-RY9dLRX4wfNVPbx50CV7AZO-
> > rBXKETGeFpAXd_
> > > >
> > O0TIYHZceBVPHbT24andbjyZvaQBHcPsoC62d0MAYDjoe9YrPnuAg2i15Z3SCJk
> > mVn4u
> > > >
> > HGorLgZriWMT1D9ae_3pUEAwdLQCdG5DeTh_XQuRfy6nkCNqdu33T21ke5AHr
> > kv4ynQk
> > > > rYfWuuUGTWbKXPcvTlLrtTXVRAHns1t0OUFp5gA-pXrw_2a-
> > YKf2C3IkEFjzQ1KM07-g
> > > > 8GY5W2f-
> > L8l3AVEwYckAMj7BuG5f3ZntpsITX9xYav31NhE_3hQCFHyuuoC89KtOt1cq
> > > > -
> > 0hOXZSjQMhd9U8HPl2InCYHhLLGeW2jqa_qXR5wk2SwKC9ecK3MSN7EWKQ7Z
> > FNQGGj8
> > > >
> > 9SqBMmPojMgjHEhA%3D%3D&u=https%3A%2F%2Fwiki.mozilla.org%2FCA%2
> > FRequi
> > > >
> > red_or_Recommended_Practices%23BR_Commitment_to_Comply_statement
> > _in_
> > > > CP.2FCPS
> > > >
> > > > jHbhT4MfRQ=?d=L_e81rE8kYCYgIlLjCzed5rAyhZvhU9-
> > WfrdxJja_havwHFfcaC7Z5
> > > > faQ8DCy5VncpZl1CphyvBJ8dTo3Ml-RY9dLRX4wfNVPbx50CV7AZO-
> > rBXKETGeFpAXd_
> > > >
> > O0TIYHZceBVPHbT24andbjyZvaQBHcPsoC62d0MAYDjoe9YrPnuAg2i15Z3SCJk
> > mVn4u
> > > >
> > HGorLgZriWMT1D9ae_3pUEAwdLQCdG5DeTh_XQuRfy6nkCNqdu33T21ke5AHr
> > kv4ynQk
> > > > rYfWuuUGTWbKXPcvTlLrtTXVRAHns1t0OUFp5gA-pXrw_2a-
> > YKf2C3IkEFjzQ1KM07-g
> > > > 8GY5W2f-
> > L8l3AVEwYckAMj7BuG5f3ZntpsITX9xYav31NhE_3hQCFHyuuoC89KtOt1cq
> > > > -
> > 0hOXZSjQMhd9U8HPl2InCYHhLLGeW2jqa_qXR5wk2SwKC9ecK3MSN7EWKQ7Z
> > FNQGGj8
> > > >
> > 9SqBMmPojMgjHEhA%3D%3D&u=https%3A%2F%2Fwiki.mozilla.org%2FCA%2
> > FRequi
> > > >
> > red_or_Recommended_Practices%23BR_Commitment_to_Comply_statement
> > _in_
> > > > CP.2FCPS
> > > >
> > https://clicktime.symantec.com/a/1/qg1xJznChxmyUV0biuQ9q261sKYl0pswb3
> > 9
> > > gsDU-SoA=?d=L_e81rE8kYCYgIlLjCzed5rAyhZvhU9-
> > WfrdxJja_havwHFfcaC7Z5faQ8
> > > DCy5VncpZl1CphyvBJ8dTo3Ml-RY9dLRX4wfNVPbx50CV7AZO-
> > rBXKETGeFpAXd_O0TIYH
> > >
> > ZceBVPHbT24andbjyZvaQBHcPsoC62d0MAYDjoe9YrPnuAg2i15Z3SCJkmVn4uH
> > GorLgZr
> > >
> > iWMT1D9ae_3pUEAwdLQCdG5DeTh_XQuRfy6nkCNqdu33T21ke5AHrkv4ynQkr
> > YfWuuUGTW
> > > bKXPcvTlLrtTXVRAHns1t0OUFp5gA-pXrw_2a-YKf2C3IkEFjzQ1KM07-
> > g8GY5W2f-L8l3
> > > AVEwYckAMj7BuG5f3ZntpsITX9xYav31NhE_3hQCFHyuuoC89KtOt1cq-
> > 0hOXZSjQMhd9U
> > >
> > 8HPl2InCYHhLLGeW2jqa_qXR5wk2SwKC9ecK3MSN7EWKQ7ZFNQGGj89SqBM
> > mPojMgjHEhA
> > > %3D%3D&u=https%3A%2F%2Fwww.wisemo.com
> > 9
> > > gsDU-SoA=?d=L_e81rE8kYCYgIlLjCzed5rAyhZvhU9-
> > WfrdxJja_havwHFfcaC7Z5faQ8
> > > DCy5VncpZl1CphyvBJ8dTo3Ml-RY9dLRX4wfNVPbx50CV7AZO-
> > rBXKETGeFpAXd_O0TIYH
> > >
> > ZceBVPHbT24andbjyZvaQBHcPsoC62d0MAYDjoe9YrPnuAg2i15Z3SCJkmVn4uH
> > GorLgZr
> > >
> > iWMT1D9ae_3pUEAwdLQCdG5DeTh_XQuRfy6nkCNqdu33T21ke5AHrkv4ynQkr
> > YfWuuUGTW
> > > bKXPcvTlLrtTXVRAHns1t0OUFp5gA-pXrw_2a-YKf2C3IkEFjzQ1KM07-
> > g8GY5W2f-L8l3
> > > AVEwYckAMj7BuG5f3ZntpsITX9xYav31NhE_3hQCFHyuuoC89KtOt1cq-
> > 0hOXZSjQMhd9U
> > >
> > 8HPl2InCYHhLLGeW2jqa_qXR5wk2SwKC9ecK3MSN7EWKQ7ZFNQGGj89SqBM
> > mPojMgjHEhA
> > > %3D%3D&u=https%3A%2F%2Fwww.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
> >
> > The definition of blank could be integrated into the statement "The
> > > public discussion message is non-binding and may contain errors.
> > > WiseMo - Remote Service Management for PCs, Phones and Embedded
> >
> words "No
> > Stipulation" mean that the particular document imposes no requirements
> > related to that section."
> >
> > Stipulation" mean that the particular document imposes no requirements
> > related to that section."
> >
>
Kathleen Wilson
Oct 22, 2018, 2:25:07 PM10/22/18
to mozilla-dev-s...@lists.mozilla.org
I have updated the section as follows:
- Removed the sentence that was trying to limit the use of "No
Stipulation". Hopefully the clarification about what these words mean is
sufficient.
- Added bullet points
- Added "Sections MUST not be left blank. ..."
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CP.2FCPS_Structured_According_to_RFC_3647
I continue to appreciate your feedback on this new section.
Thanks,
Kathleen
- Removed the sentence that was trying to limit the use of "No
Stipulation". Hopefully the clarification about what these words mean is
sufficient.
- Added bullet points
- Added "Sections MUST not be left blank. ..."
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CP.2FCPS_Structured_According_to_RFC_3647
I continue to appreciate your feedback on this new section.
Thanks,
Kathleen
Wayne Thayer
Oct 22, 2018, 6:00:35 PM10/22/18
to Kathleen Wilson, mozilla-dev-security-policy
Having given this some more thought, I suggest the following changes:
* Forbid "no stipulation" altogether. While there are a few sections where
it would be convenient to use "No stipulation" (e.g. 4.2.3 Time to Process
Certificate Applications), I don't see a requirement for more descriptive
language to be much of a burden (e.g. 4.2.3 could simply state: "we process
applications in a commercially reasonable time but do not publish specific
SLAs"). In the case of a CP that delegates requirements to one or more
CPSs, it is also more informative to state "Refer to CPS section" than to
use "No stipulation". Finally, if we continue to allow "No stipulation", we
really won't know if a CA is aware of this discussion and is using the term
properly.
* Section 1.1 of the BRs describes the reason that some sections are left
blank:
In accordance with RFC 3647 and to facilitate a comparison of other
certificate policies and CPSs (e.g. for policy mapping), this document
includes all sections of the RFC 3647 framework. However, rather than
beginning with a “no stipulation” comment in all empty sections, the
CA/Browser Forum is leaving such sections initially blank until a decision
of “no stipulation” is made.
Some of the blank sections also cover important information (e.g. 3.3.1
Identification and Authentication for Routine Re-key). We shouldn't allow
"No stipulation" for these either.
* Add a requirement that language that only applies to certificates that
are out-of-scope for Mozilla policy must be clearly marked as such. Many
CP/CPSs cover document signing and other certificate usages, but they often
aren't explicit about policies that aren't permitted for TLS and/or email
certificates. For example, it's permissible for a CP/CPS to describe
procedures for certificate suspension in 4.9.15, but it should clearly
state that suspension will not be used with TLS certificates.
* Finally, I think we need some effective date for these as required
practices. One approach would be to require compliance for any CP/CPS dated
after Dec 31, 2018.
- Wayne
* Forbid "no stipulation" altogether. While there are a few sections where
it would be convenient to use "No stipulation" (e.g. 4.2.3 Time to Process
Certificate Applications), I don't see a requirement for more descriptive
language to be much of a burden (e.g. 4.2.3 could simply state: "we process
applications in a commercially reasonable time but do not publish specific
SLAs"). In the case of a CP that delegates requirements to one or more
CPSs, it is also more informative to state "Refer to CPS section" than to
use "No stipulation". Finally, if we continue to allow "No stipulation", we
really won't know if a CA is aware of this discussion and is using the term
properly.
* Section 1.1 of the BRs describes the reason that some sections are left
blank:
In accordance with RFC 3647 and to facilitate a comparison of other
certificate policies and CPSs (e.g. for policy mapping), this document
includes all sections of the RFC 3647 framework. However, rather than
beginning with a “no stipulation” comment in all empty sections, the
CA/Browser Forum is leaving such sections initially blank until a decision
of “no stipulation” is made.
Some of the blank sections also cover important information (e.g. 3.3.1
Identification and Authentication for Routine Re-key). We shouldn't allow
"No stipulation" for these either.
* Add a requirement that language that only applies to certificates that
are out-of-scope for Mozilla policy must be clearly marked as such. Many
CP/CPSs cover document signing and other certificate usages, but they often
aren't explicit about policies that aren't permitted for TLS and/or email
certificates. For example, it's permissible for a CP/CPS to describe
procedures for certificate suspension in 4.9.15, but it should clearly
state that suspension will not be used with TLS certificates.
* Finally, I think we need some effective date for these as required
practices. One approach would be to require compliance for any CP/CPS dated
after Dec 31, 2018.
- Wayne
Kathleen Wilson
Oct 23, 2018, 2:56:33 PM10/23/18
to mozilla-dev-s...@lists.mozilla.org
I have updated this section in the wiki page again as follows:
- Changed the word 'must' to 'should' for items that are not currently
in Mozilla's Root Store Policy or the BRs. We plan to change these back
to 'must' after Wayne updates Mozilla's Root Store Policy regarding this
topic.
- Added notes/warnings that Mozilla's root store policy may be updated
soon to forbid use of blank sections and "No Stipulation".
- Added bullet point about clarifying in the CP/CPS when certain
sections (like private key generation and escrow) only apply to certain
types of certificates.
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CP.2FCPS_Structured_According_to_RFC_3647
Thanks,
Kathleen
- Changed the word 'must' to 'should' for items that are not currently
in Mozilla's Root Store Policy or the BRs. We plan to change these back
to 'must' after Wayne updates Mozilla's Root Store Policy regarding this
topic.
- Added notes/warnings that Mozilla's root store policy may be updated
soon to forbid use of blank sections and "No Stipulation".
- Added bullet point about clarifying in the CP/CPS when certain
sections (like private key generation and escrow) only apply to certain
types of certificates.
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CP.2FCPS_Structured_According_to_RFC_3647
Thanks,
Kathleen
Tim Hollebeek
Oct 23, 2018, 6:08:20 PM10/23/18
to Wayne Thayer, Kathleen Wilson, mozilla-dev-security-policy
I agree with you, but December 31 is a particularly horrible compliance deadline. Perhaps January 31?
-Tim
> -----Original Message-----
> From: dev-security-policy <dev-security-...@lists.mozilla.org> On
> Behalf Of Wayne Thayer via dev-security-policy
> Sent: Monday, October 22, 2018 6:00 PM
> To: Kathleen Wilson <kwi...@mozilla.com>
> Cc: mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org>
> Subject: Re: What does "No Stipulation" mean, and when is it OK to use it in
> CP/CPS?
>
-Tim
> -----Original Message-----
> From: dev-security-policy <dev-security-...@lists.mozilla.org> On
> Behalf Of Wayne Thayer via dev-security-policy
> Sent: Monday, October 22, 2018 6:00 PM
> To: Kathleen Wilson <kwi...@mozilla.com>
> Cc: mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org>
> Subject: Re: What does "No Stipulation" mean, and when is it OK to use it in
> CP/CPS?
>
> On Tue, Oct 23, 2018 at 2:25 AM Kathleen Wilson via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
> > I have updated the section as follows:
> > - Removed the sentence that was trying to limit the use of "No
> > Stipulation". Hopefully the clarification about what these words mean
> > is sufficient.
> > - Added bullet points
> > - Added "Sections MUST not be left blank. ..."
> >
> >
> >
> https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CP.2FCPS
> > _Structured_According_to_RFC_3647
> >
> >
> > I continue to appreciate your feedback on this new section.
> >
> > Thanks,
> > Kathleen
> >
> >
> dev-secur...@lists.mozilla.org> wrote:
>
> > I have updated the section as follows:
> > - Removed the sentence that was trying to limit the use of "No
> > Stipulation". Hopefully the clarification about what these words mean
> > is sufficient.
> > - Added bullet points
> > - Added "Sections MUST not be left blank. ..."
> >
> >
> >
> https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CP.2FCPS
> > _Structured_According_to_RFC_3647
> >
> >
> > I continue to appreciate your feedback on this new section.
> >
> > Thanks,
> > Kathleen
> >
> >
Jakob Bohm
Oct 24, 2018, 9:43:42 AM10/24/18
to mozilla-dev-s...@lists.mozilla.org
On 24/10/2018 00:08, Tim Hollebeek wrote:
> I agree with you, but December 31 is a particularly horrible compliance deadline. Perhaps January 31?
>
Note that the requirement applies only to CP/CPS dated after that date.
> I agree with you, but December 31 is a particularly horrible compliance deadline. Perhaps January 31?
>
So it is really Dec 31 + the time until the CP/CPS is updated for some
other reason. This is different than many other policy requirements,
and a welcome reduction in administrative overhead for all concerned
(including root programs and relying parties).
For example, it a CA updated their CP/CPS in August 2018 to comply with
new BRs, and again in May 2019 due to annual review, they need not
comply until May 2019.
>
>> -----Original Message-----
>> From: dev-security-policy <dev-security-...@lists.mozilla.org> On
>> Behalf Of Wayne Thayer via dev-security-policy
>> Sent: Monday, October 22, 2018 6:00 PM
>> To: Kathleen Wilson <kwi...@mozilla.com>
>> Cc: mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org>
>> Subject: Re: What does "No Stipulation" mean, and when is it OK to use it in
>> CP/CPS?
>>
>> Having given this some more thought, I suggest the following changes:
>>
>>
>> * Finally, I think we need some effective date for these as required practices.
>> One approach would be to require compliance for any CP/CPS dated after Dec
>> 31, 2018.
>>
>> - Wayne
>>
>> On Tue, Oct 23, 2018 at 2:25 AM Kathleen Wilson via dev-security-policy <
>> dev-secur...@lists.mozilla.org> wrote:
>>
>>> I have updated the section as follows:
>>> - Removed the sentence that was trying to limit the use of "No
>>> Stipulation". Hopefully the clarification about what these words mean
>>> is sufficient.
>>> - Added bullet points
>>> - Added "Sections MUST not be left blank. ..."
>>>
>>>
>>>
>> https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CP.2FCPS
>>> _Structured_According_to_RFC_3647
>>>
>>>
>>> I continue to appreciate your feedback on this new section.
>>>
Enjoy
>> * Finally, I think we need some effective date for these as required practices.
>> One approach would be to require compliance for any CP/CPS dated after Dec
>> 31, 2018.
>>
>> - Wayne
>>
>> On Tue, Oct 23, 2018 at 2:25 AM Kathleen Wilson via dev-security-policy <
>> dev-secur...@lists.mozilla.org> wrote:
>>
>>> I have updated the section as follows:
>>> - Removed the sentence that was trying to limit the use of "No
>>> Stipulation". Hopefully the clarification about what these words mean
>>> is sufficient.
>>> - Added bullet points
>>> - Added "Sections MUST not be left blank. ..."
>>>
>>>
>>>
>> https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CP.2FCPS
>>> _Structured_According_to_RFC_3647
>>>
>>>
>>> I continue to appreciate your feedback on this new section.
>>>
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Tim Hollebeek
Oct 24, 2018, 10:25:26 AM10/24/18
to mozilla-dev-security-policy, Jakob Bohm
That may be true, but I don't see any upside for using that date. If you need
to make a minor CPS update in early January for any reason, you now have
additional work.
I think late December policy changes should be avoided as a general rule.
-Tim
> -----Original Message-----
> From: dev-security-policy <dev-security-...@lists.mozilla.org>
> On Behalf Of Jakob Bohm via dev-security-policy
> Sent: Wednesday, October 24, 2018 9:44 AM
> To: mozilla-dev-s...@lists.mozilla.org
> Cc: Jakob Bohm <jb-mo...@wisemo.com>
> Subject: Re: What does "No Stipulation" mean, and when is it OK to use it in
> CP/CPS?
>
> rJgK1XipLGMs1U1jQtvScEL4FB3RgBJ
> >> dwBJwZeYE=?d=vW4rM0CTwt8BO-
> WkB0mRKJ4JerYClzYhMZEWRTwXeQpnsTE59W7amFJ7
> >> UBJ2Lqfz4GYYK9b1-
> 861DyJ4DaHeghkm5uPyaLz88lMhRqvIqIqTZA_cIJj019oR2rEK9
> >> bhkXphYgKSUVtoR8Jv4c4ZyzmC1PwABos85PgNWZUQJmHU-
> PUFpXdUPJHpMF3mizDn82r
> >>
> k0Y2RsTkEa8rivnT6E8_XY2ct_Qb2EyuqdHD5BaiPxVGtBuabizQhhSJTxJOnwKO
> WaoM-
> >> G1uz_LEZUDTl53vgLqwOnLWYb8q3kLP7q7clVFhkAPULAOQGVhob01XI-
> oCmWpmJtDsMG
> >>
> HVzmozw0E1T4208EZyfyv2L2nQKYOsdTwEScupt4ut18MDXpcevjD2CbeA2U9
> QfVhB_kA
> >> _fCU3vcSLkeOXiJOLq-
> YfSsXuiLvEqqmw4GLGR758pQeOj_rVwNE30jDvfqbbmg&u=htt
> >>
> ps%3A%2F%2Fwiki.mozilla.org%2FCA%2FRequired_or_Recommended_Pract
> ices%
> >> 23CP.2FCPS
> XBO8_i0rw=?d=vW4rM0CTwt8BO-
> WkB0mRKJ4JerYClzYhMZEWRTwXeQpnsTE59W7amFJ7UBJ2Lqfz4GYYK9b1-
> 861DyJ4DaHeghkm5uPyaLz88lMhRqvIqIqTZA_cIJj019oR2rEK9bhkXphYgKSUV
> toR8Jv4c4ZyzmC1PwABos85PgNWZUQJmHU-
> PUFpXdUPJHpMF3mizDn82rk0Y2RsTkEa8rivnT6E8_XY2ct_Qb2EyuqdHD5BaiP
> xVGtBuabizQhhSJTxJOnwKOWaoM-
> G1uz_LEZUDTl53vgLqwOnLWYb8q3kLP7q7clVFhkAPULAOQGVhob01XI-
> oCmWpmJtDsMGHVzmozw0E1T4208EZyfyv2L2nQKYOsdTwEScupt4ut18MDX
> pcevjD2CbeA2U9QfVhB_kA_fCU3vcSLkeOXiJOLq-
> YfSsXuiLvEqqmw4GLGR758pQeOj_rVwNE30jDvfqbbmg&u=https%3A%2F%2F
> irUZprQKCSffpbwg_M87H8=?d=vW4rM0CTwt8BO-
> WkB0mRKJ4JerYClzYhMZEWRTwXeQpnsTE59W7amFJ7UBJ2Lqfz4GYYK9b1-
> 861DyJ4DaHeghkm5uPyaLz88lMhRqvIqIqTZA_cIJj019oR2rEK9bhkXphYgKSUV
> toR8Jv4c4ZyzmC1PwABos85PgNWZUQJmHU-
> PUFpXdUPJHpMF3mizDn82rk0Y2RsTkEa8rivnT6E8_XY2ct_Qb2EyuqdHD5BaiP
> xVGtBuabizQhhSJTxJOnwKOWaoM-
> G1uz_LEZUDTl53vgLqwOnLWYb8q3kLP7q7clVFhkAPULAOQGVhob01XI-
> oCmWpmJtDsMGHVzmozw0E1T4208EZyfyv2L2nQKYOsdTwEScupt4ut18MDX
> pcevjD2CbeA2U9QfVhB_kA_fCU3vcSLkeOXiJOLq-
> YfSsXuiLvEqqmw4GLGR758pQeOj_rVwNE30jDvfqbbmg&u=https%3A%2F%2Fl
> ists.mozilla.org%2Flistinfo%2Fdev-security-policy
to make a minor CPS update in early January for any reason, you now have
additional work.
I think late December policy changes should be avoided as a general rule.
-Tim
> -----Original Message-----
> From: dev-security-policy <dev-security-...@lists.mozilla.org>
> On Behalf Of Jakob Bohm via dev-security-policy
> Sent: Wednesday, October 24, 2018 9:44 AM
> To: mozilla-dev-s...@lists.mozilla.org
> Cc: Jakob Bohm <jb-mo...@wisemo.com>
> Subject: Re: What does "No Stipulation" mean, and when is it OK to use it in
> CP/CPS?
>
> On 24/10/2018 00:08, Tim Hollebeek wrote:
> > I agree with you, but December 31 is a particularly horrible compliance
> deadline. Perhaps January 31?
> >
>
> deadline. Perhaps January 31?
> >
>
> Note that the requirement applies only to CP/CPS dated after that date.
> So it is really Dec 31 + the time until the CP/CPS is updated for some other
> reason. This is different than many other policy requirements, and a
> welcome reduction in administrative overhead for all concerned (including
> root programs and relying parties).
>
> For example, it a CA updated their CP/CPS in August 2018 to comply with
> new BRs, and again in May 2019 due to annual review, they need not comply
> until May 2019.
>
> >
> So it is really Dec 31 + the time until the CP/CPS is updated for some other
> reason. This is different than many other policy requirements, and a
> welcome reduction in administrative overhead for all concerned (including
> root programs and relying parties).
>
> For example, it a CA updated their CP/CPS in August 2018 to comply with
> new BRs, and again in May 2019 due to annual review, they need not comply
> until May 2019.
>
> >
> >> -----Original Message-----
> >> From: dev-security-policy
> >> <dev-security-...@lists.mozilla.org> On Behalf Of Wayne
> >> Thayer via dev-security-policy
> >> Sent: Monday, October 22, 2018 6:00 PM
> >> To: Kathleen Wilson <kwi...@mozilla.com>
> >> Cc: mozilla-dev-security-policy
> >> <mozilla-dev-s...@lists.mozilla.org>
> >> Subject: Re: What does "No Stipulation" mean, and when is it OK to
> >> use it in CP/CPS?
> >>
> >> Having given this some more thought, I suggest the following changes:
> >>
> >> ...
> >> From: dev-security-policy
> >> <dev-security-...@lists.mozilla.org> On Behalf Of Wayne
> >> Thayer via dev-security-policy
> >> Sent: Monday, October 22, 2018 6:00 PM
> >> To: Kathleen Wilson <kwi...@mozilla.com>
> >> Cc: mozilla-dev-security-policy
> >> <mozilla-dev-s...@lists.mozilla.org>
> >> Subject: Re: What does "No Stipulation" mean, and when is it OK to
> >> use it in CP/CPS?
> >>
> >> Having given this some more thought, I suggest the following changes:
> >>
> >>
> >> * Finally, I think we need some effective date for these as required
> practices.
> >> One approach would be to require compliance for any CP/CPS dated
> >> after Dec 31, 2018.
> >>
> >> - Wayne
> >>
> >> On Tue, Oct 23, 2018 at 2:25 AM Kathleen Wilson via
> >> dev-security-policy < dev-secur...@lists.mozilla.org> wrote:
> >>
> >>> I have updated the section as follows:
> >>> - Removed the sentence that was trying to limit the use of "No
> >>> Stipulation". Hopefully the clarification about what these words
> >>> mean is sufficient.
> >>> - Added bullet points
> >>> - Added "Sections MUST not be left blank. ..."
> >>>
> >>>
> >>>
> >> https://clicktime.symantec.com/a/1/Xh-
> >> * Finally, I think we need some effective date for these as required
> practices.
> >> One approach would be to require compliance for any CP/CPS dated
> >> after Dec 31, 2018.
> >>
> >> - Wayne
> >>
> >> On Tue, Oct 23, 2018 at 2:25 AM Kathleen Wilson via
> >> dev-security-policy < dev-secur...@lists.mozilla.org> wrote:
> >>
> >>> I have updated the section as follows:
> >>> - Removed the sentence that was trying to limit the use of "No
> >>> Stipulation". Hopefully the clarification about what these words
> >>> mean is sufficient.
> >>> - Added bullet points
> >>> - Added "Sections MUST not be left blank. ..."
> >>>
> >>>
> >>>
> rJgK1XipLGMs1U1jQtvScEL4FB3RgBJ
> >> dwBJwZeYE=?d=vW4rM0CTwt8BO-
> WkB0mRKJ4JerYClzYhMZEWRTwXeQpnsTE59W7amFJ7
> >> UBJ2Lqfz4GYYK9b1-
> 861DyJ4DaHeghkm5uPyaLz88lMhRqvIqIqTZA_cIJj019oR2rEK9
> >> bhkXphYgKSUVtoR8Jv4c4ZyzmC1PwABos85PgNWZUQJmHU-
> PUFpXdUPJHpMF3mizDn82r
> >>
> k0Y2RsTkEa8rivnT6E8_XY2ct_Qb2EyuqdHD5BaiPxVGtBuabizQhhSJTxJOnwKO
> WaoM-
> >> G1uz_LEZUDTl53vgLqwOnLWYb8q3kLP7q7clVFhkAPULAOQGVhob01XI-
> oCmWpmJtDsMG
> >>
> HVzmozw0E1T4208EZyfyv2L2nQKYOsdTwEScupt4ut18MDXpcevjD2CbeA2U9
> QfVhB_kA
> >> _fCU3vcSLkeOXiJOLq-
> YfSsXuiLvEqqmw4GLGR758pQeOj_rVwNE30jDvfqbbmg&u=htt
> >>
> ps%3A%2F%2Fwiki.mozilla.org%2FCA%2FRequired_or_Recommended_Pract
> ices%
> >> 23CP.2FCPS
> >>> _Structured_According_to_RFC_3647
> >>>
> >>>
> >>> I continue to appreciate your feedback on this new section.
> >>>
>
>
> >>>
> >>>
> >>> I continue to appreciate your feedback on this new section.
> >>>
>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.
> https://clicktime.symantec.com/a/1/wiu9LnSxIGejJD4uoZpqluwf3s5JsQkbpA
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.
> XBO8_i0rw=?d=vW4rM0CTwt8BO-
> WkB0mRKJ4JerYClzYhMZEWRTwXeQpnsTE59W7amFJ7UBJ2Lqfz4GYYK9b1-
> 861DyJ4DaHeghkm5uPyaLz88lMhRqvIqIqTZA_cIJj019oR2rEK9bhkXphYgKSUV
> toR8Jv4c4ZyzmC1PwABos85PgNWZUQJmHU-
> PUFpXdUPJHpMF3mizDn82rk0Y2RsTkEa8rivnT6E8_XY2ct_Qb2EyuqdHD5BaiP
> xVGtBuabizQhhSJTxJOnwKOWaoM-
> G1uz_LEZUDTl53vgLqwOnLWYb8q3kLP7q7clVFhkAPULAOQGVhob01XI-
> oCmWpmJtDsMGHVzmozw0E1T4208EZyfyv2L2nQKYOsdTwEScupt4ut18MDX
> pcevjD2CbeA2U9QfVhB_kA_fCU3vcSLkeOXiJOLq-
> YfSsXuiLvEqqmw4GLGR758pQeOj_rVwNE30jDvfqbbmg&u=https%3A%2F%2F
> 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
> 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-secur...@lists.mozilla.org
> https://clicktime.symantec.com/a/1/iMWW4Dv3PtBKTbZjlKIU-
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> irUZprQKCSffpbwg_M87H8=?d=vW4rM0CTwt8BO-
> WkB0mRKJ4JerYClzYhMZEWRTwXeQpnsTE59W7amFJ7UBJ2Lqfz4GYYK9b1-
> 861DyJ4DaHeghkm5uPyaLz88lMhRqvIqIqTZA_cIJj019oR2rEK9bhkXphYgKSUV
> toR8Jv4c4ZyzmC1PwABos85PgNWZUQJmHU-
> PUFpXdUPJHpMF3mizDn82rk0Y2RsTkEa8rivnT6E8_XY2ct_Qb2EyuqdHD5BaiP
> xVGtBuabizQhhSJTxJOnwKOWaoM-
> G1uz_LEZUDTl53vgLqwOnLWYb8q3kLP7q7clVFhkAPULAOQGVhob01XI-
> oCmWpmJtDsMGHVzmozw0E1T4208EZyfyv2L2nQKYOsdTwEScupt4ut18MDX
> pcevjD2CbeA2U9QfVhB_kA_fCU3vcSLkeOXiJOLq-
> YfSsXuiLvEqqmw4GLGR758pQeOj_rVwNE30jDvfqbbmg&u=https%3A%2F%2Fl
> ists.mozilla.org%2Flistinfo%2Fdev-security-policy
Wayne Thayer
Oct 24, 2018, 11:29:06 AM10/24/18
to Tim Hollebeek, mozilla-dev-security-policy, Jakob Bohm
I'm with Jakob on this, but the point is moot because Kathleen chose not to
adopt that suggestion. Instead, using "no stipulation" is a SHOULD NOT
until we update the root store policy. I would encourage CAs to update
their CPSs proactively to comply with this, but there isn't yet a deadline.
- Wayne
On Wed, Oct 24, 2018 at 7:25 AM Tim Hollebeek via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
> That may be true, but I don't see any upside for using that date. If you
> need
> to make a minor CPS update in early January for any reason, you now have
> additional work.
>
> I think late December policy changes should be avoided as a general rule.
>
> >
> > Jakob
>
>
adopt that suggestion. Instead, using "no stipulation" is a SHOULD NOT
until we update the root store policy. I would encourage CAs to update
their CPSs proactively to comply with this, but there isn't yet a deadline.
- Wayne
On Wed, Oct 24, 2018 at 7:25 AM Tim Hollebeek via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
> That may be true, but I don't see any upside for using that date. If you
> need
> to make a minor CPS update in early January for any reason, you now have
> additional work.
>
> I think late December policy changes should be avoided as a general rule.
>
> -Tim
>
> > -----Original Message-----
> > From: dev-security-policy <dev-security-...@lists.mozilla.org
> >
>
> > -----Original Message-----
> > From: dev-security-policy <dev-security-...@lists.mozilla.org
> >
> > On Behalf Of Jakob Bohm via dev-security-policy
> > Sent: Wednesday, October 24, 2018 9:44 AM
> > To: mozilla-dev-s...@lists.mozilla.org
> > Cc: Jakob Bohm <jb-mo...@wisemo.com>
> > Sent: Wednesday, October 24, 2018 9:44 AM
> > To: mozilla-dev-s...@lists.mozilla.org
> > Cc: Jakob Bohm <jb-mo...@wisemo.com>
> > Subject: Re: What does "No Stipulation" mean, and when is it OK to use
> it in
> > CP/CPS?
> >
> it in
> > CP/CPS?
> >
> > On 24/10/2018 00:08, Tim Hollebeek wrote:
> > > I agree with you, but December 31 is a particularly horrible compliance
> > deadline. Perhaps January 31?
> > >
> >
> > deadline. Perhaps January 31?
> > >
> >
> > Note that the requirement applies only to CP/CPS dated after that date.
> > So it is really Dec 31 + the time until the CP/CPS is updated for some
> other
> > reason. This is different than many other policy requirements, and a
> > welcome reduction in administrative overhead for all concerned (including
> > root programs and relying parties).
> >
> > For example, it a CA updated their CP/CPS in August 2018 to comply with
> > new BRs, and again in May 2019 due to annual review, they need not comply
> > until May 2019.
> >
> > >
> > So it is really Dec 31 + the time until the CP/CPS is updated for some
> other
> > reason. This is different than many other policy requirements, and a
> > welcome reduction in administrative overhead for all concerned (including
> > root programs and relying parties).
> >
> > For example, it a CA updated their CP/CPS in August 2018 to comply with
> > new BRs, and again in May 2019 due to annual review, they need not comply
> > until May 2019.
> >
> > >
> > >> -----Original Message-----
> > >> From: dev-security-policy
> > >> <dev-security-...@lists.mozilla.org> On Behalf Of Wayne
> > >> Thayer via dev-security-policy
> > >> Sent: Monday, October 22, 2018 6:00 PM
> > >> To: Kathleen Wilson <kwi...@mozilla.com>
> > >> Cc: mozilla-dev-security-policy
> > >> <mozilla-dev-s...@lists.mozilla.org>
> > >> Subject: Re: What does "No Stipulation" mean, and when is it OK to
> > >> use it in CP/CPS?
> > >>
> > >> Having given this some more thought, I suggest the following changes:
> > >>
> > >> ...
> > >> From: dev-security-policy
> > >> <dev-security-...@lists.mozilla.org> On Behalf Of Wayne
> > >> Thayer via dev-security-policy
> > >> Sent: Monday, October 22, 2018 6:00 PM
> > >> To: Kathleen Wilson <kwi...@mozilla.com>
> > >> Cc: mozilla-dev-security-policy
> > >> <mozilla-dev-s...@lists.mozilla.org>
> > >> Subject: Re: What does "No Stipulation" mean, and when is it OK to
> > >> use it in CP/CPS?
> > >>
> > >> Having given this some more thought, I suggest the following changes:
> > >>
> > >>
> > >> * Finally, I think we need some effective date for these as required
> > practices.
> > >> One approach would be to require compliance for any CP/CPS dated
> > >> after Dec 31, 2018.
> > >>
> > >> - Wayne
> > >>
> > >> On Tue, Oct 23, 2018 at 2:25 AM Kathleen Wilson via
> > >> dev-security-policy < dev-secur...@lists.mozilla.org> wrote:
> > >>
> > >>> I have updated the section as follows:
> > >>> - Removed the sentence that was trying to limit the use of "No
> > >>> Stipulation". Hopefully the clarification about what these words
> > >>> mean is sufficient.
> > >>> - Added bullet points
> > >>> - Added "Sections MUST not be left blank. ..."
> > >>>
> > >>>
> > >>>
> > >> * Finally, I think we need some effective date for these as required
> > practices.
> > >> One approach would be to require compliance for any CP/CPS dated
> > >> after Dec 31, 2018.
> > >>
> > >> - Wayne
> > >>
> > >> On Tue, Oct 23, 2018 at 2:25 AM Kathleen Wilson via
> > >> dev-security-policy < dev-secur...@lists.mozilla.org> wrote:
> > >>
> > >>> I have updated the section as follows:
> > >>> - Removed the sentence that was trying to limit the use of "No
> > >>> Stipulation". Hopefully the clarification about what these words
> > >>> mean is sufficient.
> > >>> - Added bullet points
> > >>> - Added "Sections MUST not be left blank. ..."
> > >>>
> > >>>
> > >>>
> > >> https://clicktime.symantec.com/a/1/Xh-
> > rJgK1XipLGMs1U1jQtvScEL4FB3RgBJ
> > >> dwBJwZeYE=?d=vW4rM0CTwt8BO-
> > WkB0mRKJ4JerYClzYhMZEWRTwXeQpnsTE59W7amFJ7
> > >> UBJ2Lqfz4GYYK9b1-
> > 861DyJ4DaHeghkm5uPyaLz88lMhRqvIqIqTZA_cIJj019oR2rEK9
> > >> bhkXphYgKSUVtoR8Jv4c4ZyzmC1PwABos85PgNWZUQJmHU-
> > PUFpXdUPJHpMF3mizDn82r
> > >>
> > k0Y2RsTkEa8rivnT6E8_XY2ct_Qb2EyuqdHD5BaiPxVGtBuabizQhhSJTxJOnwKO
> > WaoM-
> > >> G1uz_LEZUDTl53vgLqwOnLWYb8q3kLP7q7clVFhkAPULAOQGVhob01XI-
> > oCmWpmJtDsMG
> > >>
> > HVzmozw0E1T4208EZyfyv2L2nQKYOsdTwEScupt4ut18MDXpcevjD2CbeA2U9
> > QfVhB_kA
> > >> _fCU3vcSLkeOXiJOLq-
> > YfSsXuiLvEqqmw4GLGR758pQeOj_rVwNE30jDvfqbbmg&u=htt
> > >>
> > ps%3A%2F%2Fwiki.mozilla.org%2FCA%2FRequired_or_Recommended_Pract
> > ices%
> > >> 23CP.2FCPS
> > rJgK1XipLGMs1U1jQtvScEL4FB3RgBJ
> > >> dwBJwZeYE=?d=vW4rM0CTwt8BO-
> > WkB0mRKJ4JerYClzYhMZEWRTwXeQpnsTE59W7amFJ7
> > >> UBJ2Lqfz4GYYK9b1-
> > 861DyJ4DaHeghkm5uPyaLz88lMhRqvIqIqTZA_cIJj019oR2rEK9
> > >> bhkXphYgKSUVtoR8Jv4c4ZyzmC1PwABos85PgNWZUQJmHU-
> > PUFpXdUPJHpMF3mizDn82r
> > >>
> > k0Y2RsTkEa8rivnT6E8_XY2ct_Qb2EyuqdHD5BaiPxVGtBuabizQhhSJTxJOnwKO
> > WaoM-
> > >> G1uz_LEZUDTl53vgLqwOnLWYb8q3kLP7q7clVFhkAPULAOQGVhob01XI-
> > oCmWpmJtDsMG
> > >>
> > HVzmozw0E1T4208EZyfyv2L2nQKYOsdTwEScupt4ut18MDXpcevjD2CbeA2U9
> > QfVhB_kA
> > >> _fCU3vcSLkeOXiJOLq-
> > YfSsXuiLvEqqmw4GLGR758pQeOj_rVwNE30jDvfqbbmg&u=htt
> > >>
> > ps%3A%2F%2Fwiki.mozilla.org%2FCA%2FRequired_or_Recommended_Pract
> > ices%
> > >> 23CP.2FCPS
> > >>> _Structured_According_to_RFC_3647
> > >>>
> > >>>
> > >>> I continue to appreciate your feedback on this new section.
> > >>>
> >
> >
> > Enjoy
> > >>>
> > >>>
> > >>> I continue to appreciate your feedback on this new section.
> > >>>
> >
> >
> >
> > Jakob
>
>
Joanna Fox
Oct 25, 2018, 2:17:04 PM10/25/18
to mozilla-dev-s...@lists.mozilla.org
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?
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?
Wayne Thayer
Oct 25, 2018, 5:11:22 PM10/25/18
to jwe...@godaddy.com, mozilla-dev-security-policy
On Thu, Oct 25, 2018 at 11:17 AM Joanna Fox via dev-security-policy <
dev-secur...@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
dev-secur...@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?
>
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?
>
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
Jakob Bohm
Oct 25, 2018, 6:47:54 PM10/25/18
to mozilla-dev-s...@lists.mozilla.org
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
Ryan Sleevi
Oct 25, 2018, 7:13:24 PM10/25/18
to mozilla-dev-security-policy, Jakob Bohm
On Thu, Oct 25, 2018 at 5:47 PM Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
> On 25/10/2018 23:10, Wayne Thayer wrote:
dev-secur...@lists.mozilla.org> wrote:
> On 25/10/2018 23:10, Wayne Thayer wrote:
> 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?
> appropriate higher level sections, after the RFC section numbers run out
> at that level?
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.
Jakob Bohm
Oct 26, 2018, 1:11:54 AM10/26/18
to mozilla-dev-s...@lists.mozilla.org
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.
Wayne Thayer
Oct 26, 2018, 4:28:52 PM10/26/18
to Jakob Bohm, mozilla-dev-security-policy
On Thu, Oct 25, 2018 at 10:11 PM Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
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-secur...@lists.mozilla.org> wrote:
> 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
> 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.
>
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
0 new messages