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
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
