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 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy