One more issue to clarify is what happens during the SubCA renewal
process (and what "renewal" means), or issuance of another subCA to an
organization that has already been approved for the same certificate
type (server or email) and class (EV or not for server certificates).
Is it necessary to start a new discussion every time a new CA
Certificate is about to be issued for that same type and class, or not ?
Ben, would it make sense to add a new section to address this issue so
there is no confusion?
Also, where would the information about the unconstrained external
SubCAs that have passed public discussion and have been approved or
denied be located?
Thanks,
Dimitris.
On 11/11/2021 3:21 μ.μ., 'Corey Bonnell' via
dev-security-policy@mozilla.org wrote:
Hi Ben,
I think the expectation can be clarified by amending the paragraph
starting with “The process outlined herein applies to subCA operators
not already in the Mozilla root program”. I suggest explicitly
mentioning the three different types of trust, namely Email, (non-EV)
Websites, and EV Websites and requiring the process be followed
whenever an organization is to receive a subCA certificate that grants
one or more of those technical capabilities that the organization did
not have in the Mozilla root program. As a concrete proposal:
“The process outlined herein applies to organizations that do not
control a Root or subCA certificate trusted by the Mozilla root
program. Additionally, the process outlined herein applies to
organizations that control a subCA or Root CA certificate in Mozilla’s
root program but the new subCA certificate will grant technical
capability for the issuance of additional types of certificates.
Specifically, the process outlined herein MUST be followed when an
organization does not control a subCA or Root CA certificate that
grants capability to issue certificates of one or more of the
following types and the new subCA certificate will grant such
capability: S/MIME (Email trust bit), (DV/IV/OV) TLS Server
Authentication (Websites trust bit), and/or EV TLS Server
Authentication (Websites trust bit with EV-enablement).”
Thanks,
Corey
*From:* Ben Wilson <bwil...@mozilla.com>
*Sent:* Wednesday, November 10, 2021 5:46 PM
*To:* Corey Bonnell <corey.bonn...@digicert.com>
*Cc:* dev-secur...@mozilla.org <dev-security-policy@mozilla.org>
*Subject:* Re: Policy 2.8: MRSP Issue #233: Wiki page documenting
process for reviewing externally operated subordinate CAs
Hi Corey,
I think I'll disagree with your conclusion that there is no need to
perform a review of Sub CA B for issuance of a new intermediate
certificate to it with the serverAuth EKU.
Let's assume that Root CA A already has both the websites bit and the
email bit enabled by Mozilla. And assume that the review-and-comment
process for Sub CA B focused only on the enablement of that CA for
S/MIME certificate issuance. What if there had not been a thorough
review of Sub CA B's Compliance Self Assessment (Required
Documentation
<https://wiki.mozilla.org/CA/Subordinate_CA_Checklist#Required_Documentation>
#6) because much of the assessment applies only to server certificate
issuance (i.e. what if the assessment had been filled with a lot of
"N/A"s)? Then, the prior public discussion was insufficient.("Prior to
public discussion, the root CA operator must confirm that it has
verified all of the following information, which must be provided when
the root CA operator starts the public discussion.")
However, all of this might be different if the review of Sub CA B was
thorough enough to cover server certificate issuance.
I suppose I can make that more clear on the wiki page. I also welcome
any suggestions.
Thanks,
Ben
On Tue, Nov 9, 2021 at 3:30 PM Corey Bonnell
<corey.bonn...@digicert.com> wrote:
Hi Ben,
A scenario came to mind that may deserve further clarity in the
text, so I wanted to raise it here. Suppose Root CA “A” kicks off
the information-gathering and review process for Sub CA “B” (as
outlined on the Wiki page) for the issuance of a subordinate CA
certificate containing solely id-kp-emailProtection. The
discussion ends favorably and Sub CA B is marked in CCADB as an
“approved” organization. Some time later, Sub CA B wishes to
obtain a subordinate certificate containing id-kp-serverAuth.
Since this organization has previously been approved, according to
the proposed language, there is no need to undergo the review and
approval process again despite the difference in technical
capability and audit requirements of the subordinate CAs.
Is this an accurate read of the proposed language?
Thanks,
Corey
*From:* dev-security-policy@mozilla.org
<dev-security-policy@mozilla.org> *On Behalf Of *Ben Wilson
*Sent:* Monday, November 1, 2021 2:58 PM
*To:* dev-secur...@mozilla.org <dev-security-policy@mozilla.org>
*Subject:* Re: Policy 2.8: MRSP Issue #233: Wiki page documenting
process for reviewing externally operated subordinate CAs
I am proposing that we create a link in the MRSP to the process
for review and approval of third-party externally operated CAs as
indicated in the following commit:
https://github.com/BenWilson-Mozilla/pkipolicy/commit/9efa9e73f6cff7924d1ed856eadd1902f31bd458
On Thu, Oct 28, 2021 at 2:56 PM Ben Wilson <bwil...@mozilla.com>
wrote:
All,
This email introduces another issue selected to be addressed
in the next version of the Mozilla Root Store Policy (MSRP),
version 2.8, to be published in 2022. (See
https://github.com/mozilla/pkipolicy/labels/2.8
<https://github.com/mozilla/pkipolicy/labels/2.8>)
This is Github Issue #233
<https://github.com/mozilla/pkipolicy/issues/233>.
I have re-published the wiki page for the process of reviewing
and approving externally operated subordinate CAs. Here is
the URL:
https://wiki.mozilla.org/CA/Subordinate_CA_Checklist#Process_for_Review_and_Approval_of_Externally_Operated_Subordinate_CAs
This issue is also related to an m.d.s.p. email that I sent
and comments received with a subject line: Process for
Considering Externally Operated Subordinate CAs
<https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/AA5G1bzOwZQ/m/v4i0_wj9BAAJ>.
Please provide any additional comments you may have regarding
the review and approval process for externally operated
subordinate CAs.
Thanks,
Ben Wilson
Mozilla Root Program Manager
--
You received this message because you are subscribed to the Google
Groups "dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to dev-security-policy+unsubscr...@mozilla.org.
To view this discussion on the web visit
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaZX%2B_vWSyZe2tMGREjurRRV7y66AVMQyLkPz8LE4BbsUw%40mail.gmail.com
<https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaZX%2B_vWSyZe2tMGREjurRRV7y66AVMQyLkPz8LE4BbsUw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google
Groups "dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to dev-security-policy+unsubscr...@mozilla.org.
To view this discussion on the web visit
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/DM6PR14MB2186D6FBA3B3CC7FD7EAF7C492949%40DM6PR14MB2186.namprd14.prod.outlook.com
<https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/DM6PR14MB2186D6FBA3B3CC7FD7EAF7C492949%40DM6PR14MB2186.namprd14.prod.outlook.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups
"dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to dev-security-policy+unsubscr...@mozilla.org.
To view this discussion on the web visit
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/22757e0a-bfa8-211e-0149-d144c2ab804a%40it.auth.gr.
