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-security-policy@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-policy-boun...@lists.mozilla.org> > On > > Behalf Of Joanna Fox via dev-security-policy > > Sent: Friday, October 19, 2018 1:39 PM > > To: mozilla-dev-security-pol...@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 > > > > 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 > > > > > > > > I will continue to appreciate feedback on this update. > > > > > > > > Thanks, > > > > Kathleen > > > > > > > > > > Upon closer look, it appears that most of the "No Stipulation" entries > > > 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). > > > > > > > > > > > > Enjoy > > > > > > Jakob > > > -- > > > Jakob Bohm, CIO, Partner, WiseMo A/S. > > > > > 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 > > > 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 > > Stipulation" mean that the particular document imposes no requirements > > 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 > > _______________________________________________ > > dev-security-policy mailing list > > dev-security-policy@lists.mozilla.org > > https://clicktime.symantec.com/a/1/u49v5OVN_9xGhZ5hvzqQF62t7Nd_Oup7 > > 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 > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
