Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

[Wayne Thayer via dev-security-policy]

On Thu, Oct 25, 2018 at 10:11 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 26/10/2018 01:13, Ryan Sleevi wrote:
> > On Thu, Oct 25, 2018 at 5:47 PM Jakob Bohm via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> >> On 25/10/2018 23:10, Wayne Thayer wrote:
> >>> On Thu, Oct 25, 2018 at 11:17 AM Joanna Fox via dev-security-policy <
> >>> dev-security-policy@lists.mozilla.org> wrote:
> >>>
>  Questions about blank sections, thinking of a potential future
>  requirement. Sections such as 1.INTRODUCTION would remain blank as
> they
> >> are
>  more titles than components, correct?
>  If no sections are allowed to be blank does this include both levels
> of
>  components such as 1.4 and 1.4.1?
> 
>  I would argue that higher level sections (e.g. 1.4)  aren't blank if
> >> they
> >>> include subsections (e.g. 1.4.1). If there are no subsections under a
> >>> section (e.g. 1.1 or 2), then the section should not be blank.
> >>>
> >>> Also, what is the opinion on adding sections to the CP/CPS that are not
>  included in the RFC?
> 
>  Good question. My opinion is that it's okay to add sections as long as
> >>> they come after RFC 3647 defined sections and thus don't change the RFC
> >>> numbering. I've noted this in the policy issue -
> >>> https://github.com/mozilla/pkipolicy/issues/158
> >>>
> >>
> >> Would it be OK (I think it should) to place new sublevel sections under
> >> appropriate higher level sections, after the RFC section numbers run out
> >> at that level?
> >
> >
> > Can you explain why that is valuable?
> >
> > What purpose do you believe the CP/CPS structure serves? One of the goals
> > of developing the structure in the RFC was to identify the common
> sections
> > applicable to all CAs, with a consistent structure, to allow easy
> > comparison between policies. Indeed, early audit processes proposed
> making
> > these policies machine readable and templated, to expedite comparisons.
> >
>
> I is quite obvious that the 15 year old RFC3647 doesn't cover all the
> issues that need to be covered in a modern CP/CPS, the BRs already add
> many subsections not in the RFC.  I was giving concrete examples about
> what kinds of sections to add.
>
> However my question wasn't if additional sections could be added, this
> was already asked by someone obviously intending to do so.
>
> I was asking if such new sections could be placed where they would make
> the most logical sense rather than being confined to a section 10
> appendix.  I then gave examples of how some commonly occurring issues
> (such as a single CP/CPS covering both WebPKI and non-WebPKI roots)
> would fit more neatly earlier in a policy document.
>
> My response stating that I think this is okay was intended to include
adding new subsections to the end of any of the existing sections. I do
share some concern with this because it has and will continue to result in
information being placed into new sections rather than appropriate existing
sections. However, I also think there are legitimate reasons for adding
sections, and it makes more sense to logically group them with similar
content than at the end of the doc.

>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.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
> 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

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

[Ryan Sleevi via dev-security-policy]

On Thu, Oct 25, 2018 at 5:47 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 25/10/2018 23:10, Wayne Thayer wrote:
> > On Thu, Oct 25, 2018 at 11:17 AM Joanna Fox via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> >> Questions about blank sections, thinking of a potential future
> >> requirement. Sections such as 1.INTRODUCTION would remain blank as they
> are
> >> more titles than components, correct?
> >> If no sections are allowed to be blank does this include both levels of
> >> components such as 1.4 and 1.4.1?
> >>
> >> I would argue that higher level sections (e.g. 1.4)  aren't blank if
> they
> > include subsections (e.g. 1.4.1). If there are no subsections under a
> > section (e.g. 1.1 or 2), then the section should not be blank.
> >
> > Also, what is the opinion on adding sections to the CP/CPS that are not
> >> included in the RFC?
> >>
> >> Good question. My opinion is that it's okay to add sections as long as
> > they come after RFC 3647 defined sections and thus don't change the RFC
> > numbering. I've noted this in the policy issue -
> > https://github.com/mozilla/pkipolicy/issues/158
> >
>
> Would it be OK (I think it should) to place new sublevel sections under
> appropriate higher level sections, after the RFC section numbers run out
> at that level?


