On Sat, May 20, 2017 at 11:12 AM, Michael Casadevall via dev-security-policy <[email protected]> wrote:
> On 05/19/2017 05:43 PM, Kurt Roeckx wrote: > >>From the mail about Chrome's plan, I understand that Chrome's plan > > is to only allow certificates from the old PKI if they qualify for > > their CT requirements. They plan to only allow certificates issued > > after 2016-06-01 because that's the date when they required CT > > from Symantec. It seems that Symantec can still issue new certificates > > using the old PKI up to 2017-08-08 that are still valid for 3 > > years. > > > > I'm a little concerned that Firefox and Chrome will have different > > certificates they don't trust, and would hope that you can come to > > some agreement about when which one would get distrusted. > > > > This was likely unavoidable due to the simple fact that the > Google-Symantec discussions happened behind closed doors. Unless we can > influence Google's final policy, then this is likely going to be the > case no matter what. > (Wearing a Google Hat) As noted in the blink-dev posting, “While the plan is not final, we believe it is converging on one that strikes a good balance of addressing security risk and mitigating interruption. We still welcome any feedback about it, as prior feedback has been valuable in helping shape this plan.” >> - I'm not sold on the idea of requiring Symantec to use third-party CAs > to perform validation/issuance on Symantec's behalf. The most serious > concerns that I have with Symantec's old PKI is with their third-party > subCAs and third-party RAs. I don't have particular concern about Symantec > doing the validation/issuance in-house. So, I think it would be > better/safer for Symantec to staff up to do the validation/re-validation > in-house rather than using third parties. If the concern is about regaining > trust, then add auditing to this. > > > > The current proposal is more complicated than that since it talks about > reusing part of the original validations and OIDs to control the max > length of the certificate. I rather dislike that since its both complex, > and introduces the trust issues from the old hierarchy into the new one > which moots the point of spinning up a new root in the first place. > The Chrome plan outlined attempts to minimize disruption to site operators, as disruptions to sites are reflected as disproportionate disruptions to users, by virtue of seeing security errors. Both in discussions with Symantec and within the broadly understood operation of the Web PKI, many sites - particularly those that are engaged in automated issuance through the use of APIs - routinely replace certificates. Introducing a blocking step - the reverification of information - into obtaining a certificate, can end up creating situations where certificates are expired and not revalidated in a timely fashion. While the long-term solution for this is to require the use of standardized issuance APIs - such as the work on ACME being developed within the IETF <https://datatracker.ietf.org/wg/acme/charter/> - and to reduce both the lifetime of certificates and the reuse of validation responses - so that the difficulty in revalidating is greatly reduced, by virtue of it becoming routine and thus automated as well - these solutions are not yet widely deployed by site operators, and thus not reliable for these immediate purposes. The solution outlined attempts to find a technical solution to allow a variety of relying party applications to make trust decisions appropriate for their community, while also providing sufficient technical guidance, both as a matter of policy and expressed in the certificate, that can allow more robust controls. For example, relying party applications could choose to fully trust the existing certificate set. They could distrust those prior to 2016-06-01, and simply implicitly rely on herd immunity by virtue of Chrome’s support for CT. They could fully implement CT, and have more robust protections, such as the ability to reject redacted certificates or require the use of trusted CT logs (and not merely the presence of an SCT extension). Similarly, they can simply accept all certificates from the new hierarchy. They could accept certificates only up to the timelines proposed. They could implement different timelines entirely - although, I note, if products feel that need, we, the Chrome team, would be interested in understanding this as part of our overall effort to find an interoperable solution, if possible. For that matter, clients could decide that the risk from previous domain validations and previous organizational validations may be so large that they only accept certificates that have been fully revalidated - and the proposal provides a means and method for them to determine such certificates, in a way compatible with RFC 5280. > So they should just create new root CAs and ask them to be > > included in the root store? > > > > Honestly, we got into this mess in the first place due to third-party > signers. I don't think the right solution to stopping a gas fire is to > throw more gas on it. > The existing situation emerged from a complex number of factors, most notably, inappropriate oversight of a sprawling, complex infrastructure that had been in existence for decades. While it may seem undesirable that the solution for this involves introducing a new PKI, the proposal, as written, provides a transitional path to resolve the systematic issues with the infrastructure, policies, and issuance, on meaningful timescales, and in a way that minimizes disruption to users. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
