On Tue, Oct 30, 2018 at 1:10 PM Erwann Abalea via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> In fact, for the Relying Party, these certificates are definitely > considered as Qualified certificates for website authentication, regardless > of the content of the QCStatement extension. > Grab the German TL, find the T-Systems TSP, this specific service, you'll > see it's declared as a CA/QC type, status granted, with a Sie equal to > ForWebSiteAuthentication. There is no ambiguity (yet). > On what basis do you believe this claim is to be made? By virtue of asserting qcStatement-1? If qcStatement was mis-encoded, or qcStatement-1 was absent, do you believe the same? I'm not sure the ambiguity can be as easily resolved as you suggest, given the description within EN 319 412-5 > Are we going to also revoke all the certificates which contain encoded > DEFAULT values (in the ASN.1 sense), invalid PrintableString attributes, > invalid hostnames, Yes. This has already been the process now for several years, as shown through both https://wiki.mozilla.org/CA/Incident_Dashboard and the https://wiki.mozilla.org/CA/Closed_Incidents It is interesting that you chose those examples, as several are explicitly called out in the Root Policy at https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md#52-forbidden-and-required-practices > and reject audits performed by auditors who missed such certificates? > Yes. In general, the failure to detect such issues has called into question the competency of the auditor, as has the failure to disclose such issues. Both are relevant here, combined with the approach to revocation and overall testing methodology. Further, as detailed, the misleading remarks regarding what was examined are equally reason to question the competency of the auditor. This is no different than the rejection of audits from some WebTrust-accredited practioners due to significant oversights about ongoing and persistent misissuance that is critical within the scope of the audit scheme being used. The failure to detect such issues fundamentally calls into question the validity of the current audit, as well as those audits performed for other CAs. The response of the auditor to such issues equally bears calling into question the competencies of the auditor. > This esi4-qcStatement-6 QCStatement is a recent addition, has been really > poorly designed (a SEQUENCE OF that shall contain only 1 element, what a > great idea), and has seen several changes during the draft. It's an easy > statement, I agree, and a decent TSP shouldn't make any mistake in encoding > it. > But on the control side, there's not that much available tool to decode a > QCStatements extension (and no, "openssl asn1parse" and "dumpasn1" don't > count). > Considering that even prior versions (e.g. 2.0.12) included an ASN.1 module as a normative inclusion (Annex B), I find this profoundly non-compelling. See https://www.etsi.org/deliver/etsi_en/319400_319499/31941205/02.01.01_60/en_31941205v020101p.pdf . As you dig through these versions, the adopted versions do not share the ambiguity issues. You're correct that 2.2.0 formalized the corrigenda against 2.2.1 to include, textually, the normative requirement of "one and exactly one" method, but in either event, such encodings violate it entirely. I also fail to understand how one can argue that the CAB is following industry best practice, considering that industry best practice has included within it the use of tools such as certlint (which can ingest ASN.1 modules) or zlint (for which compliance support can be included). In any event, the testing procedure of visual inspection without actually conforming against the grammar is a fundamental approach to audit methodologies that does not stand up to scrutiny, and seriously calls into question the core competencies. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
