Re: Request to Include emSign Root CA - G1, emSign Root CA - G3, emSign Root CA - C1, and emSign Root CA - C3
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
Re: Request to Include emSign Root CA - G1, emSign Root CA - G3, emSign Root CA - C1, and emSign Root CA - C3
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. > 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). > > On Thu, Oct 11, 2018 at 11:33 PM Matt Palmer via dev-security-policy < > dev-security-policy@lists.mozilla.org> 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. > > > > 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 > > > > ___ > > dev-security-policy mailing list > > dev-security-policy@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-security-policy > > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Request to Include emSign Root CA - G1, emSign Root CA - G3, emSign Root CA - C1, and emSign Root CA - C3
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. > > 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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Request to Include emSign Root CA - G1, emSign Root CA - G3, emSign Root CA - C1, and emSign Root CA - C3
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 > 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. > 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. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Request to Include emSign Root CA - G1, emSign Root CA - G3, emSign Root CA - C1, and emSign Root CA - C3
On Friday, October 12, 2018 at 6:19:52 AM UTC+8, Matt Palmer wrote: > 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 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). ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
