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 <[email protected]> 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 > [email protected] <[email protected]> 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:* [email protected] <[email protected]> >> *On Behalf Of *Buschart, Rufus >> *Sent:* Thursday, November 18, 2021 10:03 AM >> *To:* [email protected] >> *Subject:* RE: Policy 2.8: MRSP Issue #229: Disclose Technically >> Constrained CAs in the CCADB >> >> >> >> 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] <[email protected]> >> www.twitter.com/siemens >> www.siemens.com <https://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 >> "[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 >> <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 >> "[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/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 "[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%2B1gtaZfeKT71w6K61-zNz4cMbCXQxqznSFighhMDLW5rp6vag%40mail.gmail.com.
