Le mardi 30 octobre 2018 18:28:50 UTC+1, Ryan Sleevi a écrit : > On Tue, Oct 30, 2018 at 1:10 PM Erwann Abalea via dev-security-policy < > [email protected]> 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).
Sorry, I was reading the TL too fast; this certificate is Qualified, but not a QWAC. > 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? qcStatement-1 is not mandatory, by law, if the policyId is QCP or QCP+, or if there's a matching Qualification stating that the certificate is Qualified. Implementing decision 2015/1505 defines the common EU rules, and I haven't found the specific German rules (they're asserted in the German TL). 2015/1505 can be found at https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32015D1505 My mistake was that I looked at the Sie and didn't check if there was a QualificationsExtension node. > I'm not sure the ambiguity can be as easily resolved as you suggest, given > the description within EN 319 412-5 The weight taken by EN 319412-5 is important for the EN 319412-2 certification, but not for the Qualified status and usage of the certificate (because that's a legal issue). > > 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 Fine. I'm waiting for the revocation of certificates containing an underscore in a SAN:dnsName. > > 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 > . I was talking about draft versions. The QcType definition was SEQUENCE { qcType OBJECT IDENTIFIER } just before that. > 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 agree, having the id-etsi-qct-web OID used for the statementId is a clear violation. I'm just pointing that this specific QCStatement was really stupidly defined from the start. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
