El martes, 3 de abril de 2018, 11:58:49 (UTC+2), okaphone.e...@gmail.com escribió: > On Monday, 2 April 2018 19:22:02 UTC+2, ramiro...@gmail.com wrote: > > El lunes, 2 de abril de 2018, 3:53:08 (UTC+2), Tom Prince escribió: > > > On Sunday, April 1, 2018 at 4:16:47 AM UTC-6, ramiro...@gmail.com wrote: > > > > I fully understand the proposed solution about 2018 roots but as I > > > > previously said some concerns arise, [...] > > > > > > > > > That is unfortunate for Camerfirma, but it is not Mozilla or this lists > > > issue. While people have provided some suggestions on how you can create > > > a root that *might* be acceptable, I don't think any of the participants > > > care if Camerfirma has a root accepted; given the issues previously > > > identified and the responses to those issues, I think a number of > > > participants would be just as happy if Camerfirma doesn't get accepted. > > > > > > > Hi Tom > > I'm just trying to provide a different scenario than create a new root. > > Sure that many participants do not care about our particular situation:-(, > > but this make a big difference for us and also for our customers. If the > > only way to going forward is to create a new root, we will do it, but our > > obligation is trying to provide a more convenient solution for Camerfirma > > without jeopardize the trustworthiness of the ecosystem. > > Creating a new root by itself will not solve anything. The problem you have > is with trust. It's up to you to offer a root that can be used as a trust > anchor. Reasons why the 2016 root has become unsuitable for this have been > discussed in detail. > > The way out can be creating a new root, but that makes only sense if/when you > are sure all problems have been solved and will not happen with the > certificates that would be issued from this new root. If you are not 100% > sure about this, the new root will most likely soon become as useless (for > thrust) as the old one. Please don't do it before you are ready. > > CU Hans
Thank Hans for your comments. Completely agree with you about that a new root by itself do not solve the problem. We have been working on those aspect detected by Wayne at the beginning of this thread. CPS issues, CAA issues..etc. So we think we are now ready to keep on with the root inclusion. Are we 100% sure ?, No one can assure that of their own systems, but we have placed controls to avoid the known problems, and detect the unknown ones. The issue now is choosing the starting point. 1.- New root 2018 2.- 2016 root, after revoke all certificates (< 100 units) and pass an "Point in Time" BR compliant audit. (Camerfirma proposal) 3.- We have send two root to the inclusion process. "Chambers of commerce root 2016", this is the root which has issue a few(4) missunsed certificates https://crt.sh/?cablint=273&iCAID=50473&minNotBefore=2011-01-01, all of them revoked. But we have sent "Chambersign Global Root 2016" as well, and this root is free of issuing errors. Our claim to the community is to use as starting point option 2 or option 3. Best Regards Ramiro _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
