Oscar:
The likely reason for your scans is the result of CA/Browser
Forum Ballot SC31,
https://cabforum.org/2020/07/16/ballot-sc31-browser-alignment/ ,
which was adopted as part of BRs v1.7.1. Effective 2020-09-30,
all Subscriber certificates MUST include a CA/Browser Forum
Reserved Policy OID (see Section 1.2.2 for the effective dates,
referencing Section 7.1.6.4). Given that the majority of
certificates have been issued since then, this would likely
explain your scan.
Prior to this, in BRs 1.7.0, Section 7.1.6.4 permitted CAs to use
EITHER a CA/Browser Forum reserved OID OR a CA-specified OID in
their CP/CPS. Understandably, this makes it
difficult-to-impossible for relying parties to have interoperable
confidence, hence the changes in 1.7.1 that aligned with existing
browser requirements.
In particular, prior to BRs 1.7.1, Microsoft had this as a
requirement in their root program, at https://aka.ms/rootcert.
Thus, to answer your question regarding https://crt.sh/?id=2884243786
1. If before 2020-09-30, and it contains id-kp-serverAuth and
lacks a CA/BF OID
a. It was in violation of Microsoft's root program requirements.
b. If you cannot discover in the CP/CPS in effect at the time
of issuance that the CA affirmatively states this OID complies to
the BRs or EVGs, then it was in violation of the Baseline
Requirements
2. If on-or-after 2020-09-30, and it contains id-kp-serverAuth
and lacks a CA/BF OID, it is in violation of the Baseline
Requirements
Hope that helps clarify.
The CP/CPS disclosed in CCADB is
https://www.twca.com.tw/picture/file/05271722-TWCAGLOBALCPSV13EN.pdf
, which would appear out of compliance with Mozilla's Root Store
Policy (Specifically, Policy 3.3(4) ). It's unclear if Mozilla
relies on CCADB disclosures to achieve that requirement, although
https://www.twca.com.tw/repository links
to 11061501-TWCAGLOBALCPSV13EN.pdf as their most recent CPS
(which would also be out of compliance, as best I can tell). I
double checked the CCADB disclosures for the Root,
https://crt.sh/?id=8559119 , and while they _also_ list different
versions and URLs compared to https://www.twca.com.tw/repository,
they also appear to be out of compliance.
Ignoring this failure to update issue for a second, as Ben has
highlighted, 1.3.6.1.4.1.40869.1.1.25 is disclosed as a "Device
Certificate". It's unclear if TWCA is asserting this policy OID
complies with the Baseline Requirements, given they also list
AATL-related certificates ( 1.3.6.1.4.1.40869.1.1.26 ), and
presumably the latter do not comply to the Baseline Requirements.
Thus, it's entirely possible that this certificate is misissued.
Hopefully the above steps allow you to reproduce the
investigation and reach your own determination, based on the
available facts.
On Mon, Nov 1, 2021 at 10:56 AM Ben Wilson <[email protected]>
wrote:
One of their CPSes says that Policy OID is for a "Device
Certificate" (Assurance Level 2), which is separate than a
TLS server certificate with an OID of
1.3.6.1.4.1.40869.1.1.21 (Assurance Level 3), both are very
similar, but I don't know what the distinction is between the
two types.
On Mon, Nov 1, 2021 at 7:39 AM Oscar Koeroo
<[email protected]> wrote:
Hello,
I've been doing some scanning on a few million pages and
consistently see the policy OIDs for DV, IV, OV, QWAC in
the scopes of ETSI, CA/B or others.
The certificate found on the site "https://ettoday.net"; I
can't determine the assurance policy.
Example certificate:
Subject: CN=*.ettoday.net <http://ettoday.net>,OU=RD,O=ET
New Media Holding Co.\, Ltd.,L=Taipei,ST=Taiwan,C=TW
Issuer: CN=TWCA Secure SSL Certification
Authority,OU=Secure SSL Sub-CA,O=TAIWAN-CA,C=TW
Serial number: 95559031384477517871019103745820225456
The only policy OID set is: 1.3.6.1.4.1.40869.1.1.25
['www.twca.com.tw <http://www.twca.com.tw>']
How should I qualify this certificate? Or is this a
misissuance? A clarification would be great on how to
determine this.
The OID is also not part of this quite complete list of
policy OIDs https://github.com/zmap/constants
Your guidance would be appreciated.
Kind regards,
Oscar Koeroo
--
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/f79c9a95-b07a-4f04-8a23-e228cd8f43ean%40mozilla.org
<https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/f79c9a95-b07a-4f04-8a23-e228cd8f43ean%40mozilla.org?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%2B1gtaZ_izKoqWjxEQ6k22eDw5e14PL-0Zmoz5oJn%2BgwsFBFTg%40mail.gmail.com
<https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaZ_izKoqWjxEQ6k22eDw5e14PL-0Zmoz5oJn%2BgwsFBFTg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