Can you explain why that is valuable?

What purpose do you believe the CP/CPS structure serves? One of the goals
of developing the structure in the RFC was to identify the common sections
applicable to all CAs, with a consistent structure, to allow easy
comparison between policies. Indeed, early audit processes proposed making
these policies machine readable and templated, to expedite comparisons.

I can see quite a bit of harm from your hypothetical, and have seen it in
the policies reviewed, so it would be useful to understand why you would
like to do this and what you see the purpose for CP/CPS that this would
benefit.

If you’re merely posing it as “someone” might want to, it seems like it
would be better to let those “someones” speak to their needs and use cases.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

[Jakob Bohm via dev-security-policy]

On 25/10/2018 23:10, Wayne Thayer wrote:

On Thu, Oct 25, 2018 at 11:17 AM Joanna Fox via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


Questions about blank sections, thinking of a potential future
requirement. Sections such as 1.INTRODUCTION would remain blank as they are
more titles than components, correct?
If no sections are allowed to be blank does this include both levels of
components such as 1.4 and 1.4.1?

I would argue that higher level sections (e.g. 1.4)  aren't blank if they

include subsections (e.g. 1.4.1). If there are no subsections under a
section (e.g. 1.1 or 2), then the section should not be blank.

Also, what is the opinion on adding sections to the CP/CPS that are not

included in the RFC?

Good question. My opinion is that it's okay to add sections as long as

they come after RFC 3647 defined sections and thus don't change the RFC
numbering. I've noted this in the policy issue -
https://github.com/mozilla/pkipolicy/issues/158



Would it be OK (I think it should) to place new sublevel sections under
appropriate higher level sections, after the RFC section numbers run out
at that level?

For example, some CA may want to add a section like the following
examples (these are numbers in the same overall sections as related
standard sections) (The sections below are arbitrary and not proposed
as any kind of standard):

1.1.2 Categories of root CA certificates under this policy
1.1.2.1 Application-trusted General roots
1.1.2.2 Browser-trusted WebPKI roots
1.1.2.3 Mail-application trusted email roots
1.1.2.4 System trusted code signing roots
1.1.2.5 Time stamping roots
1.1.2.6 Compatibility roots for use with older software
1.1.2.7 Historic roots used for historic signatures
1.1.2.8 Discontinued roots
1.1.2.9 Test roots
1.1.2.10 Experimental roots
1.6.5 Non-Normative references
3.1.7 Territorial name restrictions
4.9.17 Availability of historic revocation information
4.9.17.3 Historic revocation information for e-mail certificates. etc.
4.13 Intermediary CA certificate rotation procedures.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.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
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

[Wayne Thayer via dev-security-policy]

On Thu, Oct 25, 2018 at 11:17 AM Joanna Fox via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Questions about blank sections, thinking of a potential future
> requirement. Sections such as 1.INTRODUCTION would remain blank as they are
> more titles than components, correct?
> If no sections are allowed to be blank does this include both levels of
> components such as 1.4 and 1.4.1?
>
> I would argue that higher level sections (e.g. 1.4)  aren't blank if they
include subsections (e.g. 1.4.1). If there are no subsections under a
section (e.g. 1.1 or 2), then the section should not be blank.

Also, what is the opinion on adding sections to the CP/CPS that are not
> included in the RFC?
>
> Good question. My opinion is that it's okay to add sections as long as
they come after RFC 3647 defined sections and thus don't change the RFC
numbering. I've noted this in the policy issue -
https://github.com/mozilla/pkipolicy/issues/158

- Wayne
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

[Joanna Fox via dev-security-policy]

Questions about blank sections, thinking of a potential future requirement. 
Sections such as 1.INTRODUCTION would remain blank as they are more titles than 
components, correct?
If no sections are allowed to be blank does this include both levels of 
components such as 1.4 and 1.4.1?  

Also, what is the opinion on adding sections to the CP/CPS that are not 
included in the RFC?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

[Wayne Thayer via dev-security-policy]

I'm with Jakob on this, but the point is moot because Kathleen chose not to
adopt that suggestion. Instead, using "no stipulation" is a SHOULD NOT
until we update the root store policy. I would encourage CAs to update
their CPSs proactively to comply with this, but there isn't yet a deadline.

