4 ms·

This is a great nearly 20 year old idea. There is at least one major flaw, which is that GPG keys can and often do expire, and this presumes “live” verificatio

This is a great nearly 20 year old idea. There is at least one major flaw, which is that GPG keys can and often do expire, and this presumes “live” verification of comments and a single global GPG key associated with a domain. So once you replace the master GPG key for your domain, your old comments will flag as invalid/unverified. One solution would be to have the domain able to list an arbitrary collection of keys (including old ones) rather than a single. Another would be to have one or more trusted sources of archival keys, which could be delegated from your domain with a different link rel. The verifier could make a time bounded request for the domain key from a compliant key server (this would have to be added, right now I don’t think the idea of a domain pgp key exists). Another solution is simply for the comment publisher to store the fact that the comment was verified and shown it “verified” henceforth. Live verification would disappear as an option once the key expires. This is probably “good enough”.

exabrial 3y ago
CAs sort of have the same problem. You can condense the problem to a subset of keys though with a verification chain. When posted, a sequence number + key + msghash + verification result + last verification result is posted publicly. That makes a block. I supposed we could call that a blockcha.... dangit. I almost said the forbidden word.
- hooverd 3y ago
  There's dozens of good uses for, ahem, chains of blocks. Unfortunately they aren't the ones that get implemented. Maybe if there was some sort of token in the mix.
rgoulter 3y ago
> There is at least one major flaw, which is that GPG keys can and often do expire, ... So once you replace the master GPG key for your domain, your old comments will flag as invalid/unverified. e.g. GitHub shows whether commits have been signed by GPG. An expired key doesn't necessarily need its secret replaced. The key can just have its expiry date extended.
noman-land 3y ago
This is why PGP subkeys are the way. You can easily expire/extend/revoke subkeys and create new ones attached to the same master key. Re-uploading a new public key with the updated subkeys allows for verification of all historical keys.

exabrial 3y ago

CAs sort of have the same problem. You can condense the problem to a subset of keys though with a verification chain. When posted, a sequence number + key + msghash + verification result + last verification result is posted publicly. That makes a block. I supposed we could call that a blockcha.... dangit. I almost said the forbidden word.

hooverd 3y ago
There's dozens of good uses for, ahem, chains of blocks. Unfortunately they aren't the ones that get implemented. Maybe if there was some sort of token in the mix.

rgoulter 3y ago

> There is at least one major flaw, which is that GPG keys can and often do expire, ... So once you replace the master GPG key for your domain, your old comments will flag as invalid/unverified. e.g. GitHub shows whether commits have been signed by GPG. An expired key doesn't necessarily need its secret replaced. The key can just have its expiry date extended.

noman-land 3y ago

This is why PGP subkeys are the way. You can easily expire/extend/revoke subkeys and create new ones attached to the same master key. Re-uploading a new public key with the updated subkeys allows for verification of all historical keys.