Thanks Ryan. We acknowledge that you share Ryan Sleevi's concern that "modifying" our root certificates would not remediate the compliance concern. We are discussing how to move forward on this matter and expect to be able to announce an updated remediation plan in early January. We'll follow up at https://bugzilla.mozilla.org/show_bug.cgi?id=1741777.
________________________________ From: 'Ryan Dickson' via [email protected] <[email protected]> Sent: 16 December 2021 22:23 To: [email protected] <[email protected]> Cc: Rob Stradling <[email protected]>; Ben Wilson <[email protected]>; Kathleen Wilson <[email protected]>; [email protected] <[email protected]> Subject: Re: Root Replacement with digitalSignature Key Usage to Sign OCSP responses CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. [Posting on behalf of Google Chrome] Hi Rob, Modifying the certificate to include the appropriate key usage will ensure alignment with BRs Section 7.1.2.1, but it also creates an additional violation given Sectigo’s CP and CPS prohibit modification. Further, this example highlights one of the challenges associated with CA certificate modification, particularly when considering root CA certificates that cannot be revoked. Unless certificate consumers or relying party applications have a mechanism to distrust the existing certificate, it could still be used during OCSP response validation. While I do not believe this specific scenario introduces security or interoperability concerns for Chrome users or other relying parties, the “problem” still exists. As far as I can tell, there are only two paths that would avoid the introduction of additional policy violations in the process of aligning with the BRs: 1. Establish a delegated responder and stop direct OCSP signing using the CA’s key 2. Migrate to a new root with the appropriate key usage We would prefer if Sectigo committed to one of the two options above. However, in the case of GTS<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.mozilla.org%2Fshow_bug.cgi%3Fid%3D1652581&data=04%7C01%7Crob%40sectigo.com%7C4ab4e3d8c00a481615f008d9c0e2c0c9%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637752902408584966%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Q5mYBreOOAmVHto9jYNOPyQMwpk4RtaIPD7DMCysllc%3D&reserved=0>, the community established a precedent, perhaps unintentionally, that modification was an acceptable mechanism for addressing the missing key usage issue. Consequently, we are willing to accept Sectigo’s proposed path forward (i.e., modification), recognizing that: * the original violation is not fully remediated * the resolution triggers an additional CP violation that must be reported and included in a future audit report As stated in my last post, to further promote ecosystem improvement and reduce possible future confusion, we will continue exploring whether certificate modification should be prohibited long-term. We'd be happy to hear other perspectives from the community. Please let me know if you have any questions. - Ryan On Fri, Dec 10, 2021 at 5:36 PM Ryan Sleevi <[email protected]<mailto:[email protected]>> wrote: On Fri, Dec 10, 2021 at 3:12 PM Rob Stradling <[email protected]<mailto:[email protected]>> wrote: However, I'm not clear if you intended your post to also convey an opinion on Ryan Sleevi's view (expressed at https://www.mail-archive.com/[email protected]/msg00224.html<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mail-archive.com%2Fdev-security-policy%40mozilla.org%2Fmsg00224.html&data=04%7C01%7Crob%40sectigo.com%7C4ab4e3d8c00a481615f008d9c0e2c0c9%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637752902408584966%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=mjNUjtNjDqBnk%2FNAdpbCaDYy4Tqnlf%2FG2U61QyX6x5c%3D&reserved=0> and in https://bugzilla.mozilla.org/show_bug.cgi?id=1741777<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.mozilla.org%2Fshow_bug.cgi%3Fid%3D1741777&data=04%7C01%7Crob%40sectigo.com%7C4ab4e3d8c00a481615f008d9c0e2c0c9%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637752902408594941%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=NdrD8tvVCV%2FPRqj9%2FkqbuuTuYnAM1Jktf4IsoSl%2BoGw%3D&reserved=0>) that the GTS and Sectigo root replacement plans will not actually remediate the perceived non-compliance issue. Rob, I’m a bit surprised to see the verb “perceived” here; it suggests that you may not think there’s a non-compliance issue with the existing practice? I haven’t seen the final F2F minutes posted yet from the most recent CA/Browser Forum, but from both CAs and root programs, and from the bug itself, there seems to be no disagreement, except by Sectigo previously, that there is in fact a compliance issue. I’m not trying to be difficult, but I was just surprised a bit to see if phrased like that. If we accept a compliance issue, then the questions that remain is whether OCSP responses are issued by certificates, or by key pairs/subject names, and whether these alternative versions of roots are in scope. That is, the only way this solution could be remediation is either if the (new) responses are only tied to the (new) certificate, or if replacement somehow fully removes the (old) certificate from scope. It’s unclear your position on both of these. Mozilla Policy has clarified several times of doppelgängers being in scope, even explicitly within policy. Similarly, we’ve seen plenty of incidents with other CAs who have similarly understood and acknowledged the scope, and even crt.sh reports these as disclosure required, as I understand it. If the digitalSignature-less certificate is in scope, and remains in scope as transitively valid, then the only way it seems it could not be non-compliance is if an OCSP response is somehow tied to a certificate, rather than a keypair. We know a responderID byKey is tied to the shared key of both certificates, ergo the response is issued by either/or/both, and byName is tied to the subject name, which is also shared by both. Perhaps you can explain where the compliant view comes in? It’s unclear if you’re arguing doppelgängers are or should be out of scope, or if this is revisiting the earlier argument suggesting the BRs don’t actually require digitalSignature for direct signing (the legacy roots). I totally appreciate you’re looking for clarity from Ryan, but for those of us on the list (… or a beach 😅), perhaps you can articulate how you see the solution proposed complying with policy? It doesn’t seem that replacement can or should be able to declare “old” as out-of-scope, given that the whole purpose of replacing old with a doppelgänger is to keep everything signed by it valid and accepted. Just because replacement doesn’t remediate, it doesn’t shut down conversation or remove options. It just necessitates explaining and sharing more data showing the things being taken into consideration. That said, if your goal is unambiguous remediation - without having to worry about BR kremlinology or consequences - it seems rolling to a new key, as Sectigo already planned to do, is the best way to resolve that. Why wouldn’t that be an appropriate (long-term) remediation? It’s unclear if the answer from Ryan is meant to change that prioritization, and if so, why it would? -- 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]<mailto:[email protected]>. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CADEW5O94rdDGZJrQVHrQnZ0Ms2_14KRw5xLNJ%2BuUb32x4%3DK8Yw%40mail.gmail.com<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fmozilla.org%2Fd%2Fmsgid%2Fdev-security-policy%2FCADEW5O94rdDGZJrQVHrQnZ0Ms2_14KRw5xLNJ%252BuUb32x4%253DK8Yw%2540mail.gmail.com%3Futm_medium%3Demail%26utm_source%3Dfooter&data=04%7C01%7Crob%40sectigo.com%7C4ab4e3d8c00a481615f008d9c0e2c0c9%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637752902408594941%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=osHIJ2i%2BENLNhQPHXFDVUMV2v%2FaZi0SdfcsNNWEoPfU%3D&reserved=0>. -- 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/MW4PR17MB4729C5A2255BCCA803C1B811AA7D9%40MW4PR17MB4729.namprd17.prod.outlook.com.
