I provide brief explanations for the 2019 audit findings as follows: > > * The following non-conformities were listed in the 2019 BR attestation > statement [9]:
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2019121302_e-Szigno-Root-CA-2017_V1.1_s.pdf This is the latest non-EV report for the ECC root from 2019-12-13 > ** 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] Microsec uses automated tests to monitor the availability of the Web Immediate Suspension service. To perform the tests, Microsec needs one test certificate from each of the subordinate CAs. Private keys are not needed at all so, after the issuance of the test certificates the private keys are destroyed. These test certificates are periodically suspended and then automatically reinstated. On 2019-09-13, new test certificates were issued directly from each CA in the ECC root hierarchy with the following Subject DN data: SERIALNUMBER = 1.3.6.1.4.1.21528.2.2.1.13331 E = i...@..........hu CN = Microsec zrt. - Automata Felfüggesztő - ECC 2.5.4.97 = VATHU-23584497 O = Microsec zrt. L = Budapest C = HU 5 of the test certificates were issued to natural persons for electronic signature creation, but this DN does not match the certificate profile for electronic signature certificates. The auditor reported one of the incorrect certificates to Microsec at 2019-10-12 21:23 Microsec processed the report, identified the issue, verified the entire certificate database for similar issues, and revoked all 5 affected certificates with this issue at 2019-10-13 13:19. Following the revocation of the test certificates concerned, new test certificates were issued in accordance with the normal certificate issuance process. Microsec introduced a new process for issuing internal test certificates issued in the live system. All internal test certificates shall be issued from the RA system as part of the normal issuance process. It is now prohibited to issue even test certificates directly from the CA software. The standard certificate issuance process has multiple built-in automatic controls to avoid issuing faulty certificates. The auditor has reviewed the changed testing procedures, accepted the provided evidence, and deemed this finding as resolved. > ** 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] Article 24 of eIDAS contains very stringent (stronger than the EVG) requirements for the identity verification before issuing qualified certificates. The basic process requires face-to-face identity verification of the natural person, who can be the Subject in case of a signing certificate or the representative of the Subject in case of seal or website authentication certificate. eIDAS and the ETSI standards do not specify how long this face-to-face verification can be reused or when it shall be repeated. Different EU member states have different interpretations and different practices. Some member states allow the re-use of the verification result in the case of a certificate renewal, but in other member states it has to be repeated in case of issuance of a certificate due to any reason (renewal, rekey, modification). Instead of the face-to-face identity verification, the CA may accept a qualified signature or qualified seal created with the certificate to be renewed. This cannot be done if the certificate cannot be used to create a valid digital signature. The Hungarian requirements are very strict and always require face-to-face verification in each case when a valid digital signature is not available. Microsec CPS did not provide detailed regulation in some of these special cases. Microsec updated its public documents, which are valid from 2019-12-12. The section 3.2 of the CPS was modified. When issuing any certificate, Microsec uses the same identity verification process as used for initial identity verification. In all cases, the procedure for issuing qualified certificates is fully in line with Article 24 of eIDAS. > ** 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] It is the same issue as described above. In the event of a lost smartcard, the Subscriber is not able to create a valid digital signature to request a certificate re-key, and it is not possible at all with a website authentication certificate. Microsec had previously accepted the re-key request in a paper and ink based signed document, and Microsec used a trusted communication channel (usually a phone call) to validate the signature of the received request. In the current version of the CPS, this process can only be used if the expiration date of the re-keyed certificate is the same as the original certificate. In all other cases, the initial validation process shall be repeated, including the face-to-face verification. > ** The TSP shall review the re-keying procedure in the CPS and shall > align the CPS with the real processes and the relating standards. [ETSI > EN 319 411-1, REG-6.2.3-02] Nowhere is it defined exactly what re-keying means. The most useful information can be found in RFC3647. The definition does not exist in the ETSI standards, and ETSI EN 319 411-1 contains requirements that can be interpreted in different ways. The main question is whether the re-key can be used for an invalid certificate or not. After discussing the situation with the auditor and the supervisory body, we concluded that re-keying is possible for both valid and invalid certificates, but only during the validity of the service contract. Microsec improved its CPS and slightly modified the requirements for the re-keying process. It clearly states that re-keying is possible for both valid and invalid certificates, but only during the validity of the service contract. This practice is in accordance with RFC3647 and ETSI EN 319 411-1. > ** 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] According to Hungarian requirements, all validation result shall be re-validated before a qualified certificate is issued. During the validation process, Microsec only accepts validation data not older than 3 months. Microsec improved its public documents to define this topic in more detail. Version 12 of public documents are effective from 2019-12-12. The new documents have stricter requirements for re-use of validation data than EVG requires. Generally, Microsec repeats all the validation tasks when a certificate is re-issued. The only exception is when the new certificate is issued with the same expiry date as the original certificate in case of re-keying. In this case, the original validation results can be re-used. > ** 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 conflict concerns a qualified auditor checking the generation of the root CA key. The Hungarian legislation requires the presence of two persons with special trusted roles but excludes the presence of any further persons. CABF BR requires the presence of a third person, such as a qualified auditor. These requirements are contradictory and cannot be met at the same time. Before generating ECC root keys in 2017, Microsec contacted the auditor and the Hungarian supervisory authority to discuss the issue. Based on the outcome of the discussion, Microsec decided to comply with the CABF BR requirement, and an auditor from TÜViT was present during the ECC root key generation process. In addition, Microsec informed the Ministry of Interior about this conflict and asked them to change the Hungarian regulations. Following the 2019 audit, Microsec discussed the situation with the auditor via email. Finally, Microsec agreed with the auditor that there was no need to notify CABF, as Microsec complied with the CABF BR and EVG requirements. In 2020, Microsec received a letter from the Ministry. We have been informed that the problematic regulation is about to change. > ** 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 issue is related to keys generated onboard on a specific type of smartcard. The corresponding certificates had been issued to create qualified electronic signatures and authenticate clients. The keys were generated with a public exponent 101. This value does not meet the specification of ETSI TS 119 312, but it did not represent a security risk for the affected customers. Microsec decided to generate new keypairs on the smartcards onboard with proper public exponent. Microsec developed a secure web platform and client application and has organized the entire process within a limited time frame. The detailed mitigation plan was sent to TÜViT on 2019-10-24 and subsequently upgraded two times. The whole process was performed according to the accepted mitigation plan. The process in numbers is: Total number of affected cards: 4380 Cardholder have seen the information web page: 3918 Cardholder have successfully downloaded the application: 3916 Cardholder have started running the application: 3898 Cardholder have successfully finished running the application: 3842 Cardholders with new certificates: 3821 3821 of 4380 cards have been successfully upgraded and can be used further. 559 cards have not been upgraded for different reasons. Some of the cardholders were unavailable, some of them had different technical problems and some of them terminated the service. They are managed individually by the Microsec customer service. Before 16:00 on 2019-12-09 all certificates with public exponent 101 have been revoked. --------------------- The Audit letter also declares, that: For all minor non-conformities, the remediation has been successfully checked by provided evidences. This Audit Attestation has not recorded any incident. > * The following minor non-conformities are listed in the 2019 EV > attestation statement [10]: https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2019061201_Microsec-eSzignoRoot-CA-2017_EV-CAs_s.pdf This is the period of time EV attestation letter for the new ECC root on 2019-06-12 This is the same document as included at the year 2018 > ** Documentation and implementation of the generation of the OCSP > certificates within the BCP document shall be improved. [ETSI EN 319 > 401, Clause 7.11] The generation of the OCSP certificates was changed, it was moved to another server. The actual version of the Business Continuity Plan contained the earlier server configuration and not the actual configuration. Microsec reviewed the whole BCP document and corrected the fault in it. Microsec held a training for the employees responsible for the maintenance of the BCP document, to ensure that it is kept up to date. > ** 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 internal documents contain detailed guidelines on how to validate the data of an organization. Hungary has a national company registration system which contains all the data of the bigger private companies. The database is publicly available and contains the actual and authentic data of all the registered companies. Microsec uses this service during the validation of the company data. This database does not contain the registration data of the private entrepreneurs. Since these entities very rarely apply for certificates, the internal guideline did not specify how to check private entrepreneurs, this information was planned to be added as needed for the first application. Registration officers were aware of this. This did not cause any problems in practice; no such entity requested an EV certificate from Microsec. Based on the finding of the auditor, Microsec developed the validation rules for this type of entity and added this information to the internal guideline. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
