Intermediate CAs that have both serverauth and Emailprotection extkeyusage

[passerby184]

While reading CA/B s/mime working group email archive,

https://lists.cabforum.org/pipermail/smcwg-public/2021-June/000141.html

he found there are 21 intermediate have both emailprotection and tls server auth extended key usage, which is violation of CA/BR 7.1.2.2.g , which forbids it.

when I run the search myself, I found 51 trusted by NSS CAs that have both emailprotection and serverauth extkeyusage.

while some are cross signed root like WellsSecure Public Root Certification Authority 01 G2, but most aren't

I used this quary on censys.io to find such CAs:

• ((validation.nss.valid: true and parsed.extensions.extended_key_usage.email_protection: true) AND tags.raw: "trusted") AND parsed.extensions.basic_constraints.is_ca: true AND parsed.extensions.extended_key_usage.server_auth: True

exemple of such CA:

China Financial Certification Authority, CN=CFCA OV OCA

Camerfirma AAPP II - 2014

IdenTrust ACES CA 2

AgID CA1

DigiCert Assured ID CA-1

while most of them are old intermediate that was before SC31 (2020-june) but it doesn't have for-created-after sunseting, and for Actalis they signed new intermediate that volatile this as recently as 2020 Oct. AgID CA1

[Ryan Sleevi]

On Sat, Jun 19, 2021 at 11:32 AM passerby184 <tjt...@gmail.com> wrote:

while most of them are old intermediate that was before SC31 (2020-june) but it doesn't have for-created-after sunseting,

I’m not sure I follow. The BRs apply to newly issued certificates. They don’t retroactively invalidate certificates unless explicitly stated (e.g. when clarifying existing requirements), or when they require that _new_ certificates be issued from certificate chains that comply (which as only been done once, with respect to name chaining).

Put differently: certificates comply with the BRs at the time the cert was issued.

Does that address your concern?

Also, have you checked the Censys data is correct? I seem to recall the NSS trust bits were buggy/out of date, compared to crt.sh.

[passerby184]

There is a new enough intermediate CA certificate that signed after BR change(2020 Oct)  AgID CA 1(https://crt.sh/?id=3517096458&opt=ocsp)

from Actalis Authentication Root CA, while it's name constrained EKU rule still apply.

and this site uses that CA.

https://peppol-smp.agid.gov.it/public,

2021년 6월 20일 일요일 오후 1시 12분 7초 UTC+9에 Ryan Sleevi님이 작성:

[Ryan Sleevi]

Yes, this appears to be a repeat issue with Actalis. I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=1717357 for this - you should feel free to report such bugs directly to the CA or through filing an Incident Report - https://wiki.mozilla.org/CA/Responding_To_An_Incident

[Rob Stradling]

I just ran a query on the crt.sh DB that looked for any other intermediate certificates that don't (or potentially don't) comply with Section 5.3 of the Mozilla Root Store Policy.  See https://gist.github.com/robstradling/a34393f6e81639099c201a032db84853 for the query and the results (40 intermediate certificates).

Since intermediate certificates can be (and sometimes are) backdated, it's hard to programmatically verify "created after January 1, 2019".  And since there's also no requirement that intermediate certificates be logged to CT, looking at earliest SCT timestamps wouldn't work either.  So, relying on the fact that crt.sh IDs are allocated sequentially, I've erred on the side of false positives(*) rather than false negatives by filtering out only those crt.sh IDs that were definitely known to crt.sh before Jan 1st 2019.

I haven't filtered out from the result set those intermediate certificates that have already had Bugzilla bugs filed against them for this type of non-compliance (e.g., https://bugzilla.mozilla.org/show_bug.cgi?id=1586795), and so I haven't got as far as reporting any newly discovered non-compliances to the affected CAs or to Bugzilla.  (I'm kinda hoping that someone with more free time than I have will read this post and do something with the result set 😉 ).

(*) Some of these intermediate certificates belong to CAs that (IIRC) first became trusted by Mozilla after January 1, 2019.  Therefore, it's no surprise that crt.sh didn't become aware of these intermediate certificates until after that date, even though they were probably (although not programmatically provably) issued before January 1, 2019.

---

From: dev-secur...@mozilla.org <dev-secur...@mozilla.org> on behalf of Ryan Sleevi <ry...@sleevi.com>
Sent: 20 June 2021 18:08
To: passerby184 <tjt...@gmail.com>
Cc: dev-secur...@mozilla.org <dev-secur...@mozilla.org>; Ryan Sleevi <ry...@sleevi.com>
Subject: Re: Intermediate CAs that have both serverauth and Emailprotection extkeyusage

 

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/CAErg%3DHHni_L2oyWB7aeTp0tAbd6-PAMZVqGhmft4yTUA38To7g%40mail.gmail.com.

[Jeremy Rowley]

Looking through this and it looks like several are revoked. Is there a way to filter out revoked?

 

Examples:

Actalis Extended Validation Server CA G2

ABB Intermediate CA 3

NETLOCK Trust EV CA 2

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/MW4PR17MB4729E654019ABA4938172550AA069%40MW4PR17MB4729.namprd17.prod.outlook.com.

[Ryan Sleevi]

Via OneCRL or via the CRL? Either/or, or both? :)

[Rob Stradling]

If a certificate happens to be revoked before a non-compliance in that certificate is discovered, is it therefore "not an incident" when the non-compliance is discovered?  I didn't think this was the case, which is why I deliberately omitted CRL and OneCRL statuses from my report (even though crt.sh has this  revocation information readily available).

---

From: Ryan Sleevi <ry...@sleevi.com>
Sent: 25 June 2021 22:14
To: Jeremy Rowley <jeremy...@digicert.com>
Cc: Rob Stradling <r...@sectigo.com>; dev-secur...@mozilla.org <dev-secur...@mozilla.org>; ry...@sleevi.com <ry...@sleevi.com>; passerby184 <tjt...@gmail.com>

Subject: Re: Intermediate CAs that have both serverauth and Emailprotection extkeyusage

 

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.

[Jeremy Rowley]

Both revocation and the CAB forum ballot changing the EKU requirement have effective dates.  The effective date of the EKU change at CAB was Sep 2020 (SC31).  You can pretty quickly eliminate the number of  potentially bad ICAs by comparing those two dates. For example, Netlock shows a revocation date of June 2020. Even if it was issued the day before revocation, there still wouldn’t be a CAB Forum issue as the revocation date predates the effective date of the ballot.

 

I think the backdating of ICAs by years is pretty rare though. The Sectigo ICA is the only one I’m aware of that did this. Were there more? Should be pretty easy to determine from the CCADB upload compared to the notBefore date.

 

Since this is MDSP, the revocation date should be the date added to OneCRL as that’s the Mozilla requirement.

 

Jeremy