Hi Ryan,
Sorry for not addressing all of the concerns you raised in the first response. Regarding the policy OID issue, your analysis is correct. We completed the transition to including BR OID in all TLS server certificates on 2020-07-16, so before that date not all certificates include BR OID. The certificates without BR OID were indeed in violation of Microsoft’s root program requirements. All certificates issued after the transition date (and the effective date of OID requirement from BR 1.7.1) include BR OID and are not in violation of the Baseline Requirements. Regarding the CP/CPS, the most recent CP/CPS are the “Draft” ones (v1.6 for Global CA CPS) on https://www.twca.com.tw/repository?lang=en which have effective date of 2021-05-04. The draft status is due to the lengthy approval process (which is actually still in progress for this version) required by Taiwan Electronic Signature Act. The CP/CPS listed in the Root CA records on CCADB were submitted with the annual audit reports and were up-to-date for the audit period. For the different versions listed in the intermediate CA records, we thought they should have been updated by the audit report case but just realized that ”CP/CPS Same as Parent” is not checked. I have updated the intermediate CA records and will file an update request to CCADB for the Root CA records. We have also been working on releasing new CP/CPS more frequently. Our current CP/CPS covers both TLS server certificates and certificates for other applications like AATL certificate you mentioned. In these certificate types only “TLS / SSL Certificate” and “Device Certificate” have the id-kp-serverAuth and are subjected to compliance with the Baseline Requirements. Although it is indeed confusing from the naming, but the requirements for “TLS / SSL Certificate” and “Device Certificate”, for example, the description of the identity authentication process (3.2.2), are the same in the CP/CPS. The name “Device Certificate” was originally intended for devices with embedded web server (e.g. NAS) and are distinguished at the business level, thus the different assurance levels in the CP/CPS. But then because they are both TLS server certificates by definition of the Baseline Requirements and root program requirements, we do not really distinguished between these two types of certificate. To avoid confusion, we are planning to combine them into only “TLS / SSL Certificate” in future version of CP/CPS. Hope above clarifies your concerns. Do you think we should also post these to Bugzilla, and for which part we should file an incident report? Pease tell us if you have any further questions. Thanks, Hao-Chun Li Ryan Sleevi 在 2021年11月2日 星期二上午1:21:20 [UTC+8] 的信中寫道： > 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 <bwi...@mozilla.com> 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 <oko...@gmail.com> 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 "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/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 >> "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%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 "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/ddccb555-d776-46bd-9631-32b1b6f97c45n%40mozilla.org.
