RE: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS
Tim - I think that statement leaves out the next paragraph of RFC3647: In a CP, it is possible to leave certain components, subcomponents, and/or elements unspecified, and to stipulate that the required information will be indicated in a policy qualifier, or the document to which a policy qualifier points. Such CPs can be considered parameterized definitions. The set of provisions should reference or define the required policy qualifier types and should specify any applicable default values. I think normally the policy qualifier points to a CPS, but it might be some other document. But in any case if both CP & CPS say "No stipulation" in regards to something that Mozilla cares about like what validation methods are supported for TLS certificates, then it is very hard to evaluate that set of "disclosed business practices" to determine if the CA operates in accord with the BRs or Mozilla's policy. I think there may be some sections of a CP/CPS that are less critical, but in terms of any section that is critical to the evaluation for inclusion in a particular trust store, I would expect one of the 2 documents to clearly state the operational practices of the CA rather than just stating "No Stipulation" in both CP & CPS, unless the Policy Qualifier in issued certificates points to some other document that contains that information. Again - just my personal opinion. wendy Date: Tue, 9 Oct 2018 19:02:54 + From: Tim Hollebeek mailto:tim.holleb...@digicert.com>> To: "dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>" mailto:dev-security-policy@lists.mozilla.org>> Subject: RE: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS? Message-ID: mailto:bn6pr14mb110664cd140c0a82f006afa483...@bn6pr14mb1106.namprd14.prod.outlook.com>> Content-Type: text/plain; charset="us-ascii" 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." " 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 > -----Original Message----- > From: dev-security-policy > mailto:dev-security-policy-boun...@lists.mozilla.org>> > On Behalf Of Brown, Wendy (10421) via dev-security-policy > Sent: Tuesday, October 9, 2018 2:55 PM > To: > dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org> > Subject: RE: What does "No Stipulation" mean, and when is it OK to use > it in > CP/CPS? > > 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.br...@protiviti.com<mailto:wendy.br...@protiviti.com> > > > - > > Date: Tue, 9 Oct 2018 09:48:26 -0700 > From: Kathleen Wilson mailto:kwil...@mozilla.com>
RE: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?
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.br...@protiviti.com - Date: Tue, 9 Oct 2018 09:48:26 -0700 From: Kathleen Wilson To: mozilla-dev-security-pol...@lists.mozilla.org Subject: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS? Message-ID: 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?? 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
