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-policy-boun...@lists.mozilla.org> On > Behalf Of Wayne Thayer via dev-security-policy > Sent: Monday, October 22, 2018 6:00 PM > To: Kathleen Wilson <kwil...@mozilla.com> > Cc: mozilla-dev-security-policy > <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? > > 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 > > On Tue, Oct 23, 2018 at 2:25 AM Kathleen Wilson via dev-security-policy < > dev-security-policy@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-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
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
