1583464 - Add SI-TRUST root certificate

Status: RESOLVED WONTFIX

(CA Program :: CA Certificate Root Program, task)

Comment 1

[Kathleen Wilson]

The information for this root inclusion request is here:

https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000496

I have a backlog of CA updates to root inclusion requests, so it will take me a while to get to this one. I will add another comment to this bug when I perform the review.

Comment 2

[Kathleen Wilson]

The link below shows the information that has been verified for this root inclusion request. Search in the page for the word "NEED" to see where further clarification is requested. Please add a comment to this bug when you have provided all of the requested information.

https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000496

In particular, please provide the following:

1. Audit statements that meet the requirements of Mozilla's Root Store Policy,
   https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#314-public-audit-information
   e.g. SHA256 of each root and intermediate in audit scope
   Also, why is the audit type "Equivalent ETSI EN 319 411"? Is it audited according to the ETSI EN 319 411 criteria? Or is it audited according to some other "Equivalent" criteria?

2. BR audit statement that meets the requirements of Mozilla's Root Store Policy and section 8.6 of the CAB Forum Baseline Requirements.
   https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.6.pdf

3. Relevant CP/CPS documents translated into English, per
   https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Publicly_Available_CP_and_CPS
   "The CP/CPS must be available in an English version. The non-English version may be authoritative (as that's the working language of the CA) but the CA is responsible for ensuring that the translation is not materially different from the authoritative version of the document."

4. Resolve errors listed when doing the following:

• https://certificate.revocationcheck.com/
• Certificate Upload
• Paste in the PEM for the SIGOV-CA intermediate cert
• Check Revocation Status
  Errors: No CRL URL (only LDAP), OCSP service returned 'Malformed', ThisUpdate not set (RFC 5019, section 6.2), NextUpdate not set (RFC 5019, section 2.2.4)
  Note Baseline Requirement section 7.1.2.2, Subordinate CA Certificate,
  cRLDistributionPoints: This extension MUST be present and MUST NOT be marked critical. It MUST contain the HTTP URL of the CA’s CRL service

5. Resolve and explain all errors listed here:
   https://crt.sh/?caid=24508&opt=cablint,zlint,x509lint&minNotBefore=2017-01-01
   https://crt.sh/?caid=14985&opt=cablint,zlint,x509lint&minNotBefore=2017-01-01

6. Shall issuance under this root be restricted to the .SI TLD?

Note that this "SI-TRUST Root" certificate that has ValidFrom 4/25/2016, appears to have several intermediate certs and many end-entity certs that would be considered mis-issued according to Mozilla's root store policy and the BRs. I suggest that you consider creating a new root certificate and CA hierarchy that is compliant with Mozilla's root store policy and the Baseline Requirements from creation. Then apply for inclusion of that new root certificate rather than this existing root certificate.

Comment 3

[Aleš Pelan]

Please find below the explanations regarding the listed points.

1. Audit statements that meet the requirements of Mozilla's Root Store Policy:
   The audit statement URL has been changed to https://www.si-trust.gov.si/assets/Uploads/MS-QualifyingAttestationLetter-SITRUST-2019-sign.pdf which should meet the requirements.
   The audit that we took is an eIDAS audit for qualifed EU certificates that is in accordance with criteria of certification scheme defined by standard ETSI EN 319 403 v2.2.2, in association with DKP version 2. The certificate of the accredited auditor is available online at the URL https://www.cai.cz/OA/pdf/P93_2018_EN.pdf.
   The standard ETSI EN 319 403 explicitely refers to the ETSI standards for Trust Service Providers issuing certificates. The list of used audit standards in the audit statement therefore includes ETSI EN 319 411-1 V1.2.2 and ETSI EN 319 411-2 V2.2.2. We anticipated that the audit type is "Equivalent ETSI EN 319 411" but we can change it to "ETSI EN 319 411" if this suits you more.

2. BR audit statement that meets the requirements of Mozilla's Root Store Policy and section 8.6 of the CAB Forum Baseline Requirements:
   The audit statement URL has been changed to https://www.si-trust.gov.si/assets/Uploads/MS-QualifyingAttestationLetter-SITRUST-2019-sign.pdf which should meet the requirements.

