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 <[email protected]> Im > Auftrag von Kathleen Wilson via dev-security-policy > Gesendet: Montag, 9. März 2020 19:49 > An: [email protected] > 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=00000274 > > 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 upcoming version of Mozilla policy states that “CAs must provide a way to > clearly determine which CP and CPS applies to each of its root and > intermediate > certificates.” > * CP section 1.3.2 permits 3rd party RAs, but in their BR Self-Assessment, > Microsec states that “The Trust Service Provider do not apply third parties > for RA > activities.” > * CPS section 4.9.5 provides a detailed explanation of the revocation process > but > fails to mention the required preliminary report to the Subscriber and the > entity > who filed the Certificate Problem Report. > * CPS section 4.9.1 contains a section titled “Reasons for Revoking a > Subordinate > CA Certificate operated by another CA” but in their BR Self-assessment, > Microsec > states that “All Subordinate CA-s under the Microsec roots are operated by > Microsec.” > > ==Bad== > * I was unable to locate the description of email address validation practices > required by Mozilla policy section 2.2. Microsec published new CPS version > adding section 3.2.7 to resolve this issue. > * Microsec recently issued what appears to be two certificate used for > testing that > violate the BRs [3][4]. They are now expired. > * CCADB currently lists 9 audit letter validation failures for Microsec. > * The root contains subject L and organizationIdentifier fields which are > arguably > in violation of BR 7.1.4.3 [5]. Some, if not all, of the subCAs also exhibit > this issue. > * BR section 4.9.3 requires CPS section 1.5.2 to contain instructions for > reporting > an issue such as key compromise to the CA. The Microsec CPS’ only state that > questions related to the policy may be reported via the info in that section, > and > other email addresses (“[email protected]”, > “[email protected]") are found in other sections of some documents. > Section 4.9.5 then states that revocation requests are only accepted at the > address listed in section 1.2, but there is no email address in this section. > * Three EV (QWAC) certificates have been issued with an extra > subject:serialNumber field that contains what appears to be a policy OID [6]. > Only > one is currently revoked. > * In comment #18 of the inclusion bug dated January 2019, Microsec confirms > that > their CPS did not contain the required CAA information, despite Microsec > being a > Mozilla root program member at that time. > > * The following non-conformities were listed in the 2018 BR attestation > statement > [7]. (they are not defined as “major” or “minor”): > ** The TSP shall remove irrelevant and confusing information from each policy > (e.g. explanation of how to create policy codes) [ETSI EN 319 401, REQ-6.1-01] > ** The TSP shall clearly indicate which kind of documents are necessary for > the > application procedures of different types of certificates. [ETSI EN 319 401, > REQ- > 6.1-01] > ** The TSP shall maintain such asset list which can support the daily > operation > and does not cover unnecessary elements (e.g. mouse, keyboard) [ETSI EN 319 > 401, REQ-7.3.1-01, REQ-7.3.1-02]•The TSP shall ensure that the password policy > provisions are applied in all systems in the TSP and shall review them > periodically. [ETSI EN 319 401, REQ-7.4-06] > ** The TSP shall move the videoserver from the secondary data center to > another > secure location without IT administrator access and shall review the records > on > regular basis. [ISO27001], [ETSI EN 319 401, REQ-7.6-03] > ** The TSP shall check operational state of the CCTV system regularly. > [ETSI EN 319 401, REQ-7.6-03]•The TSP shall extend the Termination Plan to all > services mentioned in the CPSs. [ETSI EN 319 401, REQ-7.12-02] > ** The TSP shall check the possibilities to store and review video logs for a > longer period of time. [ETSI EN 319 411-1, OVR-6.4.2-07] The TSP shall > maintain > dual control for performing critical functions on the core systems (including > Root > CA, intermediate CAs, archiving system, TSA system, OCSP responders etc.) > [ETSI EN 319 411-1, GEN-6.4.3-02, OVR-6.4.8-07, GEN-6.5.1-04, GEN-6.5.2-06] > ** The TSP shall develop a restoration plan which schedules the restoration > over > time to cover every system. [ETSI 319 411-1, OVR-6.4.8-05] > ** The TSP shall approve and publish the latest version of its CP und CPS > documents. [ETSI EN 319 401, REQ-6.1-05] > ** The TSP shall modify the web application form and the registration > interface in > such a way that it is clearly indicated what kind of information are required > for the > issuance of the given certificate in accordance with the policies. Misleading > information shall be avoided. > [ETSI EN 319 401, REQ-6.1-01] > * The following minor non-conformities are listed in the 2018 EV attestation > statement [8]: > ** Findings with regard to ETSI EN 319 401: 7.11 Business continuity > management Documentation and implementation of the generation of the OCSP > certificates within the BCP document shall be improved. [ETSI EN > 319 401, Clause 7.11] > ** Findings with regard to ETSI EN 319 411-1: 6.2 Identification and > authentication > Documentation and implementation of the internal guideline with regard to the > verification of possible organizations shall be improved. [ETSI EN 319 411-1, > Clause 6.2.2 a), g), i)] [EVCG, Clause 11.1.1, Point 1. (A)] [ETSI EN 319 > 411-1, > Clause 6.2.2 a)] > > * The following non-conformities were listed in the 2019 BR attestation > statement > [9]: > ** The TSP shall not issue non-compliant test certificates from the live > environment. As this has been occurred in the past, the TSP shall provide > evidences of the changed testing procedures to avoid further occurrence of > such > events. [ETSI EN 319 401, REQ-6.1-07] > ** The TSP shall ensure that all issuance of a qualified signature comply with > eIDAS Article 24 in each case. [ETSI EN 319 411-1, REG-6.2.3-01] > ** The TSP shall ensure that all issuance of a qualified certificate comply > with > eIDAS Article 24 when TSP accepts certificate re-keying requests as written > mail > with handwritten (wet) signatures via postal services and any of the > subject’s data > is changed. [ETSI EN 319 411-1, REG-6.2.3-01] > ** The TSP shall review the re-keying procedure in the CPS and shall align the > CPS with the real process-es and the relating standards. [ETSI EN 319 411-1, > REG-6.2.3-02] > ** The TSP shall ensure that the reusing procedure of all data fulfills the > EVCG > 11.14 and the CPS corresponds to these reusing requirements. > [ETSI EN 319 411-1, REG-6.2.3-03] > ** There are conflicts between Hungarian law and EV Guideline regarding to the > witnessing the root ca key generation by a Qualified Auditor, the TSP must > inform > the CAB/Forum about this fact. [ETSI 319 411-1 GEN-6.5.1-14], [BRG, 9.16.3], > [EVCG, 8.1], [EVCG, 17.7] > ** The TSP shall present a mitigation plan to revoke and replace the non- > conforming certificates with exponent 101. [ETSI EN 319 411-1, SDP-6.5.1-18] > * The following minor non-conformities are listed in the 2019 EV attestation > statement [10]: > ** Documentation and implementation of the generation of the OCSP certificates > within the BCP document shall be improved. [ETSI EN 319 401, Clause 7.11] > ** Documentation and implementation of the internal guideline with regard to > the > verification of possible organizations shall be improved. > [ETSI EN 319 411-1, Clause 6.2.2 a), g), i)] [EVCG, Clause 11.1.1, Point 1. > (A)] > [ETSI EN 319 411-1, Clause 6.2.2 a)] > > > This begins the 3-week comment period for this request [11]. > > I will greatly appreciate your thoughtful and constructive feedback on the > acceptance of this root into the Mozilla CA program. > > - Kathleen > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1512270 > [2] https://e-szigno.hu/en/all-documents.html > [3] https://crt.sh/?id=1947655126&opt=zlint,ocsp > [4] https://crt.sh/?id=1947655112&opt=zlint,ocsp > [5] https://cabforum.org/pipermail/servercert-wg/2019-October/001154.html > [6] https://crt.sh/?cablint=225&iCAID=115482&minNotBefore=2017-01-01 > [7] > https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2018121303_Micro > sec-eSzignoRoot-CA-2017_nonEV-CAs_s.pdf > [8] > https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2019061201_Micro > sec-eSzignoRoot-CA-2017_EV-CAs_s.pdf > [9] > https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2019121302_e- > Szigno-Root-CA-2017_V1.1_s.pdf > [10] > https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2019061201_Micro > sec-eSzignoRoot-CA-2017_EV-CAs_s.pdf > [11] https://wiki.mozilla.org/CA/Application_Process > > _______________________________________________ > dev-security-policy mailing list > [email protected] > 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 [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
