RE: StartCom cross-signs disclosed by Certinomis
> > In this larger light, it would also seem that StartCom, having misissued a number of certificates already under their new hierarchy, which present a risk to Mozilla users (revocation is neither an excuse nor a mitigation for misissuance), should be required to take corrective steps and generate a new hierarchy that is not, out of the gate, presenting risk to the overall community due to its past misissuances. We can and should expect more of new keys being included, because the compatibility risk of expecting adherence to the Root Policy is non-existent. To me, this is very convincing that we should add the two StartCom intermediate certs to OneCRL. Along this line of discussion, I have not felt comfortable with StartCom's current root inclusion request (bug #1381406), because Hanno raised a concern about the private key used by the new root is also used by two intermediate certificates, one of them revoked. This doesn't see like good practice to me, and I'm not sure that Inigo's response is sufficient. So, I'm also wondering if I should close Bug #1381406 and request StartCom to start completely over with their new CA Hierarchy, and get it right, before creating their next root inclusion request. I will appreciate thoughtful and constructive feedback on this as well. Hi, I´ll try to clarify some of the comments here 1.- It´s true that we have miss-issued a very few number of certificates under the new hierarchy as has been posted here and even all of them are revoked, maybe it´s not enough according to some of the comments, which in other cases, as also have been expressed here, was enough. But in any case, for those mis-issued certificates, will try to explain: a.- test certificates: those were mississued certificates issued directly from the EJBCA system by the CA administrator for testing the CT log. Those certificates were valid only some minutes, they were issued, the CT tested, and then revoked. Don´t think they made any danger to the Mozilla community. These were also reflected in the webtrust audit. And after the incidence we put the countermeasures needed, not allowing to issue certificates directly. This was indicated in the bugzilla, in a detailed document. Explained what happened and why can´t happen any more. After that, none replied so assumed that the explanation was enough. b.- pre-certificates: there were 4 pre-certificates that were logged in the CTs that finally weren´t issued. I still think it could be a misinterpretation of the word intent and the binding according to the RFC but as some posted here, it´s very clear and can´t be a misinterpreation, so they were revoked inmediately when I was told it. Again, don´t think a pre-certificate could be problematic for mozilla users, but it´s my opinion. c.- mis-issuances related to the use of curves that are allowed by the BRs but not in Mozilla. There´s been a discussion about it in both forums (CABF and m.d.s.p), which has not arrived any conclusion yet (seems that Mozilla is thinking on allowing the same like the BRs if i´m not wrong). I asked personally Ryan in the last CABF F2F meeting about it and he gave me clear instructions and since then we are not allowing those curves. The countermeasure was applied into production on June 21st. All certs with these curves were revoked. Also in these ones there were some other errors related to some bit sets included in the key usages, which according to 7.1.2.4 for which the CA shall not issue unless is aware of a reason. The crt.sh tool can´t know if there´s a reason as it only checks technical stuff. So, don´t see any issue with the BRs. d.- one mis-issuance certificate with the country code wrong, used the old Zaire CC instead of the new one for the Democratic Republic of Congo. Well, for this case we didn´t have our country DB updated, we did it yesterday and also cross-checked if there were some others and realized that we had some old ones like the french and dutch antilles and missing some others like jersey and guernsey. I don´t think this is a big issue. The certificate was revoked timely. e.- misissuances related to Unicode. There were some certs with DNS not valid due to the use of their own language, cyrilic, chinese, etc. There´s been a discussion about it in the CABF, also a ballot 202 which has failed, etc. We revoked all the certs involved and updated our system accordingly adopting punnycode for all of them. Frankly don´t know if that´s the best approach. 2.- Usage of the same key. Firstly, this is not prohibited in the BRs, it´s one of the exceptions included as mentioned in the post. Maybe it´s unusual or not desiderable, but I think we didn´t do anything wrong. Our intention was to be the more accurate possible, we were allowed to cross-sign the new ones with the old ones and to avoid differences we used the same key for these cross-signatures for obtaining a certificate the most similar to the new one. So initially, with that key we created the new
Re: StartCom cross-signs disclosed by Certinomis
On Friday, 4 August 2017 03:16:45 UTC+2, Matt Palmer wrote: > On Thu, Aug 03, 2017 at 01:43:08PM -0700, Kathleen Wilson via > dev-security-policy wrote: > > However, I think it is fine for Certinomis to cross-sign with new StartCom > > subCA certs, as long as Certinomis ensures that Mozilla's Root Store > > Policy is being followed. > > ... which they didn't. So there's that. Exactly. I don't understand why this discussion seems to be about StartCom. Until they re-apply for the root program they have no direct obligation to conform to anything anymore. They may have to answer to Certinomis, depending on what was agreed with respect to the cross-signing. But that is really only relevant to Certinomis and StartCom themselves. Certinomis however, does have a root in Mozilla's root program and as such has to answer for any misissuance chaining up to their root certificate(s). In my opinion it would make more sense for Certinomis to decide that they'd better revoke their cross-signings than for Mozzilla to add them to OneCRL. Or am I missing something here? CU Hans ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
English translation for Certinomis root CP/CPS?
The Common CCADB Policy states: > CAs must provide English versions of any Certificate Policy, Certification > Practice Statement and Audit documents which are not originally in English, > with version numbers matching the document they are a translation of. The page at https://www.certinomis.fr/documents-et-liens/nos-politiques contains links to the Certinomis policies, but there is no English translation of "Politique Racine”, the CP/CPS that appears to cover the "Certinomis - Root CA” certificate. Can anyone help answer these questions? 1) Does the document titled "POLITIQUE DE CERTIFICATION AUTORITE DE CERTIFICATION RACINE” contain the policies for the Certinomis root? (https://crt.sh/?caid=5676) 2) Is an English translation available somewhere for this document but not linked from the Certinomis policy documents page? 3) If there is no English translation available, is Certinomis required to provide one? Thanks, Jonathan ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: StartCom cross-signs disclosed by Certinomis
On Friday, August 4, 2017 at 12:27:13 AM UTC, Kathleen Wilson wrote: > Along this line of discussion, I have not felt comfortable with StartCom's > current root inclusion request (bug #1381406), because Hanno raised a concern > about the private key used by the new root is also used by two intermediate > certificates, one of them revoked. This doesn't see like good practice to me, > and I'm not sure that Inigo's response is sufficient. OK, maybe I'm just not getting it but what exactly *is* the issue that was brought up in that bug? I would think that this is, as the StartCom response seems to confirm, just the way you cross-sign new roots with existing ones? Old roots signing new roots is done by other CAs as well and I'm not aware of any talk or rule that this is discouraged or forbidden? My understanding is this (please correct me if I'm wrong): Hanno's crtsh link [0] just has a spkisha256 parameter. The list contains the root's self-sign and two instances where the root was signed by an old StartCom root. I get similar output with the spkisha256 of other trusted roots, i.e.: Amazon [1]: New roots signed with old Starfield Services Root that they bought Commodo [2]: Newer roots signed with their old AddTrust Root GlobalSign [3]: R3 root signed with their R1 root How, if not like this, can roots be cross-signed at all, technically? How are the above 3 examples different from the way StartCom did it? (If they aren't, I think it's important that the record is set straight and this specific thing doesn't appear in the real or mental list of things that new StartCom did wrong... If they are, disregard of course. :-D ). [0] https://crt.sh/?spkisha256=d3b8136c20918725e848204735755a4fcce203d4c2eddcaa4013763b5a23d81f [1] https://crt.sh/?spkisha256=fbe3018031f9586bcbf41727e417b7d1c45c2f47f93be372a17b96b50757d5a2 [2] https://crt.sh/?spkisha256=82b5f84daf47a59c7ab521e4982aefa40a53406a3aec26039efa6b2e0e7244c1 [3] https://crt.sh/?spkisha256=706bb1017c855c59169bad5c1781cf597f12d2cad2f63d1a4aa37493800ffb80 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Remove old WoSign root certs from NSS
On Thursday, August 3, 2017 at 3:55:34 PM UTC-7, Kathleen Wilson wrote: > On Monday, July 10, 2017 at 12:47:31 PM UTC-7, Kathleen Wilson wrote: > > I also think we should remove the old WoSign root certs from NSS. > > > > Reference: > > https://wiki.mozilla.org/CA/Additional_Trust_Changes#WoSign > > ~~ > > Mozilla currently recommends not trusting any certificates issued by this > > CA after October 21st, 2016. That recommendation covers the following roots: > > > > CN=CA 沃通根证书, OU=null, O=WoSign CA Limited, C=CN > > CN=Certification Authority of WoSign, OU=null, O=WoSign CA Limited, C=CN > > CN=Certification Authority of WoSign G2, OU=null, O=WoSign CA Limited, > > C=CN > > CN=CA WoSign ECC Root, OU=null, O=WoSign CA Limited, C=CN > > > > This restriction has been implemented in both in the Mozilla platform > > security code (PSM), which is shared by the Mozilla applications (Firefox, > > Thunderbird, etc.), and in addition, in the NSS library code, which is used > > by applications that use the NSS certificate verification APIs. > > ~~ > > > > Please let me know if you foresee any problems with removing these root > > certs from NSS. > > > > Thanks, > > Kathleen > > > I have filed Bug #1387260 to remove the old WoSign root certificates. This > will likely happen in the October batch of root changes. > > Kathleen I suggest that Mozilla can post an announcement now about the complete removal of WoSign/StartCom to alert website developers. I suspect that a moderate amount of Chinese websites are still using WoSign certs chained to the old roots. Google posted about this complete removal here https://security.googleblog.com/2017/07/final-removal-of-trust-in-wosign-and.html And since WoSign has the most presence in China, I suggest Mozilla can instruct Mozilla China to post such announcement in Chinese as well. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