- Wayne

On Wed, Oct 24, 2018 at 7:25 AM Tim Hollebeek via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> That may be true, but I don't see any upside for using that date.  If you
> need
> to make a minor CPS update in early January for any reason, you now have
> additional work.
>
> I think late December policy changes should be avoided as a general rule.
>
> -Tim
>
> > -Original Message-
> > From: dev-security-policy  >
> > On Behalf Of Jakob Bohm via dev-security-policy
> > Sent: Wednesday, October 24, 2018 9:44 AM
> > To: mozilla-dev-security-pol...@lists.mozilla.org
> > Cc: Jakob Bohm 
> > Subject: Re: What does "No Stipulation" mean, and when is it OK to use
> it in
> > CP/CPS?
> >
> > On 24/10/2018 00:08, Tim Hollebeek wrote:
> > > I agree with you, but December 31 is a particularly horrible compliance
> > deadline.  Perhaps January 31?
> > >
> >
> > Note that the requirement applies only to CP/CPS dated after that date.
> > So it is really Dec 31 + the time until the CP/CPS is updated for some
> other
> > reason.  This is different than many other policy requirements, and a
> > welcome reduction in administrative overhead for all concerned (including
> > root programs and relying parties).
> >
> > For example, it a CA updated their CP/CPS in August 2018 to comply with
> > new BRs, and again in May 2019 due to annual review, they need not comply
> > until May 2019.
> >
> > >
> > >> -Original Message-
> > >> From: dev-security-policy
> > >>  On Behalf Of Wayne
> > >> Thayer via dev-security-policy
> > >> Sent: Monday, October 22, 2018 6:00 PM
> > >> To: Kathleen Wilson 
> > >> Cc: mozilla-dev-security-policy
> > >> 
> > >> 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:
> > >>
> > >> ...
> > >>
> > >> * 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://clicktime.symantec.com/a/1/Xh-
> > rJgK1XipLGMs1U1jQtvScEL4FB3RgBJ
> > >> dwBJwZeYE=?d=vW4rM0CTwt8BO-
> > WkB0mRKJ4JerYClzYhMZEWRTwXeQpnsTE59W7amFJ7
> > >> UBJ2Lqfz4GYYK9b1-
> > 861DyJ4DaHeghkm5uPyaLz88lMhRqvIqIqTZA_cIJj019oR2rEK9
> > >> bhkXphYgKSUVtoR8Jv4c4ZyzmC1PwABos85PgNWZUQJmHU-
> > PUFpXdUPJHpMF3mizDn82r
> > >>
> > k0Y2RsTkEa8rivnT6E8_XY2ct_Qb2EyuqdHD5BaiPxVGtBuabizQhhSJTxJOnwKO
> > WaoM-
> > >> G1uz_LEZUDTl53vgLqwOnLWYb8q3kLP7q7clVFhkAPULAOQGVhob01XI-
> > oCmWpmJtDsMG
> > >>
> > HVzmozw0E1T4208EZyfyv2L2nQKYOsdTwEScupt4ut18MDXpcevjD2CbeA2U9
> > QfVhB_kA
> > >> _fCU3vcSLkeOXiJOLq-
> > YfSsXuiLvEqqmw4GLGR758pQeOj_rVwNE30jDvfqbbmg=htt
> > >>
> > ps%3A%2F%2Fwiki.mozilla.org%2FCA%2FRequired_or_Recommended_Pract
> > ices%
> > >> 23CP.2FCPS
> > >>> _Structured_According_to_RFC_3647
> > >>>
> > >>>
> > >>> I continue to appreciate your feedback on this new section.
> > >>>
> >
> >
> > Enjoy
> >
> > Jakob
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

[Tim Hollebeek via dev-security-policy]

That may be true, but I don't see any upside for using that date.  If you need
to make a minor CPS update in early January for any reason, you now have
additional work.

I think late December policy changes should be avoided as a general rule.

-Tim

