> > 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 root, G3, for 25 years. And later on, when cross-signed with the old ones, we generated another certificate, this is for 5 years, on april the 10th. We realized that this certificate was not in UTF8, so decided to revoke the cert and generate a new one coded correctly on april 11th. I don´t know what else I can add to this. After posting this in the bugzilla, none replied so again assumed the explanation was enough. If additional details are needed, just ask me what you want me to provide. Regarding the cross-signing with Certinomis, I didn´t know we couldn´t do it as it´s been done for years for many CAs that want to start in the business. This has been a very common practice performed by the new CAs that have come to the market recently. When were distrusted, apart of be allowed to cross-sign with the old roots, also were suggested different options to come back to the business meanwhile the procedure for the inclusion is running, and this was one, so I don´t understand the problem this has caused. As Franck has explained they were waiting for our webtrust audit, which at least takes 2 months according to WT, so don´t know how this could be accomplished. Maybe a point in time WT audit was enough? And would be it enough for others? I don´t know but I agree with Franck with the conditions they required to us. In summary, it´s true that we have mis-issued some certificates, I´m not trying to hide anything, and just explaining what happened and what we have done to remediate the issue. Some of them were valid certificates according to the BRs but we decided to revoke them to avoid any issues, and I know this is not enough, or at least not enough for Startcom, but it´s the only thing we can do once they are issued. The majority of them were revoked timely and for some others we were waiting for the outcome of the different discussions. According to this list we´re talking about 46 certificates, and again, not excusing for the issue, this is a long run as Kathleen said. I know we don´t have the same credit than other CAs but it´s a new system with new people and just ask to let us start the race. Let me know if you have further questions or require additional information. Thanks, Kathleen _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