3. Relevant CP/CPS documents translated into English:
   The CP/CPS documents were translated to English. They are available at the URL https://www.si-trust.gov.si/en/support/trust-service-authority-of-slovenia-policies/. Please note that the fine reading hasn't been done yet so there might be some clumsy wordings in the documents.

4. Resolve errors listed when doing the following:
   The listed errors are not errors in fact:

• "No CRL URL (only LDAP)":
  The CRL Distribution Points indeed includes the LDAP location of CRL but it includes also the HTTP location, namely http://www.ca.gov.si/crl/si-trust-root.crl, which is correctly shown at the https://certificate.revocationcheck.com/.

• "OCSP service returned 'Malformed'":
  OCSP response is not available using GET method but it is available using POST method which is correctly shown at the https://certificate.revocationcheck.com/.

• "ThisUpdate not set" and "NextUpdate not set":
  Errors refer to the OCSP response using GET method which is not supported. They aren't listed for the OCSP response using POST method.

5. Resolve and explain all errors listed here:
   https://crt.sh/?caid=24508&opt=cablint,zlint,x509lint&minNotBefore=2017-01-01

• CA/B Forum lint:

ERROR: BR certificates must not contain rfc822Name type alternative name:
We kept the email as the additional Subject Alternate Name but we can change this immediately if needed.

ERROR: BR certificates must be 825 days in validity or less:
The validity period was changed from 36 to 27 months on 28 May 2018 when the CP/CPS were updated. Three of listed certificates that were issued after 28 May 2018 are not SSL certificates (the "Extended Key Usage" is not "TLS Web Server Authentication")

ERROR: commonNames in BR certificates must be from SAN entries:
The listed certificates are not SSL certificates but either qualified certificates for e-signature or general information system certificates. Namely, the "Extended Key Usage" field of the listed certificates is not set as "TLS Web Server Authentication".

ERROR: BR certificates must be 39 months in validity or less:
The listed certificates are not SSL certificates but either qualified certificates for e-signature or general information system certificates. Namely, the "Extended Key Usage" field of the listed certificates is not set as "TLS Web Server Authentication".

• X.509 lint:

ERROR: Invalid type in SAN entry:
We kept the email as the additional Subject Alternate Name but we can change this immediately if needed.

ERROR: The certificate is valid for longer than 60 months:
The listed certificates are not SSL certificates but either qualified certificates for e-signature or general information system certificates. Namely, the "Extended Key Usage" field of the listed certificates is not set as "TLS Web Server Authentication".

ERROR: Subject with givenName or surname but without the CAB IV policy oid:
The listed certificates are not SSL certificates but either qualified certificates for e-signature or general information system certificates. Namely, the "Extended Key Usage" field of the listed certificates is not set as "TLS Web Server Authentication".

• ZLint:

ERROR: The Subject Alternate Name extension MUST contain only 'dnsName' and 'ipaddress' name types:
We kept the email as the additional Subject Alternate Name but we can change this immediately if needed.

ERROR: Subscriber Certificate: subject:stateOrProvinceName MUST NOT appear if the subject:organizationName, subject:givenName, and subject:surname fields are absent:
The subject:organizationName field is present in the listed certificates.

ERROR: Subscriber Certificate: subject:localityName MUST NOT appear if subject:organizationName, subject:givenName, and subject:surname fields are absent:
The subject:organizationName field is present in the listed certificates.

ERROR: Subscriber Certificates issued after 1 March 2018 MUST have a Validity Period no greater than 825 days:
The validity period was changed from 36 to 27 months on 28 May 2018 when the CP/CPS were updated.

ERROR: Subscriber certificates MUST have the extended key usage extension present:
The listed certificates are not SSL certificates but either qualified certificates for e-signature or general information system certificates. Namely, the "Extended Key Usage" field of the listed certificates is not set as "TLS Web Server Authentication".