> -Original Message-
> From: dev-security-policy 
> On Behalf Of Jakob Bohm via dev-security-policy
> Sent: Wednesday, October 24, 2018 9:44 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Cc: Jakob Bohm 
> Subject: Re: What does "No Stipulation" mean, and when is it OK to use it in
> CP/CPS?
> 
> On 24/10/2018 00:08, Tim Hollebeek wrote:
> > I agree with you, but December 31 is a particularly horrible compliance
> deadline.  Perhaps January 31?
> >
> 
> Note that the requirement applies only to CP/CPS dated after that date.
> So it is really Dec 31 + the time until the CP/CPS is updated for some other
> reason.  This is different than many other policy requirements, and a
> welcome reduction in administrative overhead for all concerned (including
> root programs and relying parties).
> 
> For example, it a CA updated their CP/CPS in August 2018 to comply with
> new BRs, and again in May 2019 due to annual review, they need not comply
> until May 2019.
> 
> >
> >> -Original Message-
> >> From: dev-security-policy
> >>  On Behalf Of Wayne
> >> Thayer via dev-security-policy
> >> Sent: Monday, October 22, 2018 6:00 PM
> >> To: Kathleen Wilson 
> >> Cc: mozilla-dev-security-policy
> >> 
> >> 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:
> >>
> >> ...
> >>
> >> * 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://clicktime.symantec.com/a/1/Xh-
> rJgK1XipLGMs1U1jQtvScEL4FB3RgBJ
> >> dwBJwZeYE=?d=vW4rM0CTwt8BO-
> WkB0mRKJ4JerYClzYhMZEWRTwXeQpnsTE59W7amFJ7
> >> UBJ2Lqfz4GYYK9b1-
> 861DyJ4DaHeghkm5uPyaLz88lMhRqvIqIqTZA_cIJj019oR2rEK9
> >> bhkXphYgKSUVtoR8Jv4c4ZyzmC1PwABos85PgNWZUQJmHU-
> PUFpXdUPJHpMF3mizDn82r
> >>
> k0Y2RsTkEa8rivnT6E8_XY2ct_Qb2EyuqdHD5BaiPxVGtBuabizQhhSJTxJOnwKO
> WaoM-
> >> G1uz_LEZUDTl53vgLqwOnLWYb8q3kLP7q7clVFhkAPULAOQGVhob01XI-
> oCmWpmJtDsMG
> >>
> HVzmozw0E1T4208EZyfyv2L2nQKYOsdTwEScupt4ut18MDXpcevjD2CbeA2U9
> QfVhB_kA
> >> _fCU3vcSLkeOXiJOLq-
> YfSsXuiLvEqqmw4GLGR758pQeOj_rVwNE30jDvfqbbmg=htt
> >>
> ps%3A%2F%2Fwiki.mozilla.org%2FCA%2FRequired_or_Recommended_Pract
> ices%
> >> 23CP.2FCPS
> >>> _Structured_According_to_RFC_3647
> >>>
> >>>
> >>> I continue to appreciate your feedback on this new section.
> >>>
> 
> 
> Enjoy
> 
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.
> https://clicktime.symantec.com/a/1/wiu9LnSxIGejJD4uoZpqluwf3s5JsQkbpA
> XBO8_i0rw=?d=vW4rM0CTwt8BO-
> WkB0mRKJ4JerYClzYhMZEWRTwXeQpnsTE59W7amFJ7UBJ2Lqfz4GYYK9b1-
> 861DyJ4DaHeghkm5uPyaLz88lMhRqvIqIqTZA_cIJj019oR2rEK9bhkXphYgKSUV
> toR8Jv4c4ZyzmC1PwABos85PgNWZUQJmHU-
> PUFpXdUPJHpMF3mizDn82rk0Y2RsTkEa8rivnT6E8_XY2ct_Qb2EyuqdHD5BaiP
> xVGtBuabizQhhSJTxJOnwKOWaoM-
> G1uz_LEZUDTl53vgLqwOnLWYb8q3kLP7q7clVFhkAPULAOQGVhob01XI-
> oCmWpmJtDsMGHVzmozw0E1T4208EZyfyv2L2nQKYOsdTwEScupt4ut18MDX
> pcevjD2CbeA2U9QfVhB_kA_fCU3vcSLkeOXiJOLq-
> YfSsXuiLvEqqmw4GLGR758pQeOj_rVwNE30jDvfqbbmg=https%3A%2F%2F
> www.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
> dev-security-policy@lists.mozilla.org
> https://clicktime.symantec.com/a/1/iMWW4Dv3PtBKTbZjlKIU-
> irUZprQKCSffpbwg_M87H8=?d=vW4rM0CTwt8BO-
> WkB0mRKJ4JerYClzYhMZEWRTwXeQpnsTE59W7amFJ7UBJ2Lqfz4GYYK9b1-
> 861DyJ4DaHeghkm5uPyaLz88lMhRqvIqIqTZA_cIJj019oR2rEK9bhkXphYgKSUV
> toR8Jv4c4ZyzmC1PwABos85PgNWZUQJmHU-
> PUFpXdUPJHpMF3mizDn82rk0Y2RsTkEa8rivnT6E8_XY2ct_Qb2EyuqdHD5BaiP
> xVGtBuabizQhhSJTxJOnwKOWaoM-
> G1uz_LEZUDTl53vgLqwOnLWYb8q3kLP7q7clVFhkAPULAOQGVhob01XI-
> oCmWpmJtDsMGHVzmozw0E1T4208EZyfyv2L2nQKYOsdTwEScupt4ut18MDX
> pcevjD2CbeA2U9QfVhB_kA_fCU3vcSLkeOXiJOLq-
> YfSsXuiLvEqqmw4GLGR758pQeOj_rVwNE30jDvfqbbmg=https%3A%2F%2Fl
> ists.mozilla.org%2Flistinfo%2Fdev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

