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
