On Thu, Feb 2, 2017 at 11:33 AM, Eric Rescorla <[email protected]> wrote:
> If CAs do not log (either maliciously or through mistake), then it is > necessary for RPs to refuse to accept certificates which are not > logged. However, as long as we believe that the logs behave correctly > (specifically, they never sign an SCT that they don't then log) then > all that is required is that a certificate contain SCTs from some set > of logs and that RPs check that. This is roughly CT as Chrome > proposes to implement as of end-of-2017. Note that the Merkle tree > infrastructure is not needed here at all. > I believe you meant end-of-2016, but given that Chrome hasn't made the statement you're attributing, it's not fair to say "proposes to implement as of end-of-2017." > The final case is the one where logs are also malicious and collude > with a malicious CA to issue an SCT for a certificate but not to log > it. In order to detect this, you need to ensure that RPs have the same > view of the log structure as auditors do, because otherwise the CA can > issue a certificate which will be acceptable to the RP but will never > be audited [0]. The general notion for current CT is that there is > some notion of getting global consensus on the state of the log and > then the auditors and the RPs can know that they are checking the same > thing. This is where the Merkle tree infrastructure comes in (though > as I indicated previously, Richard and I do not believe it adequately > addresses this case). > It's unclear to me, from your remarks and Richard remarks earlier, whether you believe this goal is explicitly not achieved under the current proposals. It seems that you accept the current proposal actually does address this, but that you're unhappy with there being any window between issuance and global consensus. That is, there's agreement that the current model provides detection under a certain set of bounded constraints, but you want to reduce that. The rest of Richard's message seems to focus on whether the system is believed to be sufficiently scalable, but I don't know that there's consensus with Richard's assertion - that is, that CT is too inefficient to be deployed at scale. Indeed, much of the calculation seems to be based on an assumption of a design that tightens the detection window, rather than alternatives; the point being that the inefficiency Richard notes is itself an issue with Richard's proposal, not an intrinsic property.
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
