Hi Ben, I think it would be best if there were a rigorous definition of “functional”, similar to the language that was introduced in v2.7 to define “capable” for ICA certificates. Concretely:
“A certificate is deemed as functional if there exists at least one certification path that includes the certificate and where all certificates in the path are in scope as defined in Section 1.1 of this Policy”. As an aside, it appears that a requirement to audit TCSCs was included in the commit from two days ago: https://github.com/BenWilson-Mozilla/pkipolicy/commit/7a22e6b935b3da72e419b91f2be9951fb3871406#diff-73f95f7d2475645ef6fc93f65ddd9679d66efa9834e4ce415a2bf79a16a7cdb6R617. Was this intentional? Thanks, Corey From: dev-security-policy@mozilla.org <dev-security-policy@mozilla.org> On Behalf Of Ben Wilson Sent: Wednesday, February 9, 2022 6:51 PM To: Tim Hollebeek <tim.holleb...@digicert.com> Cc: Buschart, Rufus <rufus.busch...@siemens.com>; dev-security-policy@mozilla.org Subject: Re: Policy 2.8: MRSP Issue #229: Disclose Technically Constrained CAs in the CCADB Alternatively, we could replace "working" with "fully functional" or "operational". Another adjective that might be possible is "compliant" as in "compliant server certificates", but I wouldn't want to encourage the issuance of non-compliant server or email certificates. On Wed, Feb 9, 2022 at 4:19 PM Ben Wilson <bwil...@mozilla.com <mailto:bwil...@mozilla.com> > wrote: Elsewhere in the Policy, we use the phrases "certificate capable of being used for TLS [server authentication] ..." and "certificate capable of being used for digitally signing or encrypting email messages". Are those better? Thanks, Ben On Wed, Feb 9, 2022 at 2:20 PM 'Tim Hollebeek' via dev-security-policy@mozilla.org <mailto:dev-security-policy@mozilla.org> <dev-security-policy@mozilla.org <mailto:dev-security-policy@mozilla.org> > wrote: Just a minor nit: It’s not clear to me what the word “working” means in “working server or email certificates”. It would be better if it were expressed in technical language so CAs know how to determine whether a particular certificate “works” or not. -Tim From: dev-security-policy@mozilla.org <mailto:dev-security-policy@mozilla.org> <dev-security-policy@mozilla.org <mailto:dev-security-policy@mozilla.org> > On Behalf Of Buschart, Rufus Sent: Thursday, November 18, 2021 10:03 AM To: dev-security-policy@mozilla.org <mailto:dev-security-policy@mozilla.org> Subject: RE: Policy 2.8: MRSP Issue #229: Disclose Technically Constrained CAs in the CCADB Hello! Please find my comments inline. From: dev-security-policy@mozilla.org <mailto:dev-security-policy@mozilla.org> <dev-security-policy@mozilla.org> On Behalf Of Kathleen Wilson Sent: Dienstag, 16. November 2021 00:24 To: dev-security-policy@mozilla.org <mailto:dev-security-policy@mozilla.org> 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:rufus.busch...@siemens.com> mailto:rufus.busch...@siemens.com <http://www.twitter.com/siemens> www.twitter.com/siemens <https://siemens.com> www.siemens.com 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 "dev-security-policy@mozilla.org <mailto:dev-security-policy@mozilla.org> " group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org <mailto:dev-security-policy+unsubscr...@mozilla.org> . 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 <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/AM8PR10MB4305FC5A57B9BDE2FD5B31189E9B9%40AM8PR10MB4305.EURPRD10.PROD.OUTLOOK.COM?utm_medium=email&utm_source=footer> . -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org <mailto:dev-security-policy@mozilla.org> " group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org <mailto:dev-security-policy+unsubscr...@mozilla.org> . To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/DM8PR14MB52371E2C0CF8FC025D9DC75F832E9%40DM8PR14MB5237.namprd14.prod.outlook.com <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/DM8PR14MB52371E2C0CF8FC025D9DC75F832E9%40DM8PR14MB5237.namprd14.prod.outlook.com?utm_medium=email&utm_source=footer> . -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org <mailto:dev-security-policy@mozilla.org> " group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org <mailto:dev-security-policy+unsubscr...@mozilla.org> . To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaZfeKT71w6K61-zNz4cMbCXQxqznSFighhMDLW5rp6vag%40mail.gmail.com <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaZfeKT71w6K61-zNz4cMbCXQxqznSFighhMDLW5rp6vag%40mail.gmail.com?utm_medium=email&utm_source=footer> . -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/DM6PR14MB2186B586F54D91B075273D81922F9%40DM6PR14MB2186.namprd14.prod.outlook.com.
smime.p7s
Description: S/MIME cryptographic signature