[Jakob Bohm via dev-security-policy]

On 24/10/2018 00:08, Tim Hollebeek wrote:

I agree with you, but December 31 is a particularly horrible compliance 
deadline.  Perhaps January 31?



Note that the requirement applies only to CP/CPS dated after that date.
So it is really Dec 31 + the time until the CP/CPS is updated for some
other reason.  This is different than many other policy requirements,
and a welcome reduction in administrative overhead for all concerned
(including root programs and relying parties).

For example, it a CA updated their CP/CPS in August 2018 to comply with
new BRs, and again in May 2019 due to annual review, they need not
comply until May 2019.




-Original Message-
From: dev-security-policy  On
Behalf Of Wayne Thayer via dev-security-policy
Sent: Monday, October 22, 2018 6:00 PM
To: Kathleen Wilson 
Cc: mozilla-dev-security-policy 
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:

...

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




Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.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
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

[Tim Hollebeek via dev-security-policy]

I agree with you, but December 31 is a particularly horrible compliance 
deadline.  Perhaps January 31?

-Tim

> -Original Message-
> From: dev-security-policy  On
> Behalf Of Wayne Thayer via dev-security-policy
> Sent: Monday, October 22, 2018 6:00 PM
> To: Kathleen Wilson 
> Cc: mozilla-dev-security-policy 
> 
> 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

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

[Kathleen Wilson via dev-security-policy]

I have updated this section in the wiki page again as follows:
- Changed the word 'must' to 'should' for items that are not currently 
in Mozilla's Root Store Policy or the BRs. We plan to change these back 
to 'must' after Wayne updates Mozilla's Root Store Policy regarding this 
topic.
- Added notes/warnings that Mozilla's root store policy may be updated 
soon to forbid use of blank sections and "No Stipulation".
- Added bullet point about clarifying in the CP/CPS when certain 
sections (like private key generation and escrow) only apply to certain 
types of certificates.


https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CP.2FCPS_Structured_According_to_RFC_3647

Thanks,
Kathleen

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

[Wayne Thayer via dev-security-policy]

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

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

[Kathleen Wilson via dev-security-policy]

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

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

[Ryan Sleevi via dev-security-policy]

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

RE: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

[Tim Hollebeek via dev-security-policy]

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

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

[Joanna Fox via dev-security-policy]

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://wiki.mozilla.org/CA/Required_or_Recommended_Practices#BR_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://www.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://lists.mozilla.org/listinfo/dev-security-policy

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

[Jakob Bohm via dev-security-policy]

On 15/10/2018 20:01, Kathleen Wilson wrote:

