Request to Include emSign Root CA - G1, emSign Root CA - G3, emSign Root CA - C1, and emSign Root CA - C3

[Wayne Thayer]

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.
* 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

[Nick Lamb]

On Thu, 11 Oct 2018 13:06:46 -0700
Wayne Thayer via dev-security-policy

<dev-secur...@lists.mozilla.org> 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

I would like to read more about eMudhra / emSign.

I have never heard of this entity before, perhaps because they're
Indian (if I understand correctly) but perhaps because they're just
entirely new to this business.

Of course just being new isn't inherently disqualifying, but it'd be
good to understand things like:

- Who (human individuals) is behind this outfit, are there people we've
dealt with before in any key roles? (For example I hope we can agree
that individuals from previously distrusted CAs as leadership would
be a potential red flag) Are there people involved who've done this or
something similar before?

- Does this entity or a legally related entity already operate a
business in this space that has a record we can look at such as:
Indian RA for another Certificate Authority, CA in another PKI, or
more distantly somewhat similar businesses such as making identity
documents, or payment card systems.

- How did they come to decide to set up a new root CA for the Web PKI?

Running a trustworthy CA is pretty hard, so I am at least a little bit
sceptical of the idea that people I've never hard of can wake up one
morning and decide "Hey let's run a CA" and do a good job, whether in
India, Indianapolis or Israel.

[Wayne Thayer]

Nick - I expect an emSign representative to respond to all of your
questions, but their information request indicates that they have been
operating the Indian Government Root for more than 10 years and have issued
over 35 million certificates:
https://bug1442337.bmoattachments.org/attachment.cgi?id=8955223

- Wayne

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Matt Palmer]

On Thu, Oct 11, 2018 at 01:06:46PM -0700, Wayne Thayer via dev-security-policy wrote:
> * 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.”

To put it mildly, I'm not a fan of "our CPS says X but we promise to follow
the BRs instead". The list of "Bad" items you enumerated, which were all in
the CPS and were fixed up (presumably) as a result of someone external
(possibly you?) going through the CPS and saying "that's not compliant, and
that's not compliant" shows the benefit of explicitly describing practices
in the CPS, rather than just pointing at the BRs and saying "we do that".

Given that we've just recently had an incident caused by a CA's
misunderstanding of the BRs, anything which increases the chances of
identifying a CA's misunderstanding early (by, for example, explicitly
describing their practices in their CPS) would seem like a good thing.

- Matt

[Matt Palmer]

On Thu, Oct 11, 2018 at 02:36:18PM -0700, Wayne Thayer via dev-security-policy wrote:
> Nick - I expect an emSign representative to respond to all of your
> questions, but their information request indicates that they have been
> operating the Indian Government Root for more than 10 years and have issued
> over 35 million certificates:
> https://bug1442337.bmoattachments.org/attachment.cgi?id=8955223

The phrasing in the paragraph (I think) you're referencing is ambiguous:

> eMudhra has been a licensed CA under Controller of Certifying Authorities
> which operates the Indian Government Root for more than 10 years

I'm not sure whether it's eMudhra or the "Controller of Certifying
Authorities" which has been operating the Indian Government Root for more
than 10 years. At any rate, I can't seem to find any information about this
"Indian Government Root", how it works, what it's used for, and what its
criteria are, and so it's a bit hard to tell whether it's anything to be
particularly proud of.

If eMudhra *have* been in the CA business for 10 years, but they still
managed to produce a CPS with the extensive list of "Bad"-grade practices
you enumerated in your opening e-mail, that's... not encouraging.

- Matt

[Samuel Pinder]

Visiting the www.emsign.com homepage brings up a list of proposed products.
Currently, in the "Types of Certificate" table halfway down the page is the
following:
Wildcard SSL - OV
Wildcard SSL - EV
UCC Wildcard SSL - DV
UCC Wildcard SSL - OV
UCC Wildcard SSL - EV

That's not a good sign at all, since two of those imply EV and wildcard as
a single product. EV certificates cannot contain wildcards! This has always
been the case so why is this company, claiming 10 years experience, making
a mistake like this to propose such a product?
Sam
P.S. Sorry I don't contribute as much as I could, I do monitor this list
and read through regularly however.
Source: http://web.archive.org/web/20181011224402/http://emsign.com/ (Saved
to Web Archive in case the page is changed after this is pointed out).

[vi...@emudhra.com]

Hi Matt, To clarify, We do not mean that 'the text in CP/CPS deviates or violates BR, but BR still supersedes'. The clarification to Wayne was mentioning that there was reasonable definition provided on these parts. But if there is something insufficient in definition, we still stick to BR.'

The fixes made in CPS is not because of wrong practice, but the definition allowed ambiguity to an external reader (which gave a sense to external reader that we use something extra that violates BR).

[vi...@emudhra.com]

On Friday, October 12, 2018 at 5:07:55 AM UTC+8, Nick Lamb wrote:
> On Thu, 11 Oct 2018 13:06:46 -0700
> Wayne Thayer via dev-security-policy
> <dev-secur...@lists.mozilla.org> 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
>
> I would like to read more about eMudhra / emSign.

I'm from eMudhra. There is more information available about us at www.emudhra.com (corporate website) and www.e-mudhra.com (Indian CA website).

