Add New emSign Root Certificates

RESOLVED FIXED

Status

task
RESOLVED FIXED
Last year
3 months ago

People

(Reporter: vijay, Assigned: kwilson)

Tracking

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [ca-approved] - in NSS 3.43, FF 67; EV-enabled in FF 68)

Attachments

(16 attachments)

246.73 KB, application/pdf
Details
144.54 KB, application/pdf
Details
375.45 KB, application/pdf
Details
232.46 KB, application/pdf
Details
14.96 KB, application/x-zip-compressed
Details
2.94 MB, application/x-zip-compressed
Details
6.85 KB, application/x-zip-compressed
Details
9.16 MB, application/x-zip-compressed
Details
3.69 MB, application/pdf
Details
158.21 KB, application/pdf
Details
256.87 KB, application/pdf
Details
1.08 MB, application/pdf
Details
1.26 MB, application/pdf
Details
629.78 KB, application/pdf
Details
677.52 KB, application/pdf
Details
680.97 KB, application/pdf
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36
Posted file CA Hierarchy
I've attached the following, and looking forward to hear further.
1. Detailed CA Information in accordance to https://wiki.mozilla.org/CA/Information_Checklist
2. CA Hierarchy 
3. BR Self Assessment
4. Root Certificates Information
5. S/MIME Content - Samples
6. TestReports for EV, Revocation, BR Lint, Zlint
7. Root CA Certificates (6 CER Files)
8. Webtrust Audit Reports - Feb 2018
9. Root and Subordinate CA - Key Ceremony Audit Report by Webtrust Auditor
I have not attached the CP/CPS document here. It is available at https://repository.emsign.com/cps/CP-CPS-v1.01.pdf, as stated in CA Information document. Please let me know if it has to be uploaded here.
Acknowledging receipt of this root inclusion request. I have a huge backlog of CA updates/requests to review, so this has been added to my list. I will update this bug when I begin information verification of this request as per step #2 of our process:
https://wiki.mozilla.org/CA/Application_Process#Process_Overview
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Whiteboard: [ca-verifying]
I have begun verifying the data in this request.

Vijay, please provide a short justification about why you are requesting inclusion of 6 root certs. What does each of them offer that the others don't? And explain why you cannot cross-sign some of them so that all of them do not need to be directly included.
The attached document shows the information that I have verified so far. Search the document for the word "NEED" to find where further information or clarification is needed.

In particular:

1) Revision Table not found, per
https://wiki.mozilla.org
/CA/Required_or_Recommended_Practices#CP.2FCPS_Revision_Table

2) CAA Domains not found in CP/CPS, per 
https://wiki.mozilla.org
/CA/Required_or_Recommended_Practices#CAA_Domains_listed_in_CP.2FCPS

3) NEED justification for each of the 6 root certs in this inclusion request.

4) CPS section 1.1: "This CP/CPS addresses the actions of emSign PKI and not those of third parties operating with cross certificates issued by emSign PKI."
NEED Clarification -- The above sentence seems to contradict sections 1.3.1, 4.1.2, and 4.2.1.
Whiteboard: [ca-verifying] → [ca-verifying] - KW Comment #14 2018-05-24
I have received email from the auditor confirming the authenticity of the audit statements.
Hi Kathleen, We have reviewed your comment. Please find the below responses.

