I agree CT is off topic, but on topic to the degree to which it keeps being suggested for user keys...
On 08/19/2014 05:45 AM, Ximin Luo wrote: > I think people keep making the same mistake of treating CT as > "providing key validity". It does *not* provide key validity, nor > binding; it provides transparency *to enable systems that do provide > the former*. In other words, via the auditing and monitoring > components, then you gain "some confidence probability" that the key > is valid. .... >> (1) The web server problem: a present server needs to prove itself >> to a present visitor. Addressed by CT, etc. > CT does not address (1) any more than it addresses (2) or (3). It is > the auditing and monitoring surrounding CT that provides (1), and > even currently there are known gaps and it is only half-implemented > (no gossip protocol). As you say, "ultimately only the recipient > knows for sure which public keys are correct for the recipient". This > is true *for webservers as well*. You are making a distinction between the cryptographic log operations CT and the monitor and auditor operations. I have not heard anyone describe the monitors and auditors as "not CT". Is this semantic distinction accurate? > Overall however, this is not a cryptographic problem, but a > logistical one. (This is why I choose the term "key validity", to > distinguish it from cryptographic "authenticity" once you have > actually validated the key.) I thought the point of CT was that it is a logistical approach that includes cryptography, but it does not provide cryptographic authentication. By your distinction here, CT does provide "key validity" but not "key authenticity", yes? -elijah _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
