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,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'] >> >> 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> > . > -- 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/CAErg%3DHGkar_gbsXaNhag9FpmpMHj%3DsOedzM-4ec0ev7hVNSoEQ%40mail.gmail.com.
