Re: Request to Include emSign Root CA - G1, emSign Root CA - G3, emSign Root CA - C1, and emSign Root CA - C3
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 On Tue, Nov 27, 2018 at 10:19 AM Wayne Thayer wrote: > 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 > >> >> ___ 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
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 ___ 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
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 ___ 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 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
Re: Request to Include emSign Root CA - G1, emSign Root CA - G3, emSign Root CA - C1, and emSign Root CA - C3
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). 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 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
Re: Request to Include emSign Root CA - G1, emSign Root CA - G3, emSign Root CA - C1, and emSign Root CA - C3
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 ___ 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
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 On Thu, Oct 11, 2018 at 2:07 PM Nick Lamb via dev-security-policy < dev-security-policy@lists.mozilla.org> 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 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. > ___ > 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 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 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. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Request to Include emSign Root CA - G1, emSign Root CA - G3, emSign Root CA - C1, and emSign Root CA - C3
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
