On Friday, October 12, 2018 at 4:07:11 AM UTC+8, Wayne Thayer wrote: > This request is for inclusion of these four emSign roots operated by > eMudhra in bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1442337 > > * BR Self Assessment is here: > https://bug1442337.bmoattachments.org/attachment.cgi?id=8955225 > > * Summary of Information Gathered and Verified: > https://bug1442337.bmoattachments.org/attachment.cgi?id=9006698 > > * Root Certificate Download URL: https://repository.emsign.com/ > > * CP/CPS: https://repository.emsign.com/cps/CP-CPS-v1.04.pdf > > * This request is to include the roots with the email and websites trust > bits enabled and with EV treatment. > > * EV Policy OID: 2.23.140.1.1 > > * Test Websites > https://testevg1.emSign.com > https://testevg1e.emsign.com > https://testevg1r.emsign.com > https://testevg3.emSign.com > https://testevg3e.emsign.com > https://testevg3r.emsign.com > https://testevc1.emSign.com > https://testevc1e.emsign.com > https://testevc1r.emsign.com > https://testevc3.emSign.com > https://testevc3e.emsign.com > https://testevc3r.emsign.com > > * CRL URLs: > http://crl.emsign.com?RootCAG1.crl > http://crl.emsign.com?RootCAG3.crl > http://crl.emsign.com?RootCAC1.crl > http://crl.emsign.com?RootCAC3.crl > > * OCSP URL: http://ocsp.emsign.com > > * Audit: Point-in-time audits were performed by BDO Malaysia according to > the WebTrust for CA, BR, and EV audit criteria. > WebTrust: > https://repository.emsign.com/downloads/auditreports/1-A-CA_opt.pdf > BR: https://repository.emsign.com/downloads/auditreports/2-A-SSL_opt.pdf > EV: https://repository.emsign.com/downloads/auditreports/3-A-EVSSL_opt.pdf > > emSign expects to receive period-of-time audit reports covering February to > September 2018 in the next week. I request that an emSign representative > post links to those reports to this thread when they are available. > > I’ve reviewed the CPS, BR Self Assessment, and related information for > inclusion of the four emSign roots that is being tracked in this bug and > have the following comments: > > ==Good== > * Roots were signed earlier this year and a RKGC report was provided [1]. > * CPS section 1.4.2 forbids the use of emSign certificates for MITM. > > ==Meh== > * The CPS allows “external issuing CAs” but does not clearly state that the > requirements of BR section 1.3.2 will be met. emSign made the following > comment in response to this concern: “In the CP/CPS, there is reasonable > definition for both External Issuing CAs and External RAs. Section 1.1 of > CP/CPS also promises that BR supersedes this document.” > * It is not clear from emSign’s response in their application if they have > implemented pre-issuance linting: “Certificate issuance of emSign goes > through stringent checks, and application has validated controls to meet > the BR and RFC requirements for standards. emSign continues to implement > additional tools (as recommended) in order to enhance the pre-issuance > checks.” > * CPS section 3.2.7 clearly defines data reuse requirements for certificate > renewal. CPS section 3.2.8 implied by omission that re-keying could be done > without revalidation of information even if it was more than 825 days old. > This has been addressed in the current version of the CPS. > > ==Bad== > * Version 1.03 of the CPS allowed emSign to violate the BR requirements for > CAA validation. Section 4.2.4 stated: “If a CAA record exists and does not > list emSign PKI based Issuing CAs as an authorized CA, Issuing CA shall > verify that the applicant has authorized issuing CA to issue, despite > existence of CAA record.” This sentence has been removed from the current > CPS. > * One of the domain validation methods in CPS section 10.1 was not > specified in enough detail to allow a reader to determine if it meets BR > requirements: “Relying on publicly available records from the Domain Name > Registrar, such as WHOIS or other DNS record information.” This has been > improved in the current version of the CPS, however I would prefer to see a > more detailed description of each domain validation methods with references > to the BR method numbers. > * CPS section 10.6 described “Device Certificates” as “Includes TLS/SSL > Certificates for internal use”, then went on to omit any description of > domain validation procedures. If these TLS certificates chain to an > included root as would be implied by including them in this CPS, then they > must not allow internal names and must conform to BR domain verification > rules. The reference to “TLS/SSL Certificates for internal use” was removed > from the current version of the CPS. > * Mozilla policy 2.2(2) requires the CPS to describe how email address > validation is performed for emailProtection (S/MIME) certificates. The > statement “or any other reliable means” in section 10.7 does not meet this > requirement. emSign improved this description in the latest version of the > CPS, but the “or any other reliable means” language remains.
This has been taken into consideration for correction in all parts of the document. Section 10.2, 10.4 and 10.6 edits are due for ratification, and this will be part of next CP/CPS update during PA next week. > * Mozilla policy 2.2(4) requires the CPS to describe how IP address > validation is performed for TLS certificates. The statement “or any other > equivalent procedure, which proves the applicant’s right to use the IP” > that was in sections 10.1-10.3 did not meet this requirement. This was > corrected in the current version of the CPS. > * CPS section 3.2.1 did not clearly prohibit the generation of key pairs > for TLS subscriber certificates by emSign. This is forbidden by Mozilla > policy section 5.2. It was corrected in the current version of the CPS. > > This begins the 3-week comment period for this request [2]. > > I will greatly appreciate your thoughtful and constructive feedback on the > acceptance of these roots into the Mozilla CA program. > > - Wayne > > [1] https://bug1442337.bmoattachments.org/attachment.cgi?id=8955245 > [2] 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