I have added the following section to the Required Practices wiki page:

https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#BR_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://www.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
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

[Matt Palmer via dev-security-policy]

On Thu, Oct 18, 2018 at 03:44:44PM -0700, Kathleen Wilson via 
dev-security-policy wrote:
> I think that a blank section means the same thing as "No stipulation".
> Should we require that sections not be left blank?

I think that for the avoidance of any sort of doubt or confusion, it would
be best to require that sections not be left blank.

- Matt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

[Kathleen Wilson via dev-security-policy]

On 10/18/18 2:03 PM, Joanna Fox wrote:

https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CP.2FCPS_Structured_According_to_RFC_3647


For clarification on this statement, "Any CPS that falls within the scope of 
Mozilla’s program must not use the words “No stipulation” unless the corresponding 
section in the CA/Browser Forum Baseline Requirements state “No stipulation”, “Not 
applicable”, or is blank."

Is the intent to use No stipulation”, “Not applicable”, or blank 
interchangeably?



No. The intent of that statement was to limit the sections for which the 
CA's CP/CPS may use the words "No stipulation".


Do you have a suggestion about how to make this more clear?

Note that just before that sentence is:
"The words "No Stipulation" mean that the particular document imposes no 
requirements related to that section."


And the following sentence says:
"The words “Not applicable” are acceptable to indicate that the CA’s 
policies forbid the practice that is the title of the section."


To me, those mean very different things.


We did not define what a blank section means...

I think that a blank section means the same thing as "No stipulation". 
Should we require that sections not be left blank?


Thanks,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

[Joanna Fox via dev-security-policy]

On Monday, October 15, 2018 at 11:23:05 AM UTC-7, Kathleen Wilson wrote:
> On 10/15/18 11:01 AM, Kathleen Wilson wrote:
> > I have added the following section to the Required Practices wiki page:
> > 
> > https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#BR_Commitment_to_Comply_statement_in_CP.2FCPS
> >  
> > 
> > 
> > I will continue to appreciate feedback on this update.
> > 
> > Thanks,
> > Kathleen
> 
> 
> Oops... here's the correct link:
> 
> https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CP.2FCPS_Structured_According_to_RFC_3647

For clarification on this statement, "Any CPS that falls within the scope of 
Mozilla’s program must not use the words “No stipulation” unless the 
corresponding section in the CA/Browser Forum Baseline Requirements state “No 
stipulation”, “Not applicable”, or is blank."

Is the intent to use No stipulation”, “Not applicable”, or blank 
interchangeably?  

Thank you,
Joanna Fox
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

[Kathleen Wilson via dev-security-policy]

On 10/15/18 11:01 AM, Kathleen Wilson wrote:

I have added the following section to the Required Practices wiki page:

https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#BR_Commitment_to_Comply_statement_in_CP.2FCPS 



I will continue to appreciate feedback on this update.

Thanks,
Kathleen



Oops... here's the correct link:

https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CP.2FCPS_Structured_According_to_RFC_3647




___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

[Jakob Bohm via dev-security-policy]

On 15/10/2018 20:01, Kathleen Wilson wrote:

I have added the following section to the Required Practices wiki page:

https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#BR_Commitment_to_Comply_statement_in_CP.2FCPS



https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CP.2FCPS_Structured_According_to_RFC_3647

links directly to the edited section.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.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
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

[Kathleen Wilson via dev-security-policy]

I have added the following section to the Required Practices wiki page:

https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#BR_Commitment_to_Comply_statement_in_CP.2FCPS

I will continue to appreciate feedback on this update.

Thanks,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

[Kathleen Wilson via dev-security-policy]

On 10/15/18 12:48 AM, Pedro Fuentes wrote:

Hello,
I've a question closely related to this. I'd appreciate guidance.

I'm refactoring our CP & CPS documents considering that a CA can issue 
different types of certificates, so there would be multiple CP and one CPS.

My strategy is that if the stipulation is defined in one of the document (CP or 
CPS), then the other document can refer to the other (CPS or CP).

