Bonjour, Le mardi 30 octobre 2018 16:20:31 UTC+1, Ryan Sleevi a écrit : > (Writing with an individual hat) > > I would like to suggest that consideration be given to rejecting future > audits from TUVIT and from that of Matthias Wiedenhorst and Dr. Anja > Widermann, for some period of time. I would suggest this period be at least > one year long; however, given the technical details of ETSI accreditation, > believe a period of three years may be more appropriate. > > As part of an investigation into the incorrect qcStatements reported at > https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/x3s3CSKdIlY > , I've used this as an example to explore the complaint handling process > under ETSI EN 319 403.
[...] > In addition to these concerns with respect to the audits provided, I will > be further lodging a complaint with the German National Accreditation > Body, Deutsche Akkreditierungsstelle GmbH, regarding TUVIT's accreditation > under EN 319 403 to asses TSPs against EN 319 411-1 and EN 319 411-2. The > handling of this incident, the material misstatement as to what was > examined, combined with the failure to ensure appropriate and prompt > notification to the CAB and the Supervisory Body (as detailed in > https://bugzilla.mozilla.org/show_bug.cgi?id=1498463#c3 ) call into serious > question the compliance with Regulation (EU) N°910/2014 on behalf of both > T-Systems and TUVIT. In particular, the failure to perform a timely > notification under Article 19(2) of the "loss of integrity that has a > significant impact on the trust service provider" represents a significant > breach of trust. > > With respect to what constitutes a "loss of integrity", both Article 8 and > Article 7(f) note compliance to the appropriate technical standards and the > prohibition of any "specific disproportionate technical requirements on > relying parties ..." that would "significantly impede the interoperability > of the notified electronic identification schemes". Articles 7 and 8 have nothing to do with that kind of notification (for security breaches), they're related to notification of identification schemes to the European Commission. > Through their failure to assure a timely disclosure, and the failure to > revoke, TUVIT's certifications disproportionately and adversely affect > Relying Parties. Such certificates assert that they are qualified > certificates, and thus Relying Parties should be able to rely upon them for > their constitutive value. However, in the absence of the appropriate and > mandatory notice as to the qualified purpose of such certificates, as this > incident demonstrates, Relying Parties are left without an interoperable > means of determining whether or not such Qualified Certificates are indeed > qualified, and thus subject to the protections afforded by eIDAS. 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). Are we going to also revoke all the certificates which contain encoded DEFAULT values (in the ASN.1 sense), invalid PrintableString attributes, invalid hostnames, and reject audits performed by auditors who missed such certificates? 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). _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
