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_Microsec-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_Microsec-eSzignoRoot-CA-2009_V1.1_s.pdf
EV:
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2019121301_Microsec-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
(“highprioritycertificateproblemrep...@e-szigno.hu”,
“revocat...@e-szigno.hu") 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_Microsec-eSzignoRoot-CA-2017_nonEV-CAs_s.pdf
[8]
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2019061201_Microsec-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_Microsec-eSzignoRoot-CA-2017_EV-CAs_s.pdf
[11] https://wiki.mozilla.org/CA/Application_Process
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
