Hello! Please find my comments inline.
From: [email protected] <[email protected]> On Behalf Of Kathleen Wilson Sent: Dienstag, 16. November 2021 00:24 To: [email protected] Subject: Re: Policy 2.8: MRSP Issue #229: Disclose Technically Constrained CAs in the CCADB On Monday, November 15, 2021 at 11:40:58 AM UTC-8 Kathleen Wilson wrote: I feel like this item needs to be further discussed... 1) section 1.1 of Mozilla's Root Store Policy (MRSP)<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mozilla.org%2Fen-US%2Fabout%2Fgovernance%2Fpolicies%2Fsecurity-group%2Fcerts%2Fpolicy%2F%2311-scope&data=04%7C01%7Crufus.buschart%40siemens.com%7C8e694116e6a141e74e6e08d9a88ef7ca%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637726154263132716%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=AYJ3nbJyx0S4XpgxjqMOW4BUMjduSaWycRkrIBHumvw%3D&reserved=0> limits the scope of the policy to "intermediate certificates which are technically capable of issuing working server or email certificates". So my understanding is that the proposed changes would mean that all intermediate certificates which are technically capable of issuing working server or email certificates must be disclosed in the CCADB, even if they are name constrained. And the proposed changes would NOT mean that intermediate certificates would need to be disclosed in the CCADB when they contain an Extended Key Usage (EKU) extension which does not contain any of these KeyPurposeIds: anyExtendedKeyUsage, id-kp-serverAuth, id-kp-emailProtection. Correct? [>] This was at least my original intention 2) Just wondering... How do you all think that requiring disclosure of technically-constrained intermediate certs in the CCADB improves security for end-users? [>] In my opinion, we will get a much better transparency what is there out in the field. Currently there is a big, big unknown. And this risky since these name-constrained CAs are not externally audited but only undergo sample testing acc. BR 8.7. last two sentences. I have made an attempt to address this further with some commits in my GitHub repository: https://github.com/mozilla/pkipolicy/compare/1829373903c8d58246c781ee11ea77d6d386985a...e6550dba22ed38ac6bdd33677a8bf3d2f00e75de<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fpkipolicy%2Fcompare%2F1829373903c8d58246c781ee11ea77d6d386985a...e6550dba22ed38ac6bdd33677a8bf3d2f00e75de&data=04%7C01%7Crufus.buschart%40siemens.com%7C8e694116e6a141e74e6e08d9a88ef7ca%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637726154263132716%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=TpOCo%2Bh6fPISeRwIswYMycbkj72%2FHAgJSm1z8QWr6wM%3D&reserved=0> 3) regarding the proposed change in the first paragraph of section 5.3 from "Certificate Program MUST be operated in accordance with this policy and MUST either be technically constrained or be publicly disclosed and audited." to "Certificate Program MUST be operated in accordance with this policy and MUST either be technically constrained or be audited." My interpretation of the original sentence was: "MUST either be technically constrained or (be publicly disclosed and audited)." meaning that 3rd-party audit statements would have to be provided. I do NOT interpret it as meaning that technically-constrained intermediate certificates do not have to be audited at all. The BRs provide specific requirements for the oversight of technically-constrained intermediate certificates that I view as the minimum oversight that should be done for such intermediate certificates. [>] Yes, but the minimum oversight is slim: assess the adherence to the CP/CPS and perform a sample testing on the issued certificates Therefore, I think that first paragraph should be changed to: All certificates that are capable of being used to issue new certificates which are technically capable of issuing working server or email certificates and that directly or transitively chain to a CA certificate included in Mozilla’s CA Certificate Program MUST be operated in accordance with this policy and MUST be publicly disclosed in the CCADB. [>] 👍🏻 With best regards, Rufus Buschart Siemens AG Information Technology Infrastructure Technical Solution & Service Quality 1 IT IN COR TSQ-1 Freyeslebenstr. 1 91058 Erlangen, Germany Tel.: +49 1522 2894134 mailto:[email protected] www.twitter.com/siemens<http://www.twitter.com/siemens> www.siemens.com<https://siemens.com> [cid:[email protected]] Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann Snabe; Managing Board: Roland Busch, Chairman, President and Chief Executive Officer; Cedrik Neike, Matthias Rebellius, Ralf P. Thomas, Judith Wiese; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin-Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322 -- 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/AM8PR10MB4305FC5A57B9BDE2FD5B31189E9B9%40AM8PR10MB4305.EURPRD10.PROD.OUTLOOK.COM.
