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 <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 > 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 > > > ----------------------------- > > Date: Tue, 9 Oct 2018 09:48:26 -0700 > From: Kathleen Wilson <kwil...@mozilla.com> > 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: <n5sdneed28pgrihgnz2dnuu7-fpnn...@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?? > > 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 > > 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. > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
