Hi everybody,

this might not be closely connected to original topic, but allow me to comment 
on one issue below.

Best regards
Matthias

> -----Ursprüngliche Nachricht-----
> Von: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> Im
> Auftrag von Ryan Sleevi via dev-security-policy
> Gesendet: Samstag, 17. Oktober 2020 01:56
>
> [...]
>
> Indeed, you will hopefully recall the discussion in Shanghai that examined how
> some ETSI CAs issued certificates bearing a Qualified certificate OID, well 
> before
> they had been audited as such.
> However, once they were included within the Qualified Trust List, then all of 
> those
> certificates were retroactively granted legal effect - undermining the very
> objective of qualified certificates in the first place!

That is not my understanding of eIDAS and the Trusted Lists. Different from EV 
handling, qualified status and corresponding legal effect is not granted / 
changed retroactively. It is granted at a certain point in time and is only 
valid from that time until is withdrawn. For that purpose, the TLS includes the 
"current status starting date and time" and "previous status starting date and 
time" entries, which shall not be back-dated (see section 5.5.5 of ETSI TS 119 
612 v2.1.1).
This understanding is also captured in the statement of Clemens, as included in 
the minutes you quoted below.

>
> [...]
>
> For reference, the specific portion of the minutes that capture this are 
> reproduced
> below:
>
> > One area that Wayne brought up was about EV audits – what happens when
> > an existing root requests EV status? Ryan raised the example of
> > European CAs that were issuing QWACs before they’d been audited
> > against 319 411-2. They could be successfully audited after-the-fact.
> > If root programs granted EV, that would retroactively grant EV, while
> > for qualified status, it’d only be from the point of the audit – which is 
> > probably
> >not what browsers expect.
> > Clemens said they shouldn’t be issuing qualified certificates before
> > then, but if they do, they just don’t have qualified status in terms of the 
> > law.
> > When asked about WebTrust, Don said the same thing was possible – the
> > [...]
> _______________________________________________
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

______________________________________________________________________________________________________________________
Sitz der Gesellschaft/Headquarter: TÜV Informationstechnik GmbH * 
Langemarckstr. 20 * 45141 Essen, Germany
Registergericht/Register Court: Amtsgericht/Local Court Essen * HRB 11687 * 
USt.-IdNr./VAT No.: DE 176132277 * Steuer-Nr./Tax No.: 111/57062251
Geschäftsführung/Management Board: Dirk Kretzschmar


TÜV NORD GROUP
Expertise for your Success


Please visit our website: www.tuv-nord.com<http://www.tuv-nord.com>
Besuchen Sie unseren Internetauftritt: www.tuev-nord.de<http://www.tuev-nord.de>
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to