Draft May 2022 CA Communication and Survey

[Ben Wilson]

All,

Please review and provide feedback on the following draft of the May 2022 CA Communication and Survey that we plan to send to CAs in the Mozilla root store: 

https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a058Z000013UmsDQAS

Thanks,

Ben

[Ben Wilson]

All,

I'm going to hit "send" on the May 2022 CA Communication and Survey this afternoon.  CA responses will be made available at https://wiki.mozilla.org/CA/Communications#May_2022_Responses.

Thanks,

Ben

[Rob Stradling]

Hi.  This is a friendly reminder about the recent Mozilla Root Store Policy update[1] that was communicated in ITEM 7 (Publicly Disclose Intermediate CA Certificates capable of Issuing TLS or SMIME...in the CCADB by July 1, 2022, even if they are technically constrained) of the May 2022 CA Communication and Survey.

Today I've updated https://crt.sh/mozilla-disclosures to bring it in line with this Policy update.

crt.sh currently knows of 40 technically-constrained CA certificates [2] that are "capable of issuing working server or email certificates" but that have not yet been disclosed to the CCADB.  Since some of these CA certificates were issued by CAs whose response to ITEM 7 was "The CCADB already contains all our CA certificates capable of issuing working server or email certificates, including those that are technically constrained" [3], I would like to encourage CA operators to take another look at this topic to ensure that their CA is compliant by the upcoming July 1^st deadline.

[1] https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#5-certificates:~:text=Name%2Dconstrained%20CA%20certificates%20that%20are%20technically%20capable%20of%20issuing%20working%20server%20or%20email%20certificates%20that%20were%20exempt%20from%20disclosure%20in%20previous%20versions%20of%20this%20policy%20MUST%20be%20disclosed%20in%20the%20CCADB%20prior%20to%20July%201%2C%202022.

[2] https://crt.sh/mozilla-disclosures#constrained

[3] https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00175,Q00176

---

From: dev-secur...@mozilla.org <dev-secur...@mozilla.org> on behalf of Ben Wilson <bwi...@mozilla.com>
Sent: 16 May 2022 21:50
To: dev-secur...@mozilla.org <dev-secur...@mozilla.org>
Subject: Re: Draft May 2022 CA Communication and Survey

 

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.

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaY8Ew-JW0k%2B5bzZc-2OGZtHQOb2J-yChCYwh0DDic59%3Dw%40mail.gmail.com.

[Dimitris Zacharopoulos]

Hi Rob,

I believe the requirement does not include the disclosure of Revoked subCAs as they are not "technically capable of issuing working server or email certificates".


Thanks,
Dimitris.

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.

[Rob Stradling]

Hi Dimitris.  IIUC, you're suggesting that revocation of a Sub-CA certificate via CRL and/or OCSP is sufficient to prevent leaf certificates from "working".  I understand why you might think this, but I don't think it's Mozilla's view.

My understanding is that Mozilla only considers a Sub-CA certificate to be fully revoked if it's included in OneCRL (or if the "parent" Sub-CA certificate(s) is/are included in OneCRL), and that Mozilla will typically only include a Sub-CA certificate in OneCRL if it has first been disclosed to CCADB as "Revoked".  AFAICT from the latest Policy, technically-constrained Sub-CA certificates and unconstrained Sub-CA certificates are now treated identically in this regard.  The implication, I think, is that leaf certificates are considered by Mozilla to be "working" unless one or more Sub-CA certificates in each potential trust chain are revoked via OneCRL.

Obviously I don't speak for Mozilla though.  🙂

Ben, Kathleen: Please could I ask one of you to clarify Mozilla's viewpoint on this matter?

---

From: Dimitris Zacharopoulos <ji...@it.auth.gr>
Sent: 24 June 2022 13:27
To: Rob Stradling <r...@sectigo.com>; dev-secur...@mozilla.org <dev-secur...@mozilla.org>

[Ben Wilson]

Hi Rob and Dimitris,

I think you're correct, but let me confirm and get back to you.

