On Mon, Jan 15, 2018 at 4:54 PM, Eric Mill <e...@konklone.com> wrote:
> I can only go on what's on the public list, but if it is as it appears and > GS proactively researched their offering, identified a similar weakness via > a separate BR method, and voluntarily turned off their implementation right > away, that is the kind of activity I would think Mozilla and Google would > want to encourage (and not accidentally penalize). > It is certainly the minimum we (Google) would expect when CAs are notified of potential issues with validation methods :) > An X of 3 months (90 days) and a Y that resembled Let's Encrypt's > deprecation timeline, might help offer a lifeline without introducing > unacceptable risk. > Hopefully it's clear that finding a solution within that space of variables would indeed help resolve a number of the concerns. I understand that there are other factors, including the level of review > the protocol has been subject to and a holistic consideration of > GlobalSign's infrastructure and history, including non-public information, > and I'm not saying it would be necessarily unfair to keep GS' OneClick > offline for shared hosts. But I do think that incentivizing proactive > security interventions on the part of CAs is another factor worth > considering. > Indeed, it's the absence of these other details that make it considerably more difficult to find a solution to enable the issuance, and why we remain committed to working with GlobalSign to understand whether there can be a solution that meets the needs by reducing the risks. As you've highlighted, shorter lived certificates with an explicit sunset of either (correct or deprecate), are a great way to move that forward. Unlike Let's Encrypt's usage of ACME's TLS-SNI, GlobalSign is in an advantageous position of having a limited set of customers, for which they can quickly explore and roll out technical solutions - making it easier to move to the 'correct' side of the equation, rather than 'deprecate'. Similarly, it's possible that such customers may be viable under the 3.2.2.4.8 method of validation, which, while prohibiting the issuance of wildcard certificates, does represent an alternative method for validating the cloud/hosting provider meets those requirements. Unlike the discussion within the ACME WG of IETF, it may be that moving OneClick to an ALPN (RFC 7301) solution may not be viable, due to the considerations for the registry expressed within Section 6. However, it may be that alternative technical solutions exist that signal the 'opt-in' nature exist, such as the CAA list that Let's Encrypt decided against. This is the discussion, and which we welcome all participants to help us understand. Given the set of concerns, what steps can be taken to reduce or mitigate those concerns. Hopefully they're reasonably highlighted, and while there represents a bare minimum expectation of security that is unfortunately uncompromising, we are hopeful we can find a solution that works best for the ecosystem. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
