On 13/09/2016 16:47, Ryan Sleevi wrote:
On Monday, September 12, 2016 at 8:30:07 PM UTC-7, Jakob Bohm wrote:
A variation of this, would be to create (compacted) whitelists for
specific old intermediary certs,
It sounds like you haven't been following this conversation, but the entire
point of restarting this thread, and in the previous discussion, was that magic
(compacted) whitelists are a bit like magic beans; yes, they can solve all our
problems, but they don't exist, and so we have to decide what to do with the
remaining costs.
In this case, the fundamental concern is that a whitelist of certs is too
large, even compacted, and probabilistic structures are also too large and too
risky when compacted to a desired size.
So we end up with alternative whitelists, such as what I proposed.
Which is exactly the proposal i referred to as "compacted whitelists".
then tag the CA root as requiring
other measures (such as CT) where not overridden via whitelisting.
That way, the CA cannot bypass the measure by creating new intermediary
certs for which no trust restrictions exist.
This is literally part of what I proposed. "It could be combined with, say,
requiring CT for new certs."
My small suggestion was to reverse part of the logic, regarding which
intermediaries are the special case, and which are the "common" case
for the CA. As a simplification that might be easier to implement in
multiple browsers and other clients.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
