On Tue, Apr 3, 2018 at 8:19 AM, ramirommunoz--- via dev-security-policy < [email protected]> wrote:
> El martes, 3 de abril de 2018, 11:58:49 (UTC+2), [email protected] > escribió: > > On Monday, 2 April 2018 19:22:02 UTC+2, [email protected] 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, [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. > > > > 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. > Ramiro, I don't think option 2 or option 3 really meaningfully address the concerns being raised here. It's unclear if you don't understand those concerns, or whether you disagree with those concerns. A root that has not operated according to expected policy fundamentally is not a good starting point for trust - there will always be a cloud of suspicion over it, that on a technical level cannot be ameliorated. In that regard, Option 1 is the only option that provides a meaningful starting point for trust going forward. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
