On Mon, Apr 2, 2018 at 11:02 AM, Julian Inza via dev-security-policy < [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. > > > > > > > > [...] 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. > Such as? > > 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/ I fail to see the issue here. Does the EU TSL prevent the issuance of intermediates? If not, then this is an entirely irrelevant point. > Confomity Assessment Bodies audits have been carried out. > > Shorter hierarchies are better maintained and generate less problems. > I see nothing to support the claim that shorter hierarchies are better maintained or generate less problems. The entire hierarchy is relevant to trust, and if there is a question about a part of the hierarchy (for example, the 2016 root), then it's necessary to excise those parts that are problematic, to ensure a reliable starting point. > 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. > I don't think this is a particularly useful framing. Indeed, it sets an unnecessary framing when, as others have pointed out, this approach has been consistently applied to both WebTrust and ETSI audited CAs. > 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. > I don't think it's particularly useful or relevant to the matter at hand, and doesn't provide new information as to the matters being discussed. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