Ben

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.

[Stephen Davidson]

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.

[Buschart, Rufus]

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.

[Dimitris Zacharopoulos]

Hi Rufus,

If you can point us to the specific messages of the thread, it would be really helpful.

Thanks,

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.

[Buschart, Rufus]

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.

[Hanno Böck]

On Fri, 24 Jun 2022 15:27:23 +0300
Dimitris Zacharopoulos <ji...@it.auth.gr> wrote:

> I believe the requirement does not include the disclosure of Revoked

> subCAs as they are not /"technically capable of issuing working
> server or email certificates"/.

I would like to point out that as far as I know very few
implementations have strong revocation checks for intermediate
certificates. I remember noticing that the OCSP for the Let's Encrypt
intermediate was down, and for quite a while simply nobody noticed.

So I would very much dispute that revoked subcas are not "technically

capable of issuing working server or email certificates".

--
Hanno Böck
https://hboeck.de/

[Jeremy Rowley]

I disagree. Revocation is the industry standard for cutting off issuance capability. In addition, there is no OneCRL for non-TLS, which means there's no other option on how you can define "technically not able to issue" other than revocation. If Mozilla wants to open OneCRL for all revoked intermediates that would change things, but, right now, revocation is the only way to do this.

-----Original Message-----
From: dev-secur...@mozilla.org <dev-secur...@mozilla.org> On Behalf Of Hanno Böck
Sent: Friday, June 24, 2022 12:37 PM
To: dev-secur...@mozilla.org <dev-secur...@mozilla.org>
Subject: Re: Draft May 2022 CA Communication and Survey

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/20220624203654.34b68f20%40computer.

[Rob Stradling]

Hi Ben.  Are you able to provide an update yet?  It would be really helpful if Mozilla's interpretation of the new disclosure requirement could be made clear before that requirement comes into force on Friday!

---

From: Ben Wilson <bwi...@mozilla.com>
Sent: 24 June 2022 17:19
To: Rob Stradling <r...@sectigo.com>
Cc: Dimitris Zacharopoulos <ji...@it.auth.gr>; dev-secur...@mozilla.org <dev-secur...@mozilla.org>

[Ben Wilson]

Hi Everyone,

Section 5.3.2 of the current policy states that it applies to CAs "capable of issuing working server or email certificates". We could have made it clearer that unexpired but revoked CA certificates had to be reported in the CCADB so that they can be added to OneCRL. I have opened Issue #250 in Github [1] to amend the policy to expressly mention revoked CA certificates and the exclusion of expired CA certificates. We could also possibly remove CAs capable of issuing working email certificates, but that will require more discussion during the next policy-revision cycle. Finally, the size of some name-constrained CA certificates may be too large to submit through the current CCADB interface. If that is the case, then they can be uploaded to Bugzilla as attachments to a non-incident bug.

Do these suggestions work?

Thanks,

Ben

[1]  https://github.com/mozilla/pkipolicy/issues/250

[Jeremy Rowley]

Will the due date for these ICAs change? The requirement around revoked CAs definitely wasn’t clear. Getting everyone to upload and post by July 1 is a tight deadline.

---

From: dev-secur...@mozilla.org <dev-secur...@mozilla.org> on behalf of Ben Wilson <bwi...@mozilla.com>

Sent: Wednesday, June 29, 2022 2:35:12 PM

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.

[Jeremy Rowley]

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.

[Ben Wilson]

Agreed. This part of the Mozilla requirement -- to report previously unreported revoked and technically constrained CA certificates in the CCADB -- can be postponed until we release an update to the current policy.

However, CA operators should still be aware of Section 4 of the CCADB Policy [1]:

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.

And also Apple's policy [2]:

Effective April 1, 2022, CA providers must disclose in the CCADB all CA certificates which chain up to their CA Certificate(s) included in the Apple Root Program. 

Thanks,

Ben

[1] https://www.ccadb.org/policy#4-intermediate-certificates

[2] https://www.apple.com/certificateauthority/ca_program.html