Hi Yair, On Mon, Feb 12, 2018 at 11:50 AM, 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. > > This comment demonstrates a continued lack of knowledge of Mozilla requirements. Specifically, section 1.1 places these intermediates in-scope because they are capable of issuing SSL certificates, so they must comply with the BRs. 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. > > Yes, these problems were corrected after being identified by Mozilla, but that is not trustworthy behavior. How many problems remain that we haven't identified? A CA earns trust by understanding and complying with requirements without supervision. > 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. > Why is it not possible to generate a new root in the 6 months that are needed to get the new CA software fully operational? This new CA can be cross-signed by the Global Root CA for compatibility with other root stores. I do think we can place this request on hold and resume it once all information for the new root has been provided, rather than starting over again at the beginning of the process. I welcome input from others in the community who may disagree with me on this point. 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. > Please understand that this is not just about fixing the problems that have been identified. You are asking Mozilla to accept the risk created by the past decisions ComSign made. If this root is included, that risk will be transferred to Mozilla's users for many years to come, until this root is retired. > _______________________________________________ > 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
