Prioritization of Root CA Inclusion Requests

[Ben Wilson]

All,

I am considering tweaking the prioritization criteria for inclusion requests to prioritize applicants who have been previously approved as externally operated intermediate CAs (and that are then requesting direct inclusion).

So https://wiki.mozilla.org/CA/Prioritization would be updated. For example,

"P1 = High (Applicant has good compliance history and is replacing an already-included CA certificate)"
could become
"P1 = High (Applicant has good compliance history and is replacing an already-included CA certificate or is previously approved as a subordinate CA operator)"

"3 - Replacing Existing (Existing CA operators that are replacing an already-included root certificate) https://wiki.mozilla.org/CA/Certificate_Change_Process "
could become
"3 - Replacing Existing (Existing CA operators that are replacing an already-included root certificate, https://wiki.mozilla.org/CA/Certificate_Change_Process, or is a previously approved subordinate CA operator who is requesting direct inclusion) "

I was also thinking that applications that only seek enablement of the email trust bit should be prioritized because the level of effort and due diligence to review those roots aren't as great as with those seeking enablement of the websites trust bit.  I haven't developed language yet on how to prioritize SMIME-only roots.  For instance, I might amend "5 - Single-Purpose, Separate Roots (Hierarchies that are separated by root for a particular purpose)" to address SMIME-only roots specifically.

Thoughts?

Ben

[Doug Beattie]

Hi Ben,

 

Anything you can do to speed up/optimize the process and encourage CAs to roll out different roots for different purposes (TLS only Root, Email only Root, etc.), and to encourage more frequent roll-overs would be a good thing and you might get more adoption of that philosophy.  I don’t know the list of factors is in order of importance, but if so, the moving #5 up might encourage more CAs to create roots dedicated for a single purpose.  It certainly belongs ahead of #3.

 

Doug

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaZJsfbiDo%3DKD90Rv_LwMOive5cFiMZC7%3DHVcaigkVTdqw%40mail.gmail.com.

[Cynthia Revström]

Hi Ben,

To me personally it would make the most sense if these requests would
be classed as high priority but not as high as replacing an
already-included cert.
So like P1.5/a new P2, I am not sure how much practical difference
this would make and if it is not a lot, then it is probably fine to
just add it to P1.

My thinking here is kinda that no real change in structure of CAs
should be higher (or equal) priority than replacing an
already-included CA cert.

I will admit that I am not overly familiar with the details of this
process and these are just my initial thoughts so take this input with
a grain of salt.

-Cynthia

[Lahtiharju, Pekka]

Hi Doug,

 

Is the described multi-root schema (different roots for different purposes) some kind of new best practice for CAs? So far Telia has used only one root for all purposes but should we now change that policy and start applications with several new roots? What is the reason for multi-root schema? Note! Some root programs like Oracle have specified that one member may have maximum three roots in their systems.

 

Best Regards

Pekka

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/PUZPR03MB6129902BAB45A42A2235DD5DF00F9%40PUZPR03MB6129.apcprd03.prod.outlook.com.

This email may contain information which is privileged or protected against unauthorized disclosure or communication. If you are not the intended recipient, please notify the sender and delete this message and any attachments from your system without producing, distributing or retaining copies thereof or disclosing its contents to any other person.

Telia Company processes emails and other files that may contain personal data in accordance with Telia Company’s Privacy Policy.

[Moudrick M. Dadashov]

Good day,

"So far Telia has used only one root for all purposes but should we now change that policy and start applications with several new roots?"

See, the problem here is with "Telia", which, unlike any other well known names (e.g. Oracle Corporation), is widely misused.

As disucussed earlier, the fact that Telia Company AB (https://www.telia.se) owns Telia Finland Oyj (https://www.telia.fi) doesn't mean the trust between these independant legal entities (PKI participants) can be shared or is transferable. 

Thanks,

M.D.

Sent from my Galaxy

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/HE1PR07MB32124BB1DE01CAC78776CB3CE1109%40HE1PR07MB3212.eurprd07.prod.outlook.com.

[Ryan Sleevi]

On Tue, Mar 15, 2022 at 3:06 AM Lahtiharju, Pekka <pekka.la...@teliacompany.com> wrote:

Hi Doug,

 

Is the described multi-root schema (different roots for different purposes) some kind of new best practice for CAs? So far Telia has used only one root for all purposes but should we now change that policy and start applications with several new roots? What is the reason for multi-root schema? Note! Some root programs like Oracle have specified that one member may have maximum three roots in their systems.

Yes, it’s been recommended for several years now, both in response to numerous CA incidents and explicitly by the Chrome Root Program ( https://g.co/chrome/root-policy ), discussed at the CA/Browser Forum F2F 52 - 

https://cabforum.org/2021/04/01/minutes-of-the-ca-browser-forum-f2f-meeting-52-virtual-3-4-march-2021/#Google-Root-Program-Update

The slides also demonstrate how you can structure your hierarchy to satisfy both separate roots and, for legacy root stores that limit the number of included CAs, multipurpose roots. I use the term “legacy” because other root programs that have had limits (e.g. Microsoft and Apple, at various points), have generally in practice relaxed or removed those limits to support algorithm diversity and purpose separation.

[Ben Wilson]

All,

I've re-ordered the factors to emphasize (prioritize) CAs that are proposing separate roots. I also added to the lists "previously approved" "subordinate CA operator" - for those CA operators that have been through the public-review-and-discussion process. See https://wiki.mozilla.org/CA/Prioritization.

Ben