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 mea
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: Identrust Commercial Root CA 1 EV Request
On Tue, Oct 16, 2018 at 02:18:39PM -0700, identrust--- via dev-security-policy wrote: > 5.Explanation about how and why the mistakes were made, and not caught and > fixed earlier. > > IdenTrust: The certificate was generated for a server within IdenTrust. > The certificate contained internal domain names which were not reachable > externally. Two domain names in the SAN (Autodiscover.identrus.int and > Mercury.identrus.int) were included at that time. When the certificate > was generated, these domains were internally hosted domains. This doesn't explain why the mistakes were made, nor does it explain why they were not caught and fixed earlier. > 6. List of steps your CA is taking to resolve the situation and ensure > such issuance will not be repeated in the future, accompanied with a > timeline of when your CA expects to accomplish these things. > > IdenTrust: Post 02/22/2018, IdenTrust implemented a change in the > certificate approval processes that will prevent the domain names with the > .int TLD from being approved. What about other non-existent TLDs? - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Identrust Commercial Root CA 1 EV Request
On Monday, October 15, 2018 at 7:15:26 PM UTC-4, Nick Hatch wrote: > On February 21 2018, I reported an unexpired certificate to Identrust which > contained SAN entries for several invalid .INT domains: > > https://crt.sh/?id=7852280 > > They acknowledged and revoked the certificate in a timely manner. However, I > find this event particularly bothersome: > > - This certificate was created for Identrust's own internal use. > - The issue of .int being a valid TLD has been communicated and well-known > since 2009 [1] > - I don't believe Identrust has disclosed this misissuance as required. > > -Nick > > [1] > https://groups.google.com/d/msg/mozilla.dev.security.policy/L9A67IryHu0/RzeaEgIjt48J Mr. Hatch is correct and although IdenTrust worked to resolve this issue immediately and responded to him accordingly, there was an oversight on our part not to file the formal misissuance report more broadly to the public forum. With our apologies, here is that report: 1.How your CA first became aware of the problems listed below (e.g. via a Problem Report, via the discussion in mozilla.dev.security.policy, or via this Bugzilla Bug), and the date. IdenTrust: We were made aware of this issue on 02/22/2018 from Nicholas Hatch via an email message to IdenTrust customer support. 2.Prompt confirmation that your CA has stopped issuing TLS/SSL certificates with the problems listed below. IdenTrust: The certificate in question was revoked on the same date, 02/22/2018 3. Complete list of certificates that your CA finds with each of the listed issues during the remediation process. The recommended way to handle this is to ensure each certificate is logged to CT and then attach a CSV file/spreadsheet of the fingerprints or crt.sh IDs, with one list per distinct problem. IdenTrust: Only one certificate was found to have SAN containing ‘.int’ domain. This certificate was issued on 5/21/2015 with cert.sh ID: https://crt.sh/?id=7852280. As noted in #2, this certificate was revoked on 2/22/2018. 4. Summary of the problematic certificates. For each problem listed below: number of certs, date first and last certs with that problem were issued. IdenTrust: Problematic certificates consists of only one certificate issued on 5/21/2015 and installed on IdenTrust server. As noted in #2, this certificate was revoked on 2/22/2018. 5.Explanation about how and why the mistakes were made, and not caught and fixed earlier. IdenTrust: The certificate was generated for a server within IdenTrust. The certificate contained internal domain names which were not reachable externally. Two domain names in the SAN (Autodiscover.identrus.int and Mercury.identrus.int) were included at that time. When the certificate was generated, these domains were internally hosted domains. When the problem was identified, IdenTrust revoked the certificate and issued a new certificate without the Autodiscover.identrus.int and Mercury.identrus.int. 6. List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things. IdenTrust: Post 02/22/2018, IdenTrust implemented a change in the certificate approval processes that will prevent the domain names with the .int TLD from being approved. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Audit Reminder Email Summary
On Tue, Oct 16, 2018 at 12:49:41PM -0700, Kathleen Wilson via dev-security-policy wrote: > Forwarded Message > Subject: Summary of October 2018 Audit Reminder Emails > Date: Tue, 16 Oct 2018 19:00:37 + (GMT) > > Mozilla: Audit Reminder > Root Certificates: >AC Raíz Certicámara S.A. > Standard Audit: > http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221203 > Audit Statement Date: 2017-08-09 > CA Comments: null It covers the period of 2016-05-01 to 2017-04-30. They should have a new audit report by now. > Mozilla: Audit Reminder > Root Certificates: >Certinomis - Root CA > Standard Audit: > https://bug937589.bmoattachments.org/attachment.cgi?id=8898169 > Audit Statement Date: 2017-07-24 > BR Audit: https://bug937589.bmoattachments.org/attachment.cgi?id=8898169 > BR Audit Statement Date: 2017-07-24 > CA Comments: null This seems to be in French, and does not seem to even indicate when the audit was done, just that the report itself is valid for 2 years. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Audit Reminder Email Summary
Forwarded Message Subject: Summary of October 2018 Audit Reminder Emails Date: Tue, 16 Oct 2018 19:00:37 + (GMT) Mozilla: Audit Reminder Root Certificates: AC Raíz Certicámara S.A. Standard Audit: http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221203 Audit Statement Date: 2017-08-09 CA Comments: null Mozilla: Audit Reminder Root Certificates: Certinomis - Root CA Standard Audit: https://bug937589.bmoattachments.org/attachment.cgi?id=8898169 Audit Statement Date: 2017-07-24 BR Audit: https://bug937589.bmoattachments.org/attachment.cgi?id=8898169 BR Audit Statement Date: 2017-07-24 CA Comments: null Mozilla: Audit Reminder Root Certificates: Go Daddy Class 2 CA** Go Daddy Root Certificate Authority - G2** Starfield Class 2 CA** Starfield Root Certificate Authority - G2** ** Audit Case in the Common CA Database is under review for this root certificate. Standard Audit: http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221042 Audit Statement Date: 2017-08-31 BR Audit: http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221042 BR Audit Statement Date: 2017-08-31 EV Audit: http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221042 EV Audit Statement Date: 2017-08-31 CA Comments: null Mozilla: Audit Reminder Root Certificates: ACCVRAIZ1 Standard Audit: http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221168 Audit Statement Date: 2017-07-28 BR Audit: http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221169 BR Audit Statement Date: 2017-07-28 CA Comments: Per CA request, Root CA Generalitat Valenciana will be removed via https://bugzilla.mozilla.org/show_bug.cgi?id=1272158 Mozilla: Audit Reminder Root Certificates: NetLock Arany (Class Gold) Főtanúsítvány Standard Audit: http://www.netlock.hu/docs/dokumentumok/Certificate%20ETSI%20ENG.pdf Audit Statement Date: 2017-10-05 BR Audit: http://www.netlock.hu/docs/dokumentumok/Certificate%20ETSI%20ENG.pdf BR Audit Statement Date: 2017-10-05 CA Comments: null Mozilla: Audit Reminder Root Certificates: CFCA EV ROOT Standard Audit: http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221153 Audit Statement Date: 2017-11-10 BR Audit: http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221154 BR Audit Statement Date: 2017-11-10 EV Audit: http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221155 EV Audit Statement Date: 2017-11-10 CA Comments: null Mozilla: Audit Reminder Root Certificates: GlobalSign GlobalSign Standard Audit: http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221087 Audit Statement Date: 2017-10-31 BR Audit: http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221088 BR Audit Statement Date: 2017-11-01 CA Comments: null ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CCADB System Upgrades October 15, 8am-6pm Pacific Time
The CCADB system updates are complete, and access has been restored to normal. Please send me email if you run into any problems in the CCADB. Thanks, Kathleen ___ 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
