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 -------- Original message --------From: "Lahtiharju, Pekka" <[email protected]> Date: 3/15/22 09:06 (GMT+02:00) To: Doug Beattie <[email protected]>, [email protected] Cc: Ben Wilson <[email protected]> Subject: RE: Prioritization of Root CA Inclusion Requests
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] <[email protected]> On Behalf Of Ben Wilson Sent: Monday, March 14, 2022 1:17 PM To: [email protected] <[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]" 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/CA%2B1gtaZJsfbiDo%3DKD90Rv_LwMOive5cFiMZC7%3DHVcaigkVTdqw%40mail.gmail.com. -- 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/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. -- 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. -- 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/E1nU54D-0006iW-Ou%40submission01.runbox.
