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, [email protected] 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. > > > > [...] A complete revocation of any SSL certificate issued by 2016 root [...] > > There are at least a couple of problems with this > 1. Revocation, while a useful tool to have, there are a number of issues > surrounding it, including distribution of those revocations. Given that the > root isn't currently trusted it doesn't make sense for Mozilla to start > trusting it but also need to ship a bunch of revocations for mis-issued > certificates from it. I do know fully understand your comment. We would like to start from the beginning with this SubCA linked to the 2016 Root. We are talking about one hundred or less certificates. This SubCA is already placed in the EUTL that’s why we insist in this solution. > 2. Given the issues that have already occured with this root, there is going > to be questions of whether all the certificates that it has issued are > properly recorded, so that they can now be revoked. No problems are open with those certificates. They are all disclosed and CT logged. > That is, given the existing issues, how can Mozilla be confident that all the > certificates will be revoked. This is not a question of willingness, but > rather capability to identify and revoke all the certificates signed by this > root. > We offer an external “point in time” BR audit to prove that this situation has been reached. > -- Tom BR Ramiro _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
