I've reached to the auditor (in this case, TUVIT) to understand why they failed to detect this major non-conformity.
Now that I'm back in the states, following the CA/Browser Forum F2F, I've had a chance to look more closely at the set of CAs that have issued. This is not a full lint check - I've only included certificates I can minimally parse as correct in these extensions. In addition to T-Systems, it appears Certinomis, ComSign, and MULTICERT have similarly taken to misencoding. In the case of Certinomis, an example certificate is https://crt.sh/?q=38d025ffe77ac1cd2142764fce4fb5fc619e5da536b3adac6904036f40addf80 Although it includes a qcStatements, it includes an OID of 0.4.0.1.6, which is not valid for purpose, with the id-etsi-qct-web extension. It appears that the "1" is most likely a typo for the full id-etsi-qcs, which is that of 0.4.0.1862.1.6 - that is, they omitted the 1862 arc. They properly encode the id-etsi-qcs-QcPDS with its QcLocations. However, they do not assert compliance with the ETSI EN 319 412-5 profile (that is, OID "0.4.0.1862.1.1" is not asserted), so this is a semantic misencoding but not clearly a violation of the asserted profile. In the case of ComSign, an example certificate is https://crt.sh/?q=2d5a2596f315ba823758b2a0380de1e0e9cc22d6e045abe45e1cd7fb2c5fe01e This one is a hot mess of improper encoding, probably best captured by pointing out the misencoding of RFC 3739's SemanticsInformation from qcStatement-1 (OID "1.3.6.1.5.5.7.11.1") and the inclusion of an unassigned ETSI OID ("0.4.0.1862.11.1") that appears to be combining these two. However, Mozilla has already made a decision about ComSign going forward. In the case of MULTICERT, they're trusted transitively by AC Camerfirma in https://crt.sh/?id=573264407 , which is valid for SSL in Mozilla, and an example cert is https://crt.sh/?q=5bada9c841242c13c035496d5668d4a59cb91bb839e9e625a9c63c0e687269ab In this certificate, they completely botched the syntax, treating "0.4.0.1862.1.6.3" as permitting an optional UTF8String message, which states "Certificate for website authentication as defined in Regulation (EU) No 910/2014" MULTICERT is the most interesting of these. AC Camerfirma has claimed in Salesforce that the audits are the same as the parent - however, this does not seem to be met by https://bug1478933.bmoattachments.org/attachment.cgi?id=8995930 , which is the disclosed audit for the AC Camerfirma roots (by Auren). Auren's audit is dated July 14, 2018 and covers the period up to April 13, 2018. The cross-certificates were issued on Jun 29, 2018 ( https://crt.sh/?id=568548659 ) and Jul 3, 2018 ( https://crt.sh/?id=573264407 ), the former being revoked, the latter, not. I find this questionable and suspicious, because MULTICERT also operates its own root (within the Microsoft program), yet no audit information has been provided (by Microsoft or MULTICERT). The closest I've found is https://bugzilla.mozilla.org/show_bug.cgi?id=1433320 , which was provided by DigiCert because of https://crt.sh/?caid=1013 . Based on this, I believe that the most likely result is that AC Camerfirma has potentially mislead the community about the state of the audits - or that the misissuing MULTICERT Sub-CA has been audited multiple times (by both Auren and by APCER, which seems unlikely). As a result, it appears we have one clear misissuance by a CA in Mozilla's program - MULTICERT - and a potential issue with the auditor (APCER – Associação Portuguesa de Certificação) - and two potential issues - AC Camerfirma for the potential audit disclosure issue, and Certinomis for the possible misassertion issue (unless it can demonstrate that ETSI authorized that OID, it would be violating 7.1.2.4 of the BRs) _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
