To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/MW4PR17MB4729D9ABE96ABF0BD80990C6AAB49%40MW4PR17MB4729.namprd17.prod.outlook.com.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/MW4PR17MB47299ECF1CC5C8E7C98431E3AAB49%40MW4PR17MB4729.namprd17.prod.outlook.com.
Hello:
I agree with Dimitris. The CAs I am familiar with on your list were revoked before there was a requirement for them to be disclosed in CCADB, and in any case do not have remaining leaf certificates within their respective validity periods. In short, the CAs are not capable of issuing working certs today, and none of their previous leaf certs should be working.
Also, a number of those CAs are email. Is oneCRL used for non-TLS?
It would be helpful for a policy clarification if there is a new requirement to report ICAs that were discontinued before the respective CCADB requirements. It is potentially a large number of CAs.
Regards, Stephen
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/c939f05d-1da2-471c-7b32-9cc423e14d3a%40it.auth.gr.
Hi!
Remembering the discussion while creating this policy sentence, I think it was never the intend to include expired or revoked ICAs in CCADB.
/Rufus
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/BL1PR14MB5143238208925BBDB2B6F61CE5B49%40BL1PR14MB5143.namprd14.prod.outlook.com.
DZ.
Jun 24, 2022 21:13:05 Buschart, Rufus <rufus.b...@siemens.com>:
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/AM8PR10MB46584E0DF31EA236798FBC569EB49%40AM8PR10MB4658.EURPRD10.PROD.OUTLOOK.COM.
Hi Dimitris,
well, I’ve opened the Pull Request that introduced this sentence to the policy and it was not my intention. Disclose also TCSC to CCADB by RufusJWB · Pull Request #229 · mozilla/pkipolicy (github.com) . But you are right, it was never explicitly stated in the discussion.
/Rufus
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/f21532a0-d395-4d28-ae46-5a3494623924%40it.auth.gr.
One other note Ben is that section 1.1 puts revoked ICAs outside of the policy. There probably should be a community discussion and review before this policy changes
1.1 Scope
This policy applies, as appropriate, to certificates matching any of the following (and to the CA operators* that control or issue them):
1. CA certificates included in, or under consideration for inclusion in, the Mozilla root store;
2. intermediate certificates that have at least one valid, unrevoked chain up to such a CA certificate and that are technically capable of issuing working server or email certificates. Intermediate certificates that are not considered to be technically capable will contain either:
Given this is now bringing all revoked intermediates into scope, would this be better set for a 2.8.1 update to change the scope language?
Jeremy
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtabRUYuscZiz9Sp1X%3DQdY0tj606U_--gtdm6NPvGHhny0Q%40mail.gmail.com.
An intermediate certificate is a certificate capable of issuing new certificates that is not a root certificate. To determine which intermediate certificates must be entered into the CCADB, refer to the individual Store policy documents. This includes certificates that are revoked. For newly-created intermediate certificates, this must happen before the certificate begins issuing publicly-trusted certificates. ... If an intermediate certificate is revoked, the CCADB must be updated to mark it as revoked, giving the reason why, within 24 hours for a security incident, and within 7 days for any other reason.