On Wed, Feb 7, 2018 at 8:18 AM, YairE via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> Hi Wyane, > resopnding to your notes: > > Section 4.9 states that in any case that Comsign is notified about a > misissuance (no matter if it was notified by a subscriber or in any other > way) Comsign shall revoke the certificate. > > I have re-read section 4.9 of the ComSign CPS and I still do not agree with your interpretation. However, I also believe that your current language complies with Mozilla policy and the BR's. It is true that we didn’t update the version number and we have corrected > it. Along with updating the CPS version management table as well. > > about the software we use for issuing certificate- As we commented on the > January Communication we didn’t issue any SSL certificate in the last years > at all – we do not plan to issue any SSL certificates in our current RSA > software – only with our new one who is under audit now. > > To recap, this inclusion request is for the ComSign Global Root CA that was created in 2011[1]. This root was first BR audited on 26-April 2015, but 36 end-entity certificates were issued prior to that time [2] (all but one has since expired). We also have some evidence [3] that ComSign received an ETSI 101 456 audit in 2012. ComSign stated “Back then it seems we didn’t have a WebTrust audit (I believe we started in 2015) but only external CPA and governmental audits as are attached already.” However, I am unable to locate any additional audit documentation covering 2011-2015. about the software we use for issuing certificate- As we commented on the > January Communication we didn’t issue any SSL certificate in the last years > at all – we do not plan to issue any SSL certificates in our current RSA > software – only with our new one who is under audit now. > 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. 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. Another unconstrained subordinate CA has been used to issue email certificates that contain encoding errors [6]. In addition, numerous problems with ComSign’s CPS have been discussed in this thread. So, like we mentioned earlier we would like to be approved in advance so we > could start issuing as soon as the new system will be in use. > 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. I would appreciate your comments on this course of action. Wayne [1] https://bugzilla.mozilla.org/show_bug.cgi?id=675060 [2] https://bugzilla.mozilla.org/attachment.cgi?id=8938861 [3] https://bug675060.bmoattachments.org/attachment.cgi?id=615121 [4] https://community.rsa.com/docs/DOC-73367 [5] https://crt.sh/?cablint=680&iCAID=1631&minNotBefore=2017-01-01 [6] https://crt.sh/?caid=14449&opt=x509lint&minNotBefore=2014-01-01 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