Revision Table:
Revision table is part of version 1.01 of CP/CPS (Ref: https://repository.emsign.com/cps/CP-CPS-v1.01.pdf). It is at the end as Appendix C (Change History)of the document. Version 1.00 did not have this, as it was initial version of the document.
Proposed update: Our compliance team reviewed your query and suggested to add the “date” against each version in this section. This change will be published in repository after necessary policy authority meeting.

CAA records:
Section 4.2.4 covers the CAA record process. However, the set of Issuer Domain Names that the we recognises in CAA "issue" or "issuewild" records as permitting it to issue is not explicitly covered.
Proposed update: The section 4.2.4 is proposed to be updated with addition of the explicit statement after first sentence “The CAA records authorizing emSign PKI shall contain ‘emsign.com’ as the issuer domain names for ‘issue’ and ‘issuewild’ entries.” This change will be published in repository after necessary policy authority meeting.

6 Roots explanation:
Primarily there are 3 root certs in the name of emSign - Indian entity. One is in ECC algorithm, another in RSA-2048, and another in RSA-4096 (specially for timestamp/codesign and users demanding SSL originated through issuing CA of 4096 root). This is designed based on the technical requirement and to comply with certain security needs.
3 more root certs are in similar algorithm categorization, and is in the name of affiliate company eMudhra Inc, USA. This affiliate entity meets the user demands of America as well as other users who specifically demand from this US entity. Please let us know if there are any specific views on this.

CP/CPS applicability:
The inconsistency in CPS applicability is noted and reviewed. The section 1.1 has an oversight mistake and the word ‘not’ is being removed.
Proposed update: The said statement now modified to read as “This CP/CPS addresses the actions of emSign PKI and those of third parties operating with cross certificates issued by emSign PKI.” This change will be published in repository after necessary policy authority meeting.

The CP/CPS changes mentioned above are after detailed review of your comment, and will be ratified to final version (to be published in the repository in the coming week).

Regards, Vijay
(In reply to Vijay Kumar from comment #16)
> Hi Kathleen, We have reviewed your comment. Please find the below responses.
> 
> Revision Table:
> Revision table is part of version 1.01 of CP/CPS (Ref:
> https://repository.emsign.com/cps/CP-CPS-v1.01.pdf). It is at the end as
> Appendix C (Change History)of the document. Version 1.00 did not have this,
> as it was initial version of the document.
> Proposed update: Our compliance team reviewed your query and suggested to
> add the “date” against each version in this section. This change will be
> published in repository after necessary policy authority meeting.

OK

> 
> CAA records:
> Section 4.2.4 covers the CAA record process. However, the set of Issuer
> Domain Names that the we recognises in CAA "issue" or "issuewild" records as
> permitting it to issue is not explicitly covered.
> Proposed update: The section 4.2.4 is proposed to be updated with addition
> of the explicit statement after first sentence “The CAA records authorizing
> emSign PKI shall contain ‘emsign.com’ as the issuer domain names for ‘issue’
> and ‘issuewild’ entries.” This change will be published in repository after
> necessary policy authority meeting.

OK

> 
> 6 Roots explanation:
> Primarily there are 3 root certs in the name of emSign - Indian entity. 

The "O=eMudhra Technologies Limited" roots are primarily for use in India?
If included, should Mozilla constrain those roots to certain TLDs?


> 3 more root certs are in similar algorithm categorization, and is in the
> name of affiliate company eMudhra Inc, USA. This affiliate entity meets the
> user demands of America as well as other users who specifically demand from
> this US entity. Please let us know if there are any specific views on this.

The "O=eMudhra Inc" roots are primarily for global customers?


"emSign Root CA - G2" and "emSign Root CA - C2" appear to only be used for Code Signing and Time Stamping, so they are not applicable to Mozilla's root store. Only the Websites and Email trust bits are applicable to Mozilla's root store. 

So this request is for inclusion of the following 4 root certs, but two of them are the ECC version of the corresponding root cert.

CN=emSign Root CA - G1, OU=emSign PKI, O=eMudhra Technologies Limited, C=IN
CN=emSign ECC Root CA - G3, OU=emSign PKI, O=eMudhra Technologies Limited, C=IN

CN=emSign Root CA - C1, OU=emSign PKI, O=eMudhra Inc, C=US
CN=emSign ECC Root CA - C3, OU=emSign PKI, O=eMudhra Inc, C=US


> 
> CP/CPS applicability:
> The inconsistency in CPS applicability is noted and reviewed. The section
> 1.1 has an oversight mistake and the word ‘not’ is being removed.
> Proposed update: The said statement now modified to read as “This CP/CPS
> addresses the actions of emSign PKI and those of third parties operating
> with cross certificates issued by emSign PKI.” This change will be published
> in repository after necessary policy authority meeting.

OK

> 
> The CP/CPS changes mentioned above are after detailed review of your
> comment, and will be ratified to final version (to be published in the
> repository in the coming week).

OK
As I was processing the C1 and G3 roots I received errors from the revocationcheck site.

For example:

https://certificate.revocationcheck.com/testevc3.emsign.com
 ERROR: NextUpdate is 4s before the date in the Expires cache header
(In reply to Kathleen Wilson from comment #17)

> 
> > 
> > 6 Roots explanation:
> > Primarily there are 3 root certs in the name of emSign - Indian entity. 
> 
> The "O=eMudhra Technologies Limited" roots are primarily for use in India?
> If included, should Mozilla constrain those roots to certain TLDs?

Not really. The Indian entity also operates among several geographies and doesn't constrain to Indian Geography. It is dependent on the Business, Operational and Customer requirements, that Indian entity will be serving. This is the primary for global customers.

> 
> 
> > 3 more root certs are in similar algorithm categorization, and is in the
> > name of affiliate company eMudhra Inc, USA. This affiliate entity meets the
> > user demands of America as well as other users who specifically demand from
> > this US entity. Please let us know if there are any specific views on this.
> 
> The "O=eMudhra Inc" roots are primarily for global customers?

This once again depends on Business, Operational and Customer requirements. Where the users specifically demand for US entity based certificates, this is serviced. From business outlook angle, this requirement is more of our users from American continents, Middle East, & European countries. But this has no TLD constrains and we wish to operate this under Global category.

> 
> 
> "emSign Root CA - G2" and "emSign Root CA - C2" appear to only be used for
> Code Signing and Time Stamping, so they are not applicable to Mozilla's root
> store. Only the Websites and Email trust bits are applicable to Mozilla's
> root store. 
> 
> So this request is for inclusion of the following 4 root certs, but two of
> them are the ECC version of the corresponding root cert.
> 
> CN=emSign Root CA - G1, OU=emSign PKI, O=eMudhra Technologies Limited, C=IN
> CN=emSign ECC Root CA - G3, OU=emSign PKI, O=eMudhra Technologies Limited,
> C=IN
> 
> CN=emSign Root CA - C1, OU=emSign PKI, O=eMudhra Inc, C=US
> CN=emSign ECC Root CA - C3, OU=emSign PKI, O=eMudhra Inc, C=US
> 

You are right about 4 roots to be considered as G2 and C2 are primarily for Code Signing / Time Stamping. I request you to please exclude them.

In summary, it is two RSA and two ECC roots.
(In reply to Kathleen Wilson from comment #18)
> As I was processing the C1 and G3 roots I received errors from the
> revocationcheck site.
> 
> For example:
> 
> https://certificate.revocationcheck.com/testevc3.emsign.com
>  ERROR: NextUpdate is 4s before the date in the Expires cache header

Sorry to notice this! Found that, this is a patch related issue in OCSP server, and is being permanently mitigated. I will post an update here once I receive a test confirmation.
(In reply to Vijay Kumar from comment #20)
> (In reply to Kathleen Wilson from comment #18)
> > As I was processing the C1 and G3 roots I received errors from the
> > revocationcheck site.
> > 
> > For example:
> > 
> > https://certificate.revocationcheck.com/testevc3.emsign.com
> >  ERROR: NextUpdate is 4s before the date in the Expires cache header
> 
> Sorry to notice this! Found that, this is a patch related issue in OCSP
> server, and is being permanently mitigated. I will post an update here once
> I receive a test confirmation.

Hi Kathleen, This issue is permanently addressed yesterday night (Indian time). We have verified the same in certificate.revocationcheck.com. (However, the old checks are still giving cached responses over there. May be we have to wait till expiry time for those certs.)
Hi Kathleen, The latest CP/CPS v1.02 is published in the repository (https://repository.emsign.com/), which includes above changes, along with several other updates from compliance side). The overall changes have been verified and are inline with BR.
Hi Kathleen. Hope you had a chance to go through CP/CPS changes. It further went through revision and new version 1.03 is made available in the repository. The changes are minor and include compliance changes made in comparison with Baseline Requirements. Looking forward to hear from you.
Hi Kathleen. Just wanted to check if there was any update on our root inclusion request. If you need any clarifications, will be happy to answer that.
General Update: These roots are now available in CCADB based on Microsoft inclusion.

URL Info 
CAs may access this page via:	https://ccadb.force.com/0011J00001FxXjs
Root Store Operators may access this page via:	https://ccadb.my.salesforce.com/0011J00001FxXjs
Also,

Please explain the difference between the "emSign Root CA - G1" root and the "emSign Root CA - C1" root.

And confirm that the 4 roots that you are requesting inclusion for are:

emSign Root CA - G1 			40:F6:AF:03:46:A9:9A:A1:CD:1D:55:5A:4E:9C:CE:62:C7:F9:63:46:03:EE:40:66:15:83:3D:C8:C8:D0:03:67
RSA 2048 bits
Trust bits: Email, Websites
Enable for EV treatment

emSign ECC Root CA - G3 			86:A1:EC:BA:08:9C:4A:8D:3B:BE:27:34:C6:12:BA:34:1D:81:3E:04:3C:F9:E8:A8:62:CD:5C:57:A3:6B:BE:6B
ecdsaWithSHA384
Trust bits: Email, Websites
Enable for EV treatment

emSign Root CA - C1 			12:56:09:AA:30:1D:A0:A2:49:B9:7A:82:39:CB:6A:34:21:6F:44:DC:AC:9F:39:54:B1:42:92:F2:E8:C8:60:8F
RSA 2048 bits
Trust bits: Email, Websites
Enable for EV treatment

emSign ECC Root CA - C3 			BC:4D:80:9B:15:18:9D:78:DB:3E:1D:8C:F4:F9:72:6A:79:5D:A1:64:3C:A5:F1:35:8E:1D:DB:0E:DC:0D:7E:B3
ecdsaWithSHA384
Trust bits: Email, Websites
Enable for EV treatment
(In reply to Kathleen Wilson from comment #26)
> Vijay,
> 
> When do you plan to have period-of-time audits for these roots?

We have already appointed auditors for Period-of-time audit, and it will commence next week. We expect the closure in next 30 days.

> 
> I'm still seeing errors:
> https://certificate.revocationcheck.com/testevg1.emsign.com
> https://certificate.revocationcheck.com/testevg3.emsign.com
> https://certificate.revocationcheck.com/testevc1.emsign.com
> https://certificate.revocationcheck.com/testevc3.emsign.com
>  http://ocsp.emSign.com (GET)
>  ERROR: Response is not yet valid

Sorry to note this. We are investigating the GET module of OCSP in some of the servers. (POST module was working fine). It is resolved early morning today (Indian Time). However, team is working on permanent resolution and stability of all distributed servers, which will be completed over next 2 days. Having said this, revocation-check in GET method will continue to satisfactorily function.
(In reply to Kathleen Wilson from comment #27)
> Also,
> 
> Please explain the difference between the "emSign Root CA - G1" root and the
> "emSign Root CA - C1" root.
> 

I'm copying below the summation made by you in above comments for 4 roots.
CN=emSign Root CA - G1, OU=emSign PKI, O=eMudhra Technologies Limited, C=IN
CN=emSign ECC Root CA - G3, OU=emSign PKI, O=eMudhra Technologies Limited, C=IN

CN=emSign Root CA - C1, OU=emSign PKI, O=eMudhra Inc, C=US
CN=emSign ECC Root CA - C3, OU=emSign PKI, O=eMudhra Inc, C=US

As we can see, "emSign Root CA - G1" (and G3) is owned by eMudhra - India. Whereas "emSign Root CA - C1" (and C3) are owned by eMudhra - USA.

Quote from my earlier comment: 
"The Indian entity operates among several geographies and doesn't constrain to Indian Geography. It is dependent on the Business, Operational and Customer requirements, that Indian entity will be serving. This is the primary for global customers.

US Entity once again depends on Business, Operational and Customer requirements. Where the users specifically demand for US entity based certificates, this is serviced. From business outlook angle, this requirement is more of our users from American continents, Middle East, & European countries. But this has no TLD constrains and we wish to operate this under Global category."

>
> And confirm that the 4 roots that you are requesting inclusion for are:
> 
> emSign Root CA - G1 		
> 40:F6:AF:03:46:A9:9A:A1:CD:1D:55:5A:4E:9C:CE:62:C7:F9:63:46:03:EE:40:66:15:
> 83:3D:C8:C8:D0:03:67
> RSA 2048 bits
> Trust bits: Email, Websites
> Enable for EV treatment
> 
> emSign ECC Root CA - G3 		
> 86:A1:EC:BA:08:9C:4A:8D:3B:BE:27:34:C6:12:BA:34:1D:81:3E:04:3C:F9:E8:A8:62:
> CD:5C:57:A3:6B:BE:6B
> ecdsaWithSHA384
> Trust bits: Email, Websites
> Enable for EV treatment
> 
> emSign Root CA - C1 		
> 12:56:09:AA:30:1D:A0:A2:49:B9:7A:82:39:CB:6A:34:21:6F:44:DC:AC:9F:39:54:B1:
> 42:92:F2:E8:C8:60:8F
> RSA 2048 bits
> Trust bits: Email, Websites
> Enable for EV treatment
> 
> emSign ECC Root CA - C3 		
> BC:4D:80:9B:15:18:9D:78:DB:3E:1D:8C:F4:F9:72:6A:79:5D:A1:64:3C:A5:F1:35:8E:
> 1D:DB:0E:DC:0D:7E:B3
> ecdsaWithSHA384
> Trust bits: Email, Websites
> Enable for EV treatment

Yes.
This root inclusion request is ready for the Detailed CP/CPS Review phase, step 3 of
https://wiki.mozilla.org/CA/Application_Process#Process_Overview
so assigning this bug to Wayne.


(In reply to Vijay Kumar from comment #28)
> We have already appointed auditors for Period-of-time audit, and it will
> commence next week. We expect the closure in next 30 days.

Please add a Comment to this bug with the period-of-time audit statements are available.
Assignee: kwilson → wthayer
Whiteboard: [ca-verifying] - KW Comment #14 2018-05-24 → [ca-cps-review] - KW 2018-09-05
I have performed a preliminary review of this request and have toe following concerns:

* The CPS allows emSign to violate the BR requirements for CAA validation. Section 4.2.4 states: “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.” 
* One of the domain validation methods in CPS section 10.1 is 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.”
* CPS section 10.6 describes “Device Certificates” as “Includes TLS/SSL Certificates for internal use”, then goes 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.
* 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.
* 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” in sections 10.1-10.3 does not meet this requirement.
* CPS section 3.2.1 does not clearly prohibit the generation of key pairs for TLS subscriber certificates by emSign. This is forbidden by Mozilla policy section 5.2.
* The CPS allows “external issuing CAs” but does not clearly state that the requirements of BR section 1.3.2 will be met.
* CPS section 3.2.7 clearly defined data reuse requirements for certificate renewal. CPS section 3.2.8 implies by omission that re-keying can be done without revalidation of information even if it is more than 825 days old.

Would you like to update your CPS to address any of these concerns before I begin the public discussion?

Also, can you tell me when to expect the first period-of-time audit reports?
QA Contact: kwilson
Thanks Wayne for the detailed views. These points require compliance deliberation and result in certain text changes in CP/CPS, as our practice already adheres to these. There are no overrides in practice, even though some of these points looks to give flexibility. 

The updated CP/CPS will be put for ratification by Policy Authority and will take 2-3 days to get ratified and published.

I request you to begin the public discussion. Once repository is updated, I will update the bug with latest CPS document link during the week, which will address these points.

The period of time audit report looks to be a week away. The auditors have recently concluded the fieldwork. 

Additionally regarding audit period, I want to summarize as under for clear picture on dates:
1. Root key generation: Feb-2018
2. Point in time Audit: Feb-2018
3. Period of time Audit is for the period of Feb to Sep 2018. 

Thanks,
Vijay
(In reply to Vijay Kumar from comment #33)
> Thanks Wayne for the detailed views. These points require compliance
> deliberation and result in certain text changes in CP/CPS, as our practice
> already adheres to these. There are no overrides in practice, even though
> some of these points looks to give flexibility. 
> 
> The updated CP/CPS will be put for ratification by Policy Authority and will
> take 2-3 days to get ratified and published.
> 
> I request you to begin the public discussion. Once repository is updated, I
> will update the bug with latest CPS document link during the week, which
> will address these points.
> 
I was really asking if you would like to make changes to your CPS. I do not think it is productive to begin a discussion with changes imminent, so please update this bug when the new version has been published.

> The period of time audit report looks to be a week away. The auditors have
> recently concluded the fieldwork. 
> 
> Additionally regarding audit period, I want to summarize as under for clear
> picture on dates:
> 1. Root key generation: Feb-2018
> 2. Point in time Audit: Feb-2018
> 3. Period of time Audit is for the period of Feb to Sep 2018. 
> 
> Thanks,
> Vijay
Hi Wayne,

Sorry for the wrong interpretation. That's clear now. We wish to update CP/CPS to remove the ambiguity on highlighted sections. It is on our high priority and we are looking for publication by Wednesday. 

I will update this bug once new version is published.

Regards,
Vijay
Hi Wayne,

The CP/CPS points indicated by you have been resolved. 

This is excluding the point: [The CPS allows “external issuing CAs” but does not clearly state that the requirements of BR section 1.3.2 will be met.] The section 1.3.2 of BR looks to mention about External RAs. 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. Hence, this part is kept unchanged.

URL for latest CPS: https://repository.emsign.com/cps/CP-CPS-v1.04.pdf
Published in: https://repository.emsign.com

If this is OK, I request you to move forward for public discussion.

Regards,
Vijay
I began the discussion on the mozilla.dev.security.policy list with the following comments. I asked that emSign post links to their PoT audit reports when they become available - I will not end discussion before these are received.

==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.
* 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.
Whiteboard: [ca-cps-review] - KW 2018-09-05 → [ca-in-discussion] - ends after 1-November 2018
Hi Wayne,

There is another update made to CP/CPS and latest version 1.05 is published. The change also covers removal of the phrase 'any other reliable means' for email verification in rest of the sections. These sections were not related to certificates that contain EKU for Email Protection. And hence took additional time to conclude on an update. However, this change is ratified to remove the ambiguity in email verification mechanisms for all kinds of certificates.

URL for latest CPS: https://repository.emsign.com/cps/CP-CPS-v1.05.pdf
Published in: https://repository.emsign.com


Secondly, we have successfully completed period of time audit. I will share the URLs to these reports in 2-3 days, once they are published.

Regards,
Vijay
Thanks for the update Vijay. I have reviewed the new CPS and it satisfies my concerns.

Since this request is currently in the public discussion period, please also post this information to the mozilla.dev.security.policy thread.
Hi Wayne,

While our auditors confirmed on readiness of PoT Audit Report, we are experiencing the delays from Webtrust Seal arrival. Hence, we are unable to get a published PoT audit report. The reason I understand today about the delay is due to certain administrative procedures between CPA Canada and our Auditor, as it is our first seal.

We are expecting further updates in next couple of days, and will keep posted (and will update the Reports in public discussion).

Regards,
Vijay
Hi Wayne,

Period of Time Audit reports are attached to this bug, and also are updated in Public Discussion with necessary URL.

The reports are of 08-Oct-2018, but there was delay in publication of reports due to Webtrust seal publication delays.

Regards,
Vijay
The discussion period for this request has ended. I believe that all concerns have been resolved, so I am recommending approval of this request.

Link to the discussion: https://groups.google.com/d/msg/mozilla.dev.security.policy/dmARDUq_rPw/49RjzObVAgAJ
Assignee: wthayer → kwilson
Whiteboard: [ca-in-discussion] - ends after 1-November 2018 → [ca-pending-approval]
This request is now in step 10 of https://wiki.mozilla.org/CA/Application_Process#Process_Overview

Mozilla's process has changed from using PDF documents to directly pulling information from the Root Inclusion Case in the CCADB. So the information for this root inclusion request is now available at the following URL. Please let me know if I need to make any updates/corrections.

https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000262
Thanks Wayne & Kathleen. 

In the CCADB URL, the information is verified. We have seen one correction required, if relevant. It is mentioned as "Geographic Focus: India". We request it to be updated to Global, as our customers are spread across multiple countries.

Quote from my earlier comment: 
"The Indian entity operates among several geographies and doesn't constrain to Indian Geography. It is dependent on the Business, Operational and Customer requirements, that Indian entity will be serving. This is the primary for global customers.

US Entity once again depends on Business, Operational and Customer requirements. Where the users specifically demand for US entity based certificates, this is serviced. From business outlook angle, this requirement is more of our users from American continents, Middle East, & European countries. But this has no TLD constrains and we wish to operate this under Global category."
(In reply to Vijay Kumar from comment #49)
> Thanks Wayne & Kathleen. 
> 
> In the CCADB URL, the information is verified. We have seen one correction
> required, if relevant. It is mentioned as "Geographic Focus: India". We
> request it to be updated to Global, as our customers are spread across
> multiple countries.

OK. I changed 'Geographic Focus' to "India, Global".

Reference: https://wiki.mozilla.org/CA/Included_CAs
On behalf of Mozilla, I approve this request from eMudhra Technologies Limited to include the following root certificates:

** 'emSign Root CA - G1' (Email, Websites); EV
** 'emSign ECC Root CA - G3' (Email, Websites); EV
** 'emSign Root CA - C1' (Email, Websites); EV
** 'emSign ECC Root CA - C3' (Email, Websites); EV

I will file the NSS and PSM bugs for the approved changes.
Whiteboard: [ca-pending-approval] → [ca-approved] - Pending NSS and PSM code changes
Depends on: 1515457
Depends on: 1515465
I have filed bug #1515457 against NSS and bug #1515465 against PSM for the actual changes.
Whiteboard: [ca-approved] - Pending NSS and PSM code changes → [ca-approved] - in NSS 3.43, FF 67; pending PSM code changes
Status: ASSIGNED → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Whiteboard: [ca-approved] - in NSS 3.43, FF 67; pending PSM code changes → [ca-approved] - in NSS 3.43, FF 67; EV-enabled in FF 68
You need to log in before you can comment on or make changes to this bug.