El martes, 3 de abril de 2018, 23:48:32 (UTC+2), okaphone.e...@gmail.com escribió: > On Tuesday, 3 April 2018 14:19:43 UTC+2, ramiro...@gmail.com wrote: > > 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. > > You still don't seem to understand. This is not about hoops you need to jump > through to get your root included. It is about trust and it is entirely up to > you to do whatever is needed to (re)gain that. > > You won't get any "requirements" other than the ones you already know all > about. Some people here may offer you advice they think will help you move > forward with this. But if that doesn't suit you for one reason or another > then that is just your choice, no problem. And if you do choose to follow > somebody's advice, that doesn't imply your root will be included. It's just > what they think is your best option. But as I said, creating a new root won't > help you one bit if the problems have not been solved in a way that makes > sure they won't happen again. Or if further problems will surface. > > The bottom line is nothing more and nothing less than making it sufficiently > plausible as a CA that the root you would like to see included is (and will > stay) a suitable trust anchor. How you want to do that is your decision. The > community will and can not make that decision for you. All they have for you > is feedback (see above). > > (Actually I have no idea why I'm telling you all this. You should already > understand it as a CA. Anyway, just trying to help... ;-) > > CU Hans
Thanks for you help Hans Regards Ramiro _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
