Hacker News Reader

Comment by rakoo | Hacker News Reader

In Certificate Transparency, a CA is responsible for sharing its issued certificates to CT. In Key Transparency, anyone can register a key for an email address; they just have to arrive first. Is there any provision for preventing squatting ?

View on HN

One of the differences between Key Transparency and other solutions is the role of certifying and logging have been separated. In other words, being in the directory does not mean the identity has been verified. The verification of control of an email address is the role of the certifier. Your requirements of the certifier are an application specific decision.

But isn't "certifying" the part that actually matters (making sure I have the right key for a persona / the right persona), and AFAICT, Key Transparency is focused on the logging aspect.

This is what I'm really not seeing in the blog post / GitHub repo; how does this actually establish trust in the received key?

(While it is true that the owner of the key can audit their account, that doesn't help a sender. Also, if watching people "verify" SSH & GPG keys has taught me anything, it's that even engineers who should know better are way too lazy.)

Ok I see, KT provides a visible log of all changes happening to a given key, but my initial question still stands: I can squat, say, eschmidt@google.com today and wait for someone to pay me a huge amount of money to give up that name ?

I'm not 100% sure, but it sounds like that's outside the scope of key transparency, and Google is envisioning that the ["certification authority that the system [represents]"][1] would verify that you indeed own `eschmidt@google.com` before letting you register an account using that address.

[1]: https://github.com/google/key-transparency/blob/master/docs/...

Ah, that's something that I didn't see at all: google would be in charge of running the KT peer for google.com, yahoo for yahoo.com, etc...

Thanks for the clear-up !

Reply on news.ycombinator.com