On Thu, October 15, 2015 12:30 pm, Kathleen Wilson wrote:
>  All,
>
>  It was previously suggested[1] that we align Mozilla's CA Certificate
>  Policy to RFC 3647, so CAs can compare their CP/CPS side-by-side with
>  Mozilla's policy, as well as the BRs and audit criteria (such as the
>  forthcoming ETSI 319 411 series).

Kathleen,

I remain incredibly dubious and skeptical of the proposed value, and thus
somewhat opposed. Though I've been a big proponent of adopting the 3647
format for the CA/Browser Forum documents, I don't believe that root store
requirements naturally fit into that form, nor should they.

I think those arguing for such a conversion have a high bar to
demonstrate, by first attempting the conversion and showing how it maps,
before we can reasonably discuss whether or not to adopt.

For example, let's just look at
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
to see how it might map.

Items 1-3 are moved to "Introduction", presumably - there's no normative
requirement.

Item 4 would almost certainly get split over several items related to the
certificate profile, except each of these are merely illustrative examples
of reasons for non-inclusion.

Item 5 has no natural counterpart.

Item 6 will end up being split across a variety of sections. This is the
one that may be the most beneficial to being in a 3647 format, but coupled
with the larger issues, it seems hard to justify.

Item 7 equally is split across multiple sections, except this is an
exhaustive list of criteria, which, compared to Item 4, is confusing
(since Item 4 is just illustrative)

Item 8 has no natural counterpart.

Item 9 ends up being split across multiple sections, making it hard to see
the sum total of the definition of "technically constrained"

Item 10 ends up most logically in a 'weird' place (document updates &
repository info)

Items 13 & 14 simply get moved to definitions, which may be seen as
non-normative.

Items 15-19 have no natural counterpart.

This is just the inclusion process. Let's also consider the ongoing
obligations (
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/maintenance/
) and realize that it ends up being, at best, maybe 50% of the
requirements having counterparts to RFC 3647, with the remainder feeling
out of place and disjoint.

I feel that those who are supportive of such a change have a burden to
demonstrate that it won't be disruptive or complex to read. It's entirely
reasonable to believe I'm totally wrong here, and I may well be - but I do
want to make sure we're working to make the requirements legible and
understandable.

_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to