On Tue, Oct 30, 2018 at 4:37 PM Erwann Abalea via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> > 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. > Ah hah! Thanks for that context! That means I should re-examine the case of Certinomis in the context of https://groups.google.com/d/msg/mozilla.dev.security.policy/x3s3CSKdIlY/R1C4JAvOBQAJ , since I was downplaying the significance based upon the lack of asserting id-etsi-qcs-QcCompliance in the QCStatements, without consideration of the Certificate Policies. > 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). > I'm not sure the issues are so easily disentangled, given the other QCStatements supported. For example, the constitutive value of an id-etsi-qcs-QcLimitValue. Or is the view that such issues are to be addressed at the national level in accordance with TL maintenance? > > 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. > Oh, for sure, that was in https://www.etsi.org/deliver/etsi_en/319400_319499/31941205/02.00.12_20/en_31941205v020012a.pdf - but even still, OIDs never aligned > > 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. > Sure. It's also unlikely that will stop anytime soon though (c.f. PSD2 in TS 119 495, although that may be withdrawn now? https://portal.etsi.org/webapp/workProgram/Report_Schedule.asp?WKI_ID=53961 ) _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