So, for example, as the CPS will support/implement different CP, for certain aspects (i.e. 
suspension), I'd like to refer to the CP as source, with the text "As stipulated in the 
appropriate CP". Like wise, in certain cases the stipulation could be defined in the CPS, so 
the CP would have the text "As stipulated in the CPS". This means that someone evaluating 
the practices for SSL certificates would have to consider jointly the CP of SSL certificates and 
the CPS, while someone evaluating personal certificates for email should consider the CP for S/MIME 
certificates and the CPS.

I used this in the past while writing some docs for customers... Would this be 
cross-referencing still acceptable?

Thanks,
Pedro



Yes, cross-referencing is still acceptable, as long as it is very clear 
which root certificates each CP and CPS document governs.


Thanks,
Kathleen


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

[Pedro Fuentes via dev-security-policy]

Hello,
I've a question closely related to this. I'd appreciate guidance.

I'm refactoring our CP & CPS documents considering that a CA can issue 
different types of certificates, so there would be multiple CP and one CPS. 

My strategy is that if the stipulation is defined in one of the document (CP or 
CPS), then the other document can refer to the other (CPS or CP).

So, for example, as the CPS will support/implement different CP, for certain 
aspects (i.e. suspension), I'd like to refer to the CP as source, with the text 
"As stipulated in the appropriate CP". Like wise, in certain cases the 
stipulation could be defined in the CPS, so the CP would have the text "As 
stipulated in the CPS". This means that someone evaluating the practices for 
SSL certificates would have to consider jointly the CP of SSL certificates and 
the CPS, while someone evaluating personal certificates for email should 
consider the CP for S/MIME certificates and the CPS.

I used this in the past while writing some docs for customers... Would this be 
cross-referencing still acceptable?

Thanks,
Pedro

