On Sun, Sep 24, 2017 at 12:40 PM, Peter Bowen <[email protected]> wrote: > > I agree that 3b potentially has a higher risk than 3z, but it has a > higher reward. 3b allows pins to continue to work even if the trust > store removes 3. It comes down to the level of protection of the root > key. If it is secure, then this provides continued compatibility > while removing the original root. The 3z option means that all pins > to the existing root break. > > This isn't really a risk for browser-based applications, after all the > browser can implement a "known bad pins" list and not enforce pinning > if all the pins are on that list or can choose to not enforce pins if > older than a certain date. However in a situation where the > application is distinct from the browser, this does not work. I > realize this isn't Mozilla (or Chrome's) problem, but it is important > to consider in the broader Internet PKI view. > > Thanks, > Peter >
Peter, Thanks for confirming that this isn’t a concern for browser-based applications. While not to suggest they are the only participant that matters in the Web PKI, I think it would be fair to say that many of the concessions and workarounds have been heretofore focused on the browser-based case. That said, I’m not sure it’s as dire as you suspect. As noted in the previous message, an adoption of 3z wouldn’t break applications pinned to 3 unless and until a root store took steps to remove. We’ve seen some platforms, such as macOS and iOS, take steps for manual whitelisting of pre-existing certs. We’ve seen other platforms, such as Windows, take steps based on timestamping or date issued. Most importantly, however, the only public discussions regarding removal have suggested a timeframe of late-2018. Applications that pinned certificates, without the ability to update in a year, are arguably outside of the scope of ‘reasonable’ use cases - the ecosystem itself has shown itself to change on at least that frequency. As such, hopefully it’s persuasive that the reward for 3b compared to 3z is not actually significant, especially for browsers, and the risk is arguably much greater. Repeating the pattern of 2z & 3z, for every root with active issuance, provides the greatest way to reduce risk for applications that have pinned and need additional migration time. Note that the plan would still suggest that all users should be moved to DigiCert-by-default, should the Symantec deal close, and 2z/3z used merely to support those cases that can concretely identify compatibility issues and need additional time to migrate. Should the Symantec/DigiCert deal fail to close, then 2z/3z, operated by DigiCert as a Managed CA, can serve to support those users who cannot migrate to other CAs/PKIs and have the critical compatibility dependency. If 3z is adopted, both sites and applications would have until late-2018 to update their pinning code, and potentially have (depending on use cases identified) as much as several years to identify and mitigate the interoperability concerns between ‘truly legacy’ (but not pinned) devices and actively-maintained clients, while the risk to users from the legacy infrastructure will be eliminated by the end of 2018. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
