I think "Not applicable" would be superior to "No stipulation", when appropriate.
"3.2.2.5. No IP address certificates are issued under this CPS." is even clearer. I haven't looked into the implications of this, but perhaps it would be worth considering not allowing "No stipulation" in CPSs for sections that are not marked "No stipulation" in the Baseline Requirements. -Tim > -----Original Message----- > From: dev-security-policy <[email protected]> > On Behalf Of Jakob Bohm via dev-security-policy > Sent: Wednesday, October 10, 2018 6:09 AM > To: [email protected] > Cc: Jakob Bohm <[email protected]> > Subject: Re: What does "No Stipulation" mean, and when is it OK to use it in > CP/CPS > > On 09/10/2018 23:15, Wayne Thayer wrote: > > On Tue, Oct 9, 2018 at 12:48 PM Kathleen Wilson via > > dev-security-policy < [email protected]> wrote: > > > >> Oh, so rather than trying to define what "No Stipulation" means and > >> when it can be used, we could take a different approach -- list the > >> sections that cannot contain "No Stipulation" in the CPS. > >> > > This approach implies that we are adopting the RFC 3647 definition of > > "no stipulation" meaning "we can do whatever we want", not the meaning > > of "we don't do this" that I believe is intended in the examples your > > provided. If we take this approach, we should specify those section > > that **must be > > present** and cannot contain "no stipulation" (or similar permissive > > language). Omitting a section defined in RFC 3647 is equivalent to "no > > stipulation". > > > > In formulating Mozilla Policy one should also consider the case that a section > is rendered inapplicable by the contents of another section. > > For example if another CP/CPS section clearly states that the certificates > will > not contain IP addresses as names (alternative or otherwise), then it would > be OK to not state how IP addresses are validated. (Such a section might for > example state that certificates only contain DNS names). > > As second example, if another CP/CPS section enumerates the validation > methods used, then it would be OK to omit sections about methods not in > that enumeration. > > As a third example, the parent section of the section listing BR methods > could state (in various ways) that only the methods explicitly listed will be > used. This particular notation could avoid a CP/CPS change to a "This > method is not used" section when the corresponding section in the BR is > changed, added or removed. > > > > >> On 10/9/18 12:31 PM, Brown, Wendy (10421) wrote: > >>> 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. > >>> > > > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. > https://clicktime.symantec.com/a/1/sXnCWBuQE3OxwGzDGFCP8tz2qr4y8b > NKgbC6- > _XfwpE=?d=Z2HQ1P_v8531y6J8lUlVsUTcmCX72dez2n3uy6rBVqj3AP_W9Le5 > Kck3YIgBpWiS77d8jWkRS0b6l9KDqFwcKEocqyvVnN5uK-qbUnOkjeAK5nOY- > I07AC1KoUfhN33_MJaNeohcavrTshCIAAtrsPn_ccAchU2O65lWqwDaHUoHRh > 9gIYPwwxf7tCdkXlf5pf2-RTSRUapCGMR5i- > D5rFzE5bLaRqyIJQawRpDBOC8lwAgcAIYySICtdAPtmTtxZaS1ekVbuYxfKKAqnD > QXB4SuFx0Pm6w9JPnU0xYppl0EUNTCMyfc9XtS_ZVRv5C30dxjSrwQjQ4azrub > pnWxwa2bSJTbuMGd25gNskRQAmSpLbSupgWEe7g2WWrxkA0nnmE8J4ksZu > JonRs5qSCPxAduJkwssCKkmmZatvuGPimdKnfVibZ07vgopAqoQ7ZmszJyA1jt3 > Wv4weiQ&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 > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://clicktime.symantec.com/a/1/qXbwT24EADX2Ce3aTbvNmHpiiHBgOP > WeQxQoWaZqW6s=?d=Z2HQ1P_v8531y6J8lUlVsUTcmCX72dez2n3uy6rBVqj3 > AP_W9Le5Kck3YIgBpWiS77d8jWkRS0b6l9KDqFwcKEocqyvVnN5uK- > qbUnOkjeAK5nOY- > I07AC1KoUfhN33_MJaNeohcavrTshCIAAtrsPn_ccAchU2O65lWqwDaHUoHRh > 9gIYPwwxf7tCdkXlf5pf2-RTSRUapCGMR5i- > D5rFzE5bLaRqyIJQawRpDBOC8lwAgcAIYySICtdAPtmTtxZaS1ekVbuYxfKKAqnD > QXB4SuFx0Pm6w9JPnU0xYppl0EUNTCMyfc9XtS_ZVRv5C30dxjSrwQjQ4azrub > pnWxwa2bSJTbuMGd25gNskRQAmSpLbSupgWEe7g2WWrxkA0nnmE8J4ksZu > JonRs5qSCPxAduJkwssCKkmmZatvuGPimdKnfVibZ07vgopAqoQ7ZmszJyA1jt3 > Wv4weiQ&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security- > policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
