Le mardi 30 octobre 2018 22:23:10 UTC+1, Ryan Sleevi a écrit : > On Tue, Oct 30, 2018 at 4:37 PM Erwann Abalea via dev-security-policy < > [email protected]> 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.
Ok. Then in this context, the Certinomis' certificate is just not claimed to be qualified. It's permitted. The problem regarding 0.4.0.1.6 remains, though. > > 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? The eIDAS regulation, its associated implementing acts and delegated acts, don't mention ETSI EN 319411 or ETSI 319412 at all. So, from an eIDAS point of view (Qualified status, signature/seal/...), compliance to EN 319412-5 does not matter. For the LimitValue statement, the note is even clearer in that it was introduced to support the 1999 directive, and no equivalent text is present in the eIDAS regulation. [...] > > > 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 > ) It certainly won't be withdrawn (PSD2 is another European Directive which consumes eIDAS services, this TS provides technical support for that). It's also badly designed (IMHO). I'll let payment service providers come in and do their part of the job, or accept the resulting beast (they're late, but it seems some are discovering it and mourn, that's amusing). The withdrawal you're pointing at is for the WI (work item). Once the deliverable is produced (and considered mature enough), the WI is shut down. A new one can later be re-open in order to work on a revision. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
