On Mon, May 22, 2017 at 12:33 PM, Gervase Markham via dev-security-policy < [email protected]> wrote:
> On 19/05/17 21:04, Kathleen Wilson wrote: > > - 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. > > Of course, if we don't require something but Google do (or vice versa) > then Symantec will need to do it anyway. But I will investigate in > discussions whether some scheme like this might be acceptable to both > the other two sides and might lead to a quicker migration timetable to > the new PKI. > (Wearing a Google Hat) This requirement is born directly out of Issues C, D and N, and indirectly out of Issues B, F, L, P, Q, T, V, W, Y. The appropriateness of validation controls depends on the policies and procedures that are established by Management, the day to day execution of this by Validation Specialists, and the technical controls and designs to detect or prevent any human error from being introduced. Understandably and obviously, domain validation represents a critical function, and the evidence and disclosures have made it clear that domain validation was not consistently followed, either from the system design or by validation specialists. Similarly, the indirect issues highlight issues with overall process design and documentation - an issue explicitly called out in the remediation of Issue D and subsequently Issue W - that raise concerns about the validation processes. To allow validation to continue as a Delegated Third Party, which is what would be necessary to permit what was described, is to bring in all of the issues raised with aspects of both oversight (now with respect to the Managed CA overseeing Symantec’s validation operations) and execution, both of which would both create opportunity for new issues and incompletely resolve existing issues. Given the nature of the integration here, we do not believe it would reasonably speed up any migration to allow what is proposed. That is, the initial efforts with respect to establishing the Managed CA infrastructure are orthogonal to the question of validation, and reflect API integrations and business contracting. This is why, as part of our proposal, issuance can proceed without forcing an immediate transition to revalidation. However, by requiring revalidation, phased in over time, there is an objective and quantifiable level of security improvement, reflected through the independence of the operation and the robust technical controls - that provides a clear and objective manner of re-establishing trust. These are incredibly important concerns for Google, as we seek to ensure that solutions to restore trust in CAs are appropriate for the nature of the concerns and reusable, in the event another CA should have issue. This represents the only way we have identified to reliably provide assurance that the validation issues have been concretely resolved, and that the policies fully reflect the Baseline Requirements both now and going forward, and with robust controls to ensure that. We are, of course, interested in if there are technical means to achieve this same result - that validations are sufficiently documented in policies, consistently executed on both a technical and procedural level, and appropriately overseen through both technical and procedural controls - in a manner that is both objective and transparent, thus reusable, and which suitably meets the needs of the broader ecosystem. We welcome any ideas that can establish this without relying solely on audits, which are demonstrably insufficient, as evidenced by the issues with respect to Delegated Third Parties, their operation, and their overall supervision. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
