That way, if people get multiple messages from you, they can actually verify which one is supposed to be the most recent and what your key actually should be.
That will solve your problems and let you disseminate public keys through Twitter.
That way, if people get multiple messages from you, they can actually verify which one is supposed to be the most recent and what your key actually should be.
That will solve your problems and let you disseminate public keys through Twitter.
If "don't make mistakes" was a viable solution, we just wouldn't have a whole family of problems.
> you probably should include a timestamp, an expiration for the key, a hash of the previous message so people can tell what is supposed to supercede what, etc.
An expiration for your current key doesn't _really_ help the problem of "I don't know where to get the next key from". A blockchain _in theory_ formalises the "disseminate your public key through this accessible place" (which you've defined as twitter, I might define as a CA registry that comes with browser and someone else might define as a blockchain), but this solution doesn't actually solve the problem of "the public key is different, which one do I use?" which _is_ what a blockchain does, except in reality, it's useless because when these things diverge you almost certainly look elsewhere for trust.
I will add that "don't make stupid mistakes" is a key tenet of cryptography in general - and blockchains in specific.
And where would one publish such documents, so that they would not be under the control of any single party?
If someone compromises my blockchain keys, it's about as bad as if someone compromises my website (in terms of the actual attack vectors).
And what if your use case requires you to prove to others that you (or your publisher) can't surreptitiously and arbitrarily alter the information you published?