ERROR: Subscriber Certificates issued after 1 July 2016 but prior to 1 March 2018 MUST have a Validity Period no greater than 39 months:
The listed certificates are not SSL certificates but either qualified certificates for e-signature or general information system certificates. Namely, the "Extended Key Usage" field of the listed certificates is not set as "TLS Web Server Authentication".

ERROR: Subscriber Certificate: A certificate containing a subject:givenName field or subject:surname field MUST contain the (2.23.140.1.2.3) certPolicy OID:
The listed certificates are not SSL certificates but either qualified certificates for e-signature or general information system certificates. Namely, the "Extended Key Usage" field of the listed certificates is not set as "TLS Web Server Authentication".

ERROR: Subscriber Certificate: subject:stateOrProvinceName MUST NOT appeear if the subject:organizationName, subject:givenName, and subject:surname fields are absent:
The subject:organizationName field is present in the listed certificates.

ERROR: DNSNames must have a valid TLD:
The DNSName in the listed certificate is valid. However, we kept the email as the additional Subject Alternate Name but we can change this immediately if needed.

ERROR: The common name field in subscriber certificates must include only names from the SAN extension:
The listed certificate is not SSL certificate but general information system certificate. Namely, the "Extended Key Usage" field of the certificate is not set as "TLS Web Server Authentication".

https://crt.sh/?caid=14985&opt=cablint,zlint,x509lint&minNotBefore=2017-01-01

• CA/B Forum lint:

ERROR: BR certificates must not contain rfc822Name type alternative name:
We kept the email as the additional Subject Alternate Name but we can change this immediately if needed.

ERROR: BR certificates with organizationName must include either localityName or stateOrProvinceName:
The subject:localityName field was added on 28 May 2018 when the CP/CPS were updated.

ERROR: BR certificates must be 825 days in validity or less:
The validity period was changed from 36 to 27 months on 28 May 2018 when the CP/CPS were updated.

• X.509 lint:

ERROR: Invalid type in SAN entry:
We kept the email as the additional Subject Alternate Name but we can change this immediately if needed.

ERROR: Subject with organizationName, givenName or surname but without stateOrProvince or localityName:
The subject:localityName field was added on 28 May 2018 when the CP/CPS were updated.

ERROR: The certificate is valid for longer than 60 months:
The listed certificates are not SSL certificates but general information system certificates. Namely, the "Extended Key Usage" field of the listed certificates is not set as "TLS Web Server Authentication".

• ZLint:

ERROR: The Subject Alternate Name extension MUST contain only 'dnsName' and 'ipaddress' name types:
We kept the email as the additional Subject Alternate Name but we can change this immediately if needed.

ERROR: Subscriber Certificate: subject:stateOrProvinceName MUST appear if the subject:organizationName, subject:givenName, or subject:surname fields are present and subject:localityName is absent:
The subject:localityName field was added on 28 May 2018 when the CP/CPS were updated.

ERROR: Subscriber Certificate: subject:localityName MUST appear if subject:organizationName, subject:givenName, or subject:surname fields are present but the subject:stateOrProvinceName field is absent:
The subject:localityName field was added on 28 May 2018 when the CP/CPS were updated.

ERROR: Subscriber Certificates issued after 1 March 2018 MUST have a Validity Period no greater than 825 days:
The validity period was changed from 36 to 27 months on 28 May 2018 when the CP/CPS were updated.

6. Shall issuance under this root be restricted to the .SI TLD?
   No. The restriction applies to organizations themselves because they need to be registered in Slovenia. Therefore most of them use .SI TLD but this is not necessary in order to obtain a certificate.

Comment 4

[Kathleen Wilson]

There are two show-stopper problems with this CA hierarchy that will prevent Mozilla from approving inclusion of the following root certificate.
CN=SI-TRUST Root; O=Republika Slovenija; C=SI
Validity: 4/25/2016 - 12/25/2037
SHA-256 Fingerprint FAD540811AFAE0DC767CDF6572A088FA3CE8493DD82B3B869A67D10AAB4E8124

The show-stopper problems are:

