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

From: 'Doug Beattie' via [email protected] 
<[email protected]>
Sent: maanantai 14. maaliskuuta 2022 21.48
To: Ben Wilson <[email protected]>; [email protected] 
<[email protected]>
Subject: RE: Prioritization of Root CA Inclusion Requests

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

From: [email protected]<mailto:[email protected]> 
<[email protected]<mailto:[email protected]>> On 
Behalf Of Ben Wilson
Sent: Monday, March 14, 2022 1:17 PM
To: [email protected]<mailto:[email protected]> 
<[email protected]<mailto:[email protected]>>
Subject: Prioritization of Root CA Inclusion Requests

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

--
You received this message because you are subscribed to the Google Groups 
"[email protected]<mailto:[email protected]>" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
[email protected]<mailto:[email protected]>.
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<https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaZJsfbiDo%3DKD90Rv_LwMOive5cFiMZC7%3DHVcaigkVTdqw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups 
"[email protected]<mailto:[email protected]>" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
[email protected]<mailto:[email protected]>.
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<https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/PUZPR03MB6129902BAB45A42A2235DD5DF00F9%40PUZPR03MB6129.apcprd03.prod.outlook.com?utm_medium=email&utm_source=footer>.

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<https://www.teliacompany.com/en/about-the-company/privacy/>.


-- 
You received this message because you are subscribed to the Google Groups 
"[email protected]" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
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.

Reply via email to