On Wed 2016-02-24 23:27:34 +0100, Ben Laurie <[email protected]> wrote:
> https://github.com/agl/crlset-tools (answer: yes, crlsets can blacklist on
> SPKI).
good, i'm glad to hear it.
> Surely no-one has to remember anything ... if a browser-used log logs
> a cert that is for a domain that wasn't expecting that cert to be
> issued, then action needs to be taken.
Sure, but if that action is nothing because "meh, this particular
browser-used log just hasn't rejected certs that chain back to A yet,
and we know that A is bad, so we can just ignore this leaf cert", then
we're in the situation that CT is supposed to prevent.
OTOH, If we expect all browser-used logs to immediately refuse to serve
SCTs that chain to a given root (A) whenever any of A's intermediates
(A_X) is shown to have misissued anything (how do we prove a
misissuance, as opposed to compromise or organizational failure of the
end entity itself again?), then we get to try to coordinate a new set of
multiple parties during an apparent CA compromise (logs this time, in
addition to browser vendors), and log operators themselves need to make
potentially-political decisions about which roots or intermediates to
blacklist and which to continue logging.
More generally, I'm quite concerned that we seem to be adding a second
category of log to the CT ecosystem in an attempt to have an analysis
that doesn't have this dual-CA-compromise issue.
The CT ecosystem is complicated and hard to analyze with only one kind
of log, and now it seems that we have:
* browser-used logs
* non-browser-used logs
What are the different requirements of each kind of log? What kinds of
decisions do the different kinds of log operators need to make? What
additional data structures do they need to maintain for correct
operation? How does the ecosystem as a whole depend on them doing their
specific work? what happens if they fail? what incentives do people
have to offer one kind of log or another? Do auditors need to look at
both kinds of logs, or only one?
> Eventually, presumably, everyone will get bored of taking action on
> every cert issued by the compromised CA and deal with the problem in a
> more fundamental way. Such as blacklisting the SPKI.
Who blacklists the SPKI? All browser vendors? browser-used logs?
non-browser-used logs? which SPKI gets blacklisted? blacklisting the
SPKI of the intermediate cert doesn't work if the root CA is compromised
-- the attacker can just issue a new intermediate. how many compromised
intermediates does a log need to see before it decides to blacklist the
root CA itself? Does it need to coordinate such a blacklist with the
browser vendors? with all of them, or just some of them?
sorry for being all questions and no answers, but this still doesn't
seem resolved to me.
--dkg
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