El viernes, 12 de octubre de 2018, 2:27:49 (UTC+2), Kathleen Wilson  escribió:
> Based on the input into this discussion so far, I propose to add the 
> following section to the Required part of this wiki page:
> https://wiki.mozilla.org/CA/Required_or_Recommended_Practices
> 
> We can consider adding text about this directly to Mozilla's Root Store 
> Policy later. (I'll file the request/issue in github.)
> 
> -- Proposed Text --
> Section Heading: CP/CPS Structured According to RFC 3647
> 
> CP/CPS documents must be structured according to RFC 3647. This 
> requirement is stated in section 2.2 of the CA/Browser Forum Baseline 
> Requirements, with the effective of 31 May 2018. Further, CP/CPS 
> documents should include every component and subcomponent, and the 
> placement of information should be aligned with the BRs; e.g. domain 
> validation practices should be documented in section 3.2.2.4 of the CA’s 
> CP/CPS.
> 
> The words "No Stipulation" mean that the particular document imposes no 
> requirements related to that section.
> 
> Any CPS that falls within the scope of Mozilla’s program must not use 
> the words “No stipulation” unless the corresponding section in the 
> CA/Browser Forum Baseline Requirements state “No stipulation”, “Not 
> applicable”, or is blank. The words “Not applicable” are acceptable to 
> indicate that the CA’s policies forbid the practice that is the title of 
> the section. Language similar to “We do not perform  section>” is preferred. If a full description of a section is repeated 
> elsewhere in the document, language similar to “Refer to Section 1.2.3” 
> is preferred.
> 
> Examples:
> - If your CA does not allow a particular domain validation method to be 
> used, then the CP or CPS should say that, e.g. "This method of domain 
> validation is not used".
> - The BRs do not allow certificate suspension, so the CA’s CPS must 
> state that certificate suspension is not allowed, and then the other 
> sections related to suspension should say “Not applicable”.
> - If your CA does not issue SSL certs containing IP addresses, then 
> section 3.2.2.5, ‘Authentication for an IP Address’ in your CP or CPS 
> should say that such certificate issuance is not allowed; e.g. “No IP 
> address certificates are issued under this CPS.”
> 
> 
> I will appreciate your constructive feedback on this.
> 
> Thanks,
> Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

[Kathleen Wilson via dev-security-policy]

Based on the input into this discussion so far, I propose to add the 
following section to the Required part of this wiki page:

https://wiki.mozilla.org/CA/Required_or_Recommended_Practices

We can consider adding text about this directly to Mozilla's Root Store 
Policy later. (I'll file the request/issue in github.)


-- Proposed Text --
Section Heading: CP/CPS Structured According to RFC 3647

CP/CPS documents must be structured according to RFC 3647. This 
requirement is stated in section 2.2 of the CA/Browser Forum Baseline 
Requirements, with the effective of 31 May 2018. Further, CP/CPS 
documents should include every component and subcomponent, and the 
placement of information should be aligned with the BRs; e.g. domain 
validation practices should be documented in section 3.2.2.4 of the CA’s 
CP/CPS.


The words "No Stipulation" mean that the particular document imposes no 
requirements related to that section.


Any CPS that falls within the scope of Mozilla’s program must not use 
the words “No stipulation” unless the corresponding section in the 
CA/Browser Forum Baseline Requirements state “No stipulation”, “Not 
applicable”, or is blank. The words “Not applicable” are acceptable to 
indicate that the CA’s policies forbid the practice that is the title of 
the section. Language similar to “We do not perform section>” is preferred. If a full description of a section is repeated 
elsewhere in the document, language similar to “Refer to Section 1.2.3” 
is preferred.


Examples:
- If your CA does not allow a particular domain validation method to be 
used, then the CP or CPS should say that, e.g. "This method of domain 
validation is not used".
- The BRs do not allow certificate suspension, so the CA’s CPS must 
state that certificate suspension is not allowed, and then the other 
sections related to suspension should say “Not applicable”.
- If your CA does not issue SSL certs containing IP addresses, then 
section 3.2.2.5, ‘Authentication for an IP Address’ in your CP or CPS 
should say that such certificate issuance is not allowed; e.g. “No IP 
address certificates are issued under this CPS.”



I will appreciate your constructive feedback on this.

Thanks,
Kathleen



___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS

[Tim Hollebeek via dev-security-policy]

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 
> On Behalf Of Jakob Bohm via dev-security-policy
> Sent: Wednesday, October 10, 2018 6:09 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Cc: Jakob Bohm 
> 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 < dev-security-policy@lists.mozilla.org> 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=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 

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS

[Jakob Bohm via dev-security-policy]

On 09/10/2018 23:15, Wayne Thayer wrote:

On Tue, Oct 9, 2018 at 12:48 PM Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> 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://www.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
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS

[Wayne Thayer via dev-security-policy]

On Tue, Oct 9, 2018 at 12:48 PM Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> 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".


> 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.
> >
> >  wendy
> >
>
>
> ___
> 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

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS

[Kathleen Wilson via dev-security-policy]

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.



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.

 wendy




___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS

[Brown, Wendy (10421) via dev-security-policy]

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.

wendy



Date: Tue, 9 Oct 2018 19:02:54 +

From: Tim Hollebeek 
mailto:tim.holleb...@digicert.com>>

To: 
"dev-security-policy@lists.mozilla.org"


mailto:dev-security-policy@lists.mozilla.org>>

Subject: RE: What does "No Stipulation" mean, and when is it OK to use

it in CP/CPS?

Message-ID:


mailto:bn6pr14mb110664cd140c0a82f006afa483...@bn6pr14mb1106.namprd14.prod.outlook.com>>



Content-Type: text/plain; charset="us-ascii"



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

> mailto: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 mailto: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: 
> mailto:n5sdneed28pgrihgnz2dnuu7-fpnn...@mozilla.org>>

> Content-Type: text/plain; charset=utf-8; format=flowed

>

> All,

>

> I would 

RE: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

[Tim Hollebeek via dev-security-policy]

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

RE: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

[Brown, Wendy (10421) via dev-security-policy]

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

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

[(RS) Tyler Schroder via dev-security-policy]

The legal definition that I came acrosss is " In United States 
law, a stipulation is a formal 
legal acknowledgment and agreement made between opposing parties before a 
pending hearing or 
trial. For example, both parties 
might stipulate to certain facts and so not have to argue them in court. After 
the stipulation is entered into, it is presented to the judge." [1]


On 10/9/2018 12:48 PM, Kathleen Wilson via dev-security-policy wrote:

CAUTION: This message was sent from outside the company.


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

What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

[Kathleen Wilson via dev-security-policy]

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.




==