AW: Questions regarding the qualifications and competency of TUVIT

[Wiedenhorst, Matthias via dev-security-policy]

Dear all,

Still posting on behalf of TÜViT.

On Wed, Oct 31, 2018 at 11:43 AM Wiedenhorst, Matthias via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org>>
 wrote:
· Since January 2018, T-Systems issued EV certificates with an 
incorrect qcStatement. T-Systems was made aware of the problem in October 2018, 
i.e. for about 9 month the error was not detected/reported
https://bugzilla.mozilla.org/show_bug.cgi?id=1498463#c3
T-Systems fixed the error in a timely manner so that certificates now contain 
the correct qcStatement.

T-Systems identified a deficiency within their systems, made a change on 
October 5, but did not notify their CAB and SB until October 16.

Under the requirements provided by EN 319 401, 7.9, that does not seem 
consistent with meeting those requirements.

· TUVIT performed an audit of T-Systems according to ETSI policies EVCP 
and QCP-w in the beginning of 2018. During the audit the incorrect coding of 
the qcStatement was not detected.

Yes. I believe this is a significant issue, given the assessment report.

· In several emails, we answered to his complaint, explained our 
procedures and justified the classification of the encoding error as minor 
(non-critical) non-conformity.
For non-critical non-conformities, our certification requirements foresee a 
maximum period of 3 month for remediation before the certification shall be 
withdrawn. (see also ETSI EN 319 403, section 7.6 b) Based on the 
classification as minor, we do not see a necessity for revocation.
That’s about the relevant facts.
Let me now reply in detail to Ryans private contribution:

>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.

Dr. Anja Wiedemann (please mind the correct spelling) was not part of the audit 
team. We do not understand why her name is mentioned here.
One / three years exclusion from audit sounds like a punishment. We do not 
understand where this time frame comes from and why such a time frame is needed.

Auditor and Reviewer, as stated on 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2018072001_Audit_Attestation_E_Deutsche-Telekom-Root-CA-2_20180718_s.pdf
 - the parties tasked with ensuring that the audit is meaningfully able to 
ensure the criteria were met and the testing procedures were able to meet those 
requirements.

Auditors and reviewers need to be distinguished: ISO/IEC 17065 §7.5.1 forbids 
that the person(s) performing the review is involved in the audit process.

The time frame selected is one that has been consistently used in the past 
regarding questions about audits. Unfortunately, there lacks suitable means to 
objectively determine whether or not the auditor is sufficiently competent in 
remediation of problematic audits. Past procedures have resulted in indefinite 
suspensions for some auditors, or temporary suspensions of their recognition. 
The choice of three years, rather than one year, is based on the fact that we 
have now seen auditors who were not accredited perform audits against the 
frameworks, later become accredited, and retroactively issue reports covering 
their activities prior to accreditation. This does not instill confidence in 
the ETSI approach to auditor supervision, and thus the longer period is to 
ensure that no in-process audits are retroactively certified upon the 
expiration of the period. Three years thus aligns with both the 1 year (CA/B 
Forum) and 2 year (eIDAS) time periods in ensuring that such a possibility is 
not technically achievable.

>If there is a belief that a TSP has failed to meet the requirements of
>their accreditation, EN 319 403 describes a process for which complaints
>may be made to either the TSP or to the CAB. This complaint process is
>further expanded upon in ISO/IEC 17065, which 319 403 incorporates. This
>same process also applies when there have been mistakes by the CAB to
>adhere to its scheme requirements under EN 319 403 - a complaint may be
>made with either the CAB or the NAB regarding the CAB's accreditation.

TSPs are not accredited but certified, ETSI EN 319 403 §7.13 does not make any 
additional requirements on complaint procedures but just reference ISO/IEC 
17065. (The requirements from ISO/IEC 17065 [1], clause 7.13 shall apply.) In 
particular, no procedures for complaints to TSPs or NABs are defined (only to 
CABs).

4.1.2.2 (j) provides for the client (the TSP) to inform the CAB any complaints 
made known to it. You're correct that procedures for complaints directly to the 
TSP are not normatively specified by ISO/IEC 17065 or that of EN 319 403; 
however, the countenance is made that a client (t

AW: Questions regarding the qualifications and competency of TUVIT

[Wiedenhorst, Matthias via dev-security-policy]

Thanks for focussing the discussion on the substance and thus allowing the 
community moving towards a common understanding and towards defining adequate 
requirements for treating such kind of incidents. We are very much interested 
in improving the existing requirements as we have done in the past by 
participating actively in drafting of ETSI standards, including EN 319 403.

I am particularly disturbed by three points made by TUVIT during this 
discussion:

1. A malformed qcStatement extension is a minor non-conformity because there is 
no known security risk - This argument is incredibly dangerous and harmful. It 
implies that all sorts of well-defined requirements can be ignored if the CA 
and/or auditor decide that there is no risk in doing so.

We agree that neither CAs nor Auditors may ignore a failure against 
well-defined requirements independent of their classification as critical or 
non-critical.
This is already currently not the case as both are non-conformities.
CAs and auditors have to address every non-conformity and cannot ignore them. 
The classification (just) refers to the timeframe for remediation. Every major 
non-conformity has to be remediated before ETSI certification is possible. In 
case of existing certificates, the certificate is withdrawn. With minor 
non-conformities, an auditor may issue an ETSI certificate under the condition 
that every minor non-conformity is remediated within timeframe of 3 month 
(maximum) after conclusion of the audit. Existing certificates may stay valid 
but must be withdrawn if the CA fails to remediate within the deadline.

2. Citing ISO 17065 as requiring non-conformities be kept confidential - adding 
on Ryan's comments, we're seeing increasing disclosure of audit findings 
(another example: 
https://netlock.hu/download/etsi-certification-netlock/?wpdmdl=57340), leading 
me to believe that this is TUVIT's own interpretation of the confidentiality 
requirements. I don't believe that TUVIT needs "the establishment of rules with 
in the CAB/Forum for making such kind of incidents public" in order to begin 
making these disclosures.

Section 4.5 of ISO/IEC 17065 states that in general all non-public information 
shall be regarded as confidential. However, that section also allows that CAB 
and TSP can agree between each other about information not to be regarded as 
confidential.
Our interpretation (which we think is aligned with current interpretation of 
general data protection legislation informally stated as “everything which is 
not explicitly required/allowed is forbidden”), indeed follows a minimum 
principle. So you are right, with consent of the TSP it is possible and we are 
willing to request such consent in future.
We suggest the establishment of general rules / requirements valid for all 
auditors instead of individual / different commitments. These rules could be on 
the content of public audit reports and on the roles of audits during security 
incidents including reporting and should allow browsers and the interested 
community to obtain the necessary information to get a good picture on the 
incident and the assessment of the auditor.

3. The argument that T-Systems has 3-months to revoke these certificates - 
while I understand that under ETSI TSPs have 3 months to correct minor 
non-conformities, using that as an excuse to ignore CAB Forum revocation 
requirements is unacceptable, and perhaps explains why we see such poor 
compliance with this requirement. If this is indeed the accepted interpretation 
(please confirm), then I will look for ways to fix this via Mozilla policy.

- Wayne

>From the ETSI certification point of view, this is the interpretation. Failure 
>to revoke within the required timeframe is clearly a non-conformity. 
>Nevertheless, if the non-conformity has been rated as minor non-conformity 
>(due to the individual circumstances), there would be a period of 3 month 
>before the corresponding ETSI certification would be withdrawn.
However, we do see your concern and it is a very reasonable one. Using this 
construct to deliberately delay revocation is not at all desired. How could we 
deal with it?
One possibility would be for the CAB to mandatorily require the TSP  to publish 
the failure to adhere to the certificate revocation timeline requirement as bug 
in the Bugzilla (as already required from the TSP by Mozilla Policy) before the 
rating as minor non-conformity is possible. Without publication, it has to be 
rated as major non-conformity and hence an existing ETSI certificate will be 
withdrawn. This would facilitate the interest of transparency and would allow 
Mozilla, if regarded necessary, to take further action regardless of a still 
existing ETSI certificate. In the past, the ETSI certificate was not regarded 
as the primary audit deliverable by root store operators; this is the audit 
attestation letter. Combined with number 2 above, in such the case the next 
audit attestation letter would also 

AW: Request to Include Microsec e-Szigno Root CA 2017 and to EV-enable Microsec e-Szigno Root CA 2009

[Wiedenhorst, Matthias via dev-security-policy]

Dear all,

with regard to the findings listed in the different audit attestations, we 
would like to clarify that
-   all non-conformities have been resolved in a timely manner
-   the resolution has been audited by and proven to the certification body

In addition, we would like to emphasise that a pure number of non-conformities 
is not per se an indication of pour quality of the TSP but more an indication 
of a thorough audit. Give the number of different CAs / services within the 
scope of the audit, the number of non-conformities appears to be not 
extraordinary high.
Please also keep in mind, that according to the current agreement, audit 
attestations list all non-conformities, independent of their severity and 
status (resolved or not). We feel, that non-conformities should be evaluated 
individually and TSPs should not suffer to any penalties just because of the 
number of non-conformities revealed in the audit.

Best regards
Matthias Wiedenhorst
--
TUV Informationstechnik GmbH
TUV NORD GROUP


> -Ursprüngliche Nachricht-
> Von: dev-security-policy  Im
> Auftrag von Kathleen Wilson via dev-security-policy
> Gesendet: Montag, 9. März 2020 19:49
> An: mozilla-dev-security-pol...@lists.mozilla.org
> Betreff: Request to Include Microsec e-Szigno Root CA 2017 and to EV-enable
> Microsec e-Szigno Root CA 2009
>
> This request is for inclusion of the Microsec e-Szigno Root CA 2017 trust 
> anchor
> and to EV-enable the currently included Microsec e-Szigno Root CA 2009 trust
> anchor as documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1445364
>
> BR Self Assessment is here:
> https://bugzilla.mozilla.org/attachment.cgi?id=9036567
>
> Summary of Information Gathered and Verified:
> https://ccadb-
> public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0274
>
> Root Certificate Download URLs:
> http://www.e-szigno.hu/rootca2017.crt
> http://www.e-szigno.hu/rootca2009.crt
>
> CP/CPS:
> eIDAS conform Qualified Certificate for Website Authentication CP (EV):
> https://static.e-szigno.hu/docs/hr--min--ssl--EN--v2.13.pdf
> eIDAS conform Qualified Certificate for Website Authentication CPS (EV):
> https://static.e-szigno.hu/docs/szsz--min--ssl--EN--v2.13.pdf
> eIDAS conform Certificate for Website Authentication CP (DV, OV):
> https://static.e-szigno.hu/docs/hr--fok--ssl--EN--v2.13.pdf
> eIDAS conform Certificate for Website Authentication CPS (DV, OV):
> https://static.e-szigno.hu/docs/szsz--fok--ssl--EN--v2.13.pdf
>
> This request is to include the 2017 root with the websites and email trust 
> bits
> enabled, and to enable both roots for EV.
>
> Test Websites for the 2017 root:
> Valid: https://eqtlsca2018-valid.e-szigno.hu/
> Expired: https://eqtlsca2018-expired.e-szigno.hu/
> Revoked: https://eqtlsca2018-revoked.e-szigno.hu/
>
> Test Websites for the 2009 root:
> Valid: https://qtlsca2018-valid.e-szigno.hu/
> Expired: https://qtlsca2018-expired.e-szigno.hu/
> Revoked: https://qtlsca2018-revoked.e-szigno.hu/
>
> CRL URLs:
> http://rootca2017-crl1.e-szigno.hu/rootca2017.crl,
> http://rootca2017-crl2.e-szigno.hu/rootca2017.crl,
> http://rootca2017-crl3.e-szigno.hu/rootca2017.crl
> http://rootca2009-crl1.e-szigno.hu/rootca2009.crl,
> http://rootca2009-crl2.e-szigno.hu/rootca2009.crl,
> http://rootca2009-crl3.e-szigno.hu/rootca2009.crl
>
> OCSP URLs:
> http://rootca2017-ocsp1.e-szigno.hu,
> http://rootca2017-ocsp2.e-szigno.hu, http://rootca2017-ocsp3.e-szigno.hu
> http://rootca2009-ocsp1.e-szigno.hu,
> http://rootca2009-ocsp2.e-szigno.hu, http://rootca2009-ocsp3.e-szigno.hu
>
> Audit: Annual audits are performed by TÜViT according to the ETSI 319
> 411 audit criteria.
> Microsec e-Szigno Root CA 2017:
> BR:
> https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2019121302_e-
> Szigno-Root-CA-2017_V1.1_s.pdf
> EV:
> https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2019061201_Micro
> sec-eSzignoRoot-CA-2017_EV-CAs_s.pdf
> Microsec e-Szigno Root CA 2009:
> BR:
> https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2019121301_Micro
> sec-eSzignoRoot-CA-2009_V1.1_s.pdf
>
> EV:
> https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2019121301_Micro
> sec-eSzignoRoot-CA-2009_V1.1_s.pdf
>
>
> Wayne performed the detailed review of the CPs, CPSs, BR Self Assessment, and
> related information for inclusion of the Microsec e-Szigno Root CA 2017 and 
> the
> EV-enablement of the Microsec e-Szigno Root CA 2009 roots that are being
> tracked in this bug and he had the following comments:
>
> ==Meh==
> * The subordinate CA certificates for this root were created in 2017 and 2018.
> None of those intended for serverAuth are constrained by EKU.
> Mozilla began requiring this in 2019.
> * Microsec issued two certificates in 2018 with 3-year validity periods [1].
> * There are roughly 20 policy documents for this hierarchy [2]. It is quite
> challenging to determine which documents apply to which types of certificates.
> The 

AW: Request to Include Microsec e-Szigno Root CA 2017 and to EV-enable Microsec e-Szigno Root CA 2009

[Wiedenhorst, Matthias via dev-security-policy]

Hello Ryan,

my message was not meant as a response to your previous message but as a 
general contribution.
I know that you have deepest knowledge around the different audit schemes. 
However, others on this list might be less familiar with audits. That’s why I 
thought it might be useful to provide some framing information from the 
auditors perspective, although knowing that you already had elaborated on some 
of the aspects.

I am not proposing that decisions should not be based on published 
non-conformities but I wanted to point out that decisions shall consider all 
the facts and should not be based purely on the number of non-conformities. As 
you said, just counting "bad" points without looking at the whole picture might 
set wrong incentives.

Best regards
Matthias


Von: Ryan Sleevi 
Gesendet: Mittwoch, 11. März 2020 19:18

Matthias,

I took a lot of care to address precisely that concern, so I hope that message 
was not directed in response to me. If it was, then I think it highlights a 
fundamental misunderstanding of the concern.

I think everything you said is consistent with the response I offered. I am 
would be far more deeply concerned with the auditor if they did not list such 
non-conformities, and took great care to try to highlight that the risk of 
penalizing based on number of non-conformities listed would simply encourage 
CAs to work with their auditors to hide things. However, the response a CA 
takes to address those non-conformities /is/ a critical evaluation of trust.

Your response, while appreciated, runs the risk of suggesting we can't make a 
decision to not trust a CA without evidence of non-conformities, but if there 
is evidence of non-conformities, we shouldn't use that as evidence in a 
decision to not trust a CA. That's not really sustainable, nor is it in line 
with the purpose and goal of audits themselves, at least as practiced by 
Mozilla since the first version of the root policy.

On Wed, Mar 11, 2020 at 11:45 AM Wiedenhorst, Matthias via dev-security-policy 
<mailto:dev-security-policy@lists.mozilla.org> wrote:
Dear all,

with regard to the findings listed in the different audit attestations, we 
would like to clarify that
-   all non-conformities have been resolved in a timely manner
-   the resolution has been audited by and proven to the certification body

In addition, we would like to emphasise that a pure number of non-conformities 
is not per se an indication of pour quality of the TSP but more an indication 
of a thorough audit. Give the number of different CAs / services within the 
scope of the audit, the number of non-conformities appears to be not 
extraordinary high.
Please also keep in mind, that according to the current agreement, audit 
attestations list all non-conformities, independent of their severity and 
status (resolved or not). We feel, that non-conformities should be evaluated 
individually and TSPs should not suffer to any penalties just because of the 
number of non-conformities revealed in the audit.

__
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

AW: Policy 2.7.1: MRSP Issue #152: Add EV Audit exception for Policy Constraints

[Wiedenhorst, Matthias via dev-security-policy]

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  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
Besuchen Sie unseren Internetauftritt: www.tuev-nord.de
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

AW: MRSP Issue #147 - Require EV audits for certificates capable of issuing EV certificates

[Wiedenhorst, Matthias via dev-security-policy]

Hi Ben, Hi all,

sorry for the late reply. Thanks to your summary yesterday, I re-checked all 
the open issues and stumbled upon one question with regard to this issue that 
didn't came to my mind earlier.

I am not sure if I am understanding correctly the desired outcome of this 
change. Forgive me if I am overlooking something to obvious at the moment.
Main parts of the EV requirements and hence of an EV audit are about the 
issuance and certificate profile of end-entity certificates.

Let's say we have an EV-enabled Root CA "A" and a Sub-CA "B", which is only 
used to issue DV certificates, but which is not properly constrained and hence 
would be EV capable.

Now, if I would perform an EV audit on Sub-CA "B", then of course all issued 
end entity certificate would fail to meet the EV requirements on end-entity 
certificates (obviously, because they are DV certificates...). As a result, 
such Sub-CA would be non-conformant with regard to EV requirements and not pass 
the audit.
So is the intent to not allow such Sub-CA's, because they can't pass the 
necessary audit?

Or is the intent only, that the Sub-CA certificate for "B" must meet all EV 
requirements on Sub-CA certificates?

Or did you have a scenario in mind, where a Sub-CA "C" has been used to issue 
EV certificates, is than (temporarily) taken out of service and sometime later 
activated again. Now someone could (bot of course shoulndn't) argue that "C" 
has not been issuing EV certs and hence no EV audits were necessary for that 
period.

Best regards
Matthias


> -Ursprüngliche Nachricht-
> Von: dev-security-policy  Im
> Auftrag von Ben Wilson via dev-security-policy
> Gesendet: Dienstag, 6. Oktober 2020 22:38
> An: mozilla-dev-security-policy 
> 
> Betreff: MRSP Issue #147 - Require EV audits for certificates capable of 
> issuing
> EV certificates
>
>  #147  - Require EV audits 
> for
> certificates capable of issuing EV certificates – Clarify that EV audits are 
> required
> for all intermediate certificates that are technically capable of issuing EV
> certificates, even when not currently issuing EV certificates.
>
> This issue is presented for resolution in the next version of the Mozilla 
> Root Store
> Policy.
>
> Suggested language is presented here:
> https://github.com/BenWilson-
> Mozilla/pkipolicy/commit/a83eca6d7d8bf2a3b30529775cb55b0c8a5f982b
>
>
> The proposal is to replace "if issuing EV certificates" with "if capable of 
> issuing
> EV certificates" in two places -- for WebTrust and ETSI audits.
> ___
> 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
Besuchen Sie unseren Internetauftritt: www.tuev-nord.de
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy