On Mon, Feb 12, 2018 at 1:50 PM, YairE via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> Hi Wayne, > Please realize our situation versus the Israeli market. We are the major > certificate authority and we comply with every piece of local regulation, > we are also members of international forums and trying to establish a CA in > the UK with a new "international" root (Comsign International).This is our > long term plan. > Meanwhile we are in a tough task to move from the RSA old and unsupported > CA software to a new MS CA. It isn’t simple and involves many aspects, > locally and internationally. On the same time, we try to be certified to > eIDAS in order to be included in the European Trust list. > Mozilla is a mile stone that we MUST pass once and for all, as it prevents > and holds us from supplying a lot of signing services to the Israeli > market, especially the increasing requests for services over the mobile. > So, while we try to go "hand by hand" with you and with the BR, if you now > send us back with the ROOT we have, it actually eliminates all the work we > are doing to be complied with Mozilla for a long period of time, as you > mentioned in your message. We can estimate that we will fully switch to MS > within 6 months or so, mainly because we wait for the final audit and the > approval of the Israeli Ministry of Justice, but if, as you suggest, you > do not trust the ROOT (not only the CA software in which we are all on the > same page with you), it is a much bigger problem, as you understand the > meaning of such severe conclusion after all our efforts we did with Mozilla > not to speak about the damage to our reputation that such a decision > creates. > > That was the background. For the essence: > 1."ComSign Global Root CA that was created in 2011 was first BR audited on > 26-April 2015, but 36 end-entity certificates were issued prior to that > time, all but one has since expired)." > >>This one certificate expires at 3/2018 and we commit not to issue new > SSL certificates until we are authorized with the new MS CA. However this > point should not affect the integrity of the entire Root. > > 2."However, am unable to locate any additional audit documentation > covering 2011-2015.". > >>We've asked the auditor (CPA Shefler which is approved by Webtrust from > ~mid 2015) to send us all the audits reports. As is already disclosed this > ROOT has passed many Webtrust audits over the last years and can be > considered audited –we have already disclosed all the certificates that > were issued prior to our first Webtrust as you have asked earlier on this > thread. > > 3."ComSign stated that they are currently using “RSA CA 6.7 on Solaris” to > issue certificates. This version has not been supported since July 2013 > [4]. This implies that all 36 certificates were issued using unsupported CA > software." > >>Correct. Wrong decision of Comsign, which we apologized for. However, we > still believe is should not affect the entire ROOT. > > 4."I’ve discovered that ComSign recently issued two new unconstrained > subordinate Cas [5] from this root that contain a non-critical > basicConstraints extension in violation of BR 7.1.2.2. > >>While we appreciate your point here, these subCA's are not issuing SSL > certificates at all but client certificates only. We cannot revoke these > subordinates that serve hundreds of thousands of customers. However, if you > approve our root – we commit to disclose the new SSL subCA before we issue > new SSL certificates, while we keep the BR rules strictly of course. > > 5."Another unconstrained subordinate CA has been used to issue email > certificates that contain encoding errors [6]." > >>That subCA does not issue SSL certificates as we mentioned above, the > encoding error was corrected long ago and is linked to the RSA software > that we are replacing in any case. > > 6."In addition, numerous problems with ComSign’s CPS have been discussed > in this thread". > >>All these problems were corrected by us and approved by Mozilla > representatives. > > 7."While I appreciate ComSign’s efforts to resolve issues that have been > identified, new ones continue to be found. I am not at all comfortable > recommending that this request proceed at this time, and I have also lost > confidence that trust can ever be established for this root given its > history. I support Ryan’s recommendation that this request be denied and > that ComSign be asked to submit a new root containing a new key pair that > has not been used with their outdated CA system." > >>As we understand Ryan’s recommendation, after we accomplished almost all > the points of rejection, is that Ryan recommends to wait for the new MS-CA, > but Ryan did not express mistrust of the ROOT. > We fully understand the points that both you and Ryan made, but to throw > the root back now, will be like starting everything from the beginning all > over again and will take long precious time. > We suggest that we keep working on this root and fix all that still needs > to be fixed. > As for the CPS, we should be totally compliant now. > As for the CA software we will enclose all the relevant details as soon as > we finish our preparations and auditing. > > We ask you to reconsider this ROOT approval request. > Note: On 2016-02-04, I recommended that new trust not be granted and that all trust in ComSign be removed - https://groups.google.com/d/msg/mozilla.dev.security.policy/uTBDhqO_IB0/bGWV7_lwBAAJ While the inclusion request has continued, the nature of the issues and the question about the provenance have me fully supporting Wayne's recommendations. That is, if any new ComSign root is to be trusted, then ComSign MUST address the infrastructural issues discovered, must transition to a CA fully compliant (and note that CAs running on Microsoft's Certificate Services platform have, historically, failed to comply with industry changes in sufficient time, so switching to MS does seem a potentially risky change), and only when new keys are generated and a new hierarchy, unblemished by the many issues discovered, should we consider trusting it. This is entirely consistent with the advice given regarding other CAs applying for inclusion or renewal that have had substantial issues, and for existing CAs that have demonstrated patterns of issues. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
