On Mon, May 15, 2017 at 10:18 AM, Alex Gaynor via dev-security-policy <
[email protected]> wrote:
> Once upon a time I would said "yes, we should totally encourage people to
> lovingly craft their perfect trust store, to reduce their risk profile".
> Now, not so much.
>
> As we've seen in numerous discussions, customers of CAs, particularly large
> enterprises and vendors (think payment terminals) love to pick out one or
> two roots, ship them to a billion devices with no update capability, and
> then use this as an argument against improvements to the WebPKI ecosystem
> (e.g. SHA-1) or CA distrust (e.g. take a wild guess :-P). Hand crafted
> trust stores are significantly less likely to have any hope of getting an
> update than just shipping the whole Mozilla bundle. Further, with CT
> enforcement, you can get basically the same security guarantee (only certs
> I intend; +/- 24 hours) without burdening the ecosystem with your lack of
> agility.
>
> Cheers,
> Alex
An alternative solution to the ossification that Alex muses about is to
require that all CAs must generate (new) roots on some interval (e.g. 3
years) for inclusion. That is, the 'maximum' a root can be included in a
Mozilla product is 3 years (or less!)
What this does is it bounds the limit of badness (from these CAs) to 5
years. As a new CA is stood up for inclusion in Mozilla products, the
(existing) root can sign the (new) root. The third year the CA transitions
all new certificates to be issued from this (new) root, and starts the
inclusion process, so that by the fifth year, it can ubiquitously included
within Mozilla products.
That is, imagine you have the following scenario:
(old root) -> (old intermediate) -> (3 year leaf)
On Y3, you generate new root and new intermediate, and then cross-sign,
such that you have
(old root) -> (old intermediate) -> (old existing certs)
-> (new root) -> (new intermediate) -> (new leaf certs)
Sites can either rely on AIA (Ideal, but unfortunately, not yet supported
by Mozilla) or simply supply the full chain (less ideal, wasteful on
bandwidth and caching), of either
(site cert) -> (new intermediate) -> (new root) [the AIA path]
(site cert) -> (new intermediate) -> (new root) -> (old root) [the slow,
compatibility path]
The benefit here is that we can reasonably assume that the 'risk' profile
of a root is bounded to its 'acceptance within Mozilla' - here, at 3 years
of 'live' issuance, plus 2-3 years (depending on the max age of the cert)
For products that bake in roots, the CA can continue to support/maintain
them, as they essentially become 'private' PKI roots after some period of
time. Sites that need 'publicly trusted' certs, but also need to support
those old devices, can use the (new root) -> (old root) -> (older root) ->
(oldest root) [if we assume 12 year device lifecycle] - *provided* that the
new certs are supported on the old devices.
If the new certs aren't, then just cut a 'legacy' cert from the old device
- and know that Web clients cannot and should not be expected to support
these.
It forces agility into the system. The arguments against this is that it'd
be more work for the CAs (... for which I'm admittedly not sympathetic),
that it doesn't address cases where both old devices with old certs and new
devices/web users with new certs need to exist on the same endpoint (again,
I'm less sympathetic of this, in this modern age), and more work for
Mozilla (processing trust store changes). But this seems a good balance.
Most importantly, it systematically addresses the risk factors posed by
having 'ancient' roots included in modern clients - and all of those past
decisions affecting the security of up-to-date users. By ensuring agility
in the ecosystem, it substantially reduces that risk.
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
