2020. március 9., hétfő 19:48:56 UTC+1 időpontban Kathleen Wilson a következőt írta: > 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 > > > 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: >
Let me answer Wayne's findings in the original text > ==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. The subordinate CA-s already contain EKU which are intended to issue codesigning certificates and certificates for time stamping units. There is not EKU in the subordinate CA certificates which are intended to issue other types of certificates, like website authentication, digital signature, client authentication, encryption etc. These subordinate CAs were created in 2017. > * Microsec issued two certificates in 2018 with 3-year validity periods [1]. The certificates were issued for CISCO VPN servers. After receiving the information about the misissuance the certificates were revoked. > * 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.” Microsec already offers a tool on its homepage which filters the corresponding policy documents to a specific type of certificates. The CP and CPS documents contain the policy OID values which are included in the issued certificates. The CP OID contains also the version of the CP so it is evident which version of the CP is relevant. Microsec plans to develop a tool which will help the user to find the proper CP and CPS documents for a specific certificate based on the CP OID included in the certificate. > * 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.” Correct, Microsec presently do not apply any third parties for RA activities as it written in the CPS. > * 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. The working process contains the communication with the Subscriber and the entity who filed the Certificate Problem Report. This information will be included in the next version of the CPS. > * 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.” Microsec is open for this type of cooperation, but presently Microsec operates all the subordinate CA-s under the Microsec roots. > > ==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 always validates the email address, typically by sending an email containing an unique URL to the email address which has to be used by the Subscriber. The actual CPS contains more detailed description about the validation method of the email addresses. > * Microsec recently issued what appears to be two certificate used for > testing that violate the BRs [3][4]. They are now expired. These were only pre-certificates which were sent to the log servers. These pre-certificates have been issued for internal test purposes only. The live certificates have never been published in our certificate store and never been used in publicly available networks. > * CCADB currently lists 9 audit letter validation failures for Microsec. The CCADB presently contains 0 failure > * 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. It is a general requirement that CA name shall be detailed enough to allow relatively straightforward identification of the CA. In the EU all of the companies has an official and unique company registration number, and it is a requirement to add this value into the enduser certificates in the organizationIdentifier field. It is widely used in subordinate certificates too. The section BR 7.1.4.3 contains only 3 mandatory fields which shall be included in the certificate, but it is not clear in the wording of the BR that other fields are not allowed to be used. According to the basic requirement Microsec adds these two more fields to the CA certificates to make possible the clear identification of the CA. > * 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 > (“highpriority...@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. The CPS of Microsec is structured according to the requirement of RFC3647. This also required by the CABF BR in section 2.2. According to RFC3647 the Section 1.5 is for the policy administration and section 1.5.2 defines the contact person who is responsible for maintaining the CPS. Section 4.9.3 of the CPS contains detailed information about the possibilities of revocation request submission. Section 1.3.1 contains the email addresses, where revocation request can be sent (mentioning section 1.2 is an editorial mistake, it will be corrected in the next version of the CPS). Section 4.9.3 contains also a subsection which describes the High-Priority Certificate Problem Report mechanism. More detailed information can be found on our website on the given link. > * 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. Microsec issued only test EV certificates from the "e-Szigno Qualified TLS CA 2018" CA to support the test sites for valid, revoked and expired certificates required by Mozilla. The OID in the subject:serialNumber field of the certificates is the unique identifier of the subject assigned by Microsec in a form of an OID. One of these certificates is revoked on purpose, the next had an extremely short validity and the third has already expired. Usually Microsec puts more than one serialnumber field to the different type of enduser certificates, one of them contains this OID based identifier of the Subject. After having the discussion regarding the usage of the organizationIdentifier filed in the EV certificates last year, it became clear that the EVG allows only one serialnumber field. Microsec changed its general practice and policy in case of EV certificates, and presently the EV certificates contain only one serialnumber field hich contains the company registration number. > * 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 Microsec CPS contains, that Microsec checks the content of the CAA record as part of the validation process from the CPS version 2.3 dated 2017-04-30. The information about the accepted domain name is added to the CPS in the version 2.9 dated 2019-04-24. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