1. Continued issuance of non-BR-compliant TLS certificates, and the CA's response in Comment #3 shows that the CA is not aware of the Baseline Requirement to revoke non-BR-compliant certs within 5 days of learning of the non-compliance.
   For example: https://crt.sh/?id=2066751833&opt=cablint
   See section 7.1.4.2.1, Subject Alternative Name Extension, of the Baseline Requirements.
   And also see section 4.9.1.1, Reasons for Revoking a Subscriber Certificate, of the Baseline Requirements.
   https://crt.sh/?caid=24508&opt=cablint,zlint,x509lint&minNotBefore=2017-01-01
   https://crt.sh/?caid=14985&opt=cablint,zlint,x509lint&minNotBefore=2017-01-01

2. Intermediate certificates that are capable of issuing TLS certificates that have not and are not being audited according to the required audit criteria. For example, the "sigov-ca", "sigen-ca" and "SI-PASS-CA" intermediate certs are not audited according to ETSI EN 319 411-2 QCP-w, even though they are capable of issuing server authentication (SSL/TLS) certs.
   See section 3.1.2.2 ETSI of Mozilla's Root Store Policy.
   See section 8.1 of the Baseline Requirements.

Therefore, inclusion of this root certificate is denied. I will close this bug and the corresponding root inclusion case.

You are welcome to re-apply for inclusion of a new root certificate with a CA hierarchy that is and has always been fully compliant with Mozilla's root store policy and the Baseline Requirements, has the correct constraints on intermediate certificates, has pre-cert-issuance lint testing, and has the correct audits from creation. When you are ready, please create a new Root Inclusion Case and Bugzilla Bug.

Please also let your auditor know about these problems, so that they can improve their future audit practices.

Comment 5

[Aleš Pelan]

Please find below our comments:

• The only non-conformacy that hasn't been resolved yet is keeping an email as the additional Subject Alternate Name. We will correct this setting in the CP/CPS as soon as possible. We are also willing to revoke affected certificates, even though (in our opinion) this non-conformacy does not introduce any security risk for website operators and/or end-users.
• The intermediate certs "ou=sigov-ca", "ou=sigen-ca" and "cn=SI-PASS-CA" are not audited according to ETSI EN 319 411-2 QCP-w because they are not issuing server authentication (SSL/TLS) certs. In fact, intermediate certs "ou=sigov-ca" and "ou=sigen-ca" are not issuing any certificates anymore since they will expire in 2021 and were substituted by intermediate certs "cn=SIGOV-CA" and "cn=SIGEN-CA G2" that are the only intermediate certs issuing SSL/TSL certificates.

Comment 6

[Kathleen Wilson]

(In reply to Aleš Pelan from comment #5)

Please find below our comments:

• The only non-conformacy that hasn't been resolved yet is keeping an email as the additional Subject Alternate Name. We will correct this setting in the CP/CPS as soon as possible. We are also willing to revoke affected certificates, even though (in our opinion) this non-conformacy does not introduce any security risk for website operators and/or end-users.

I think that statement reiterates my decision to deny this root inclusion request. Additionally, upon reading this CA's CP/CPS I was unable to find the required BR Commitment to Comply. Therefore, it appears that this CA is making decisions about which BRs they think are important enough to follow. The BRs are not optional for CAs who want their root certificate trusted for TLS in Mozilla's program.

• The intermediate certs "ou=sigov-ca", "ou=sigen-ca" and "cn=SI-PASS-CA" are not audited according to ETSI EN 319 411-2 QCP-w because they are not issuing server authentication (SSL/TLS) certs. In fact, intermediate certs "ou=sigov-ca" and "ou=sigen-ca" are not issuing any certificates anymore since they will expire in 2021 and were substituted by intermediate certs "cn=SIGOV-CA" and "cn=SIGEN-CA G2" that are the only intermediate certs issuing SSL/TSL certificates.

If this root cert were included in Mozilla's program and the Websites (TLS) trust bit enabled, those intermediate certs would be capable of issuing TLS certs that would be trusted in Firefox. It is not possible to enforce rules based on a CA's intended usage for intermediate certificates which is why the BRs and Mozilla's Root Store Policy require technical constraints (via EKU) on intermediate certs that are not intended to be used for TLS.