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. > > > > > [...] 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. > 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. 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. > > -- Tom
I think the Camerfirma proposed solution is as acceptable as a new root with cross certification. At the end, you trust on that specific CA either directly or through the cross certification mechanism. Cross certification generates several problems for environments not based in browsers. EU TSL (Trusted Service Status List) has been already been issued (this means the approval of a Supervisory Body). See also http://tlbrowser.tsl.website/tools/ Confomity Assessment Bodies audits have been carried out. Shorter hierarchies are better maintained and generate less problems. At the end we are dealing about how security and operational meassures are taken by a CA and how to demonstrate them to those with the power to withdraw the CA from a Trusted List. These past years european legislation regarding qualified trust services has evolved to define the European Regulation UE 910/2014 (also known as EIDAS). With that unbrella, several technical standards have been published, among them EN 319 412 and EN 319 411. Those standards include requirements from "CAB Forum Baseline Requirements Documents" and "Extended Validation SSL Certificate Guidelines". Withs those standards, Conformity Assessment Bodies (CABs) audit certification authorities. CABs also are audited by National Accreditation Bodies and their Assessment Reports are analyzed by National Supervisory Bodies, which in turn can request additional inofmation before approving the qualified status and including the CA in the TSL. This appears as an European-American confrontation. Of course, any service can be improved, and Mozilla rules for CA inclusion in the Mozilla root program conforms a consistent verification framework. But at the end, CABs also perform their duty harmonizing requirements from ETSI standards and CAB Forum requirements, to assess Certification Authorities which not only issue SSL certificates, but also natural person certificates for qualified electronic signatures, legal person certificates for qualified electronic seals, qualified electronic tiestamping, and other rlated trust services. So, one of the critical poits would be to identify what CABs are not doing well when assessing CAs. Because once CABs issue their Conformity Assessment Report stating thay some specific CA is complying with all requirements, the problem is not in the CA, is in the CAB. Sorry for this long description of the European PKI Assessment model, but I thought it could be useful. Best regards Julián Inza _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