>
> I have never heard of this entity before, perhaps because they're
> Indian (if I understand correctly) but perhaps because they're just
> entirely new to this business.
>
> Of course just being new isn't inherently disqualifying, but it'd be
> good to understand things like:
>
> - Who (human individuals) is behind this outfit, are there people we've
> dealt with before in any key roles? (For example I hope we can agree
> that individuals from previously distrusted CAs as leadership would
> be a potential red flag) Are there people involved who've done this or
> something similar before?
>
> - Does this entity or a legally related entity already operate a
> business in this space that has a record we can look at such as:
> Indian RA for another Certificate Authority, CA in another PKI, or
> more distantly somewhat similar businesses such as making identity
> documents, or payment card systems.
>
> - How did they come to decide to set up a new root CA for the Web PKI?
>

We have been operating PKI since last 10+ years in India. But this was not a complete Webtrust audited setup. Rather, it is under Government of India. We are also chair of India PKI Forum, as well as vice chair of Asia PKI Consortium working on PKI regulation, adoption and awareness, predominantly for client certificates. We also do TLS certificates under India, but limited for a few government requirements. We also work with several PKI implementation and operation in Africa, Middle east, etc.

emSign is an initiative with our roots (new) audited under Webtrust, and intends to issue TLS in India and Rest of the World. This setup is separate from our Indian CA setup.

[vi...@emudhra.com]

On Friday, October 12, 2018 at 6:33:53 AM UTC+8, Matt Palmer wrote:
> On Thu, Oct 11, 2018 at 02:36:18PM -0700, Wayne Thayer via dev-security-policy wrote:
> > Nick - I expect an emSign representative to respond to all of your
> > questions, but their information request indicates that they have been
> > operating the Indian Government Root for more than 10 years and have issued
> > over 35 million certificates:
> > https://bug1442337.bmoattachments.org/attachment.cgi?id=8955223
>
> The phrasing in the paragraph (I think) you're referencing is ambiguous:
>
> > eMudhra has been a licensed CA under Controller of Certifying Authorities
> > which operates the Indian Government Root for more than 10 years
>
> I'm not sure whether it's eMudhra or the "Controller of Certifying
> Authorities" which has been operating the Indian Government Root for more
> than 10 years. At any rate, I can't seem to find any information about this
> "Indian Government Root", how it works, what it's used for, and what its
> criteria are, and so it's a bit hard to tell whether it's anything to be
> particularly proud of.

Controller of Certifying Authorities is a government body defined under Indian Information Technology Act. We operate under the license of them. The work we have done so far is more on client certificates. (www.cca.gov.in)

We have been partner for Indian Tax system (Income Tax and GST) and also the company law filings to enable paperless filings through trusted client certificates. The CA Operation undergoes stringent audit measures imposed by the Government on annual basis, in addition to regular internal audits.

emSign are the new roots intended for issuance of TLS, Code Sign (and client) certificates. This has undergone Webtrust audits by BDO.The roots are currently trusted in Microsoft root program. In progress in Mozilla, Apple and others.

[vi...@emudhra.com]

On Friday, October 12, 2018 at 6:47:12 AM UTC+8, Samuel Pinder wrote:
> Visiting the www.emsign.com homepage brings up a list of proposed products.
> Currently, in the "Types of Certificate" table halfway down the page is the
> following:
> Wildcard SSL - OV
> Wildcard SSL - EV
> UCC Wildcard SSL - DV
> UCC Wildcard SSL - OV
> UCC Wildcard SSL - EV
>

That's an unfortunate design issue. We acknowledge the mistake!

We are not currently active on Online request acceptance. This is just an information website and put up by our design team. Merely as a material of presence. Being a "coming soon" website, it did not undergo detailed checks. (Got this corrected now after you pointed this.)

We just completed our Period-Of-Time Audits which will enable us to issue live certificates shortly. The online (and offline) certificate request acceptance system will come live soon, which undergoes stringent checking measures by PA.

We are apologetic for this oversight design issue.

[vi...@emudhra.com]

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.

[Vijay Kumar]

There is an update made to emSign CP/CPS and latest version 1.05 is published.

The change covers more clarity on email verification methods. It also covers couple of structural updates to CP/CPS in line with RFC 3647. (Change History is part of the document, at the end.)

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

[Vijay Kumar]

Hi,

Happy to inform the availibility of Period of Time Audit reports. The audit reports are dated 08-Oct-2018, and the corresponding Webtrust seals are available at https://repository.emsign.com

Links to individual audit reports.

WebTrust CA: https://bugzilla.mozilla.org/attachment.cgi?id=9027883
WebTrust SSL Baseline w Net Sec: https://bugzilla.mozilla.org/attachment.cgi?id=9027884
WebTrust EV SSL: https://bugzilla.mozilla.org/attachment.cgi?id=9027885

These attachments are also part of the parent bug ID 1442337.

Regards,
Vijay

[Wayne Thayer]

I've reviewed the updated CPS and these period-of-time audit statements - I
have no concerns with them.

I believe that emSign has also addressed all the other comments that have
been made on this request.

Unless additional concerns are raised, I plan to end this discussion on
Friday 30-November.

- Wayne

[Wayne Thayer]

I have update the bug [1] and recommended approval of this emSign root
inclusion request.

- Wayne

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1442337