I think you'd want to have a regular public key change, where the user creates a new public key, signs it with their old key. This way key change does not suggest possible ownership change. Then to effect a nym transfer, the new public key is instead chosen by the new owner, and the old owner signs it. This still leaves the problem of the old nym revealing a previously unpublished identity revocation, or simply some signed statements which are damaging to the nyms reputation. Some ideas on this: - introduce a time-stamping service for certification signatures only (explicitly not for documents) - re-define valid certificate signatures to be signatures made on public key and identity pairs within the validity period of a key - publish signature private keys after expiry. Now anyone can create nym revocation with old keys, and so no reputational damage can be done by the old owner with nym revocations. The time-stamper will not assist in signing arbitrary documents, and so the old nym owner can not use it to prove a document was signed during the validity period of the key. (Were it signed after the validity period it would anyway not be considered a valid signature). Where general document signing time-stamping is used, to prevent post-sale nym reputation suicide, the new owner could demand all past signed messages and verify them against the merkle hash tree master hash maintained by the time-stamper, and vet the messages as not damaging to the nyms reputation. For private encrypted messages the nym would not like to share, even after nym sale, a non-transferable signature scheme could be used, with the time-stamper having a separate hash-tree for such signatures. The new owner would be somewhat assured that the old owner could not have any signatures that he can both prove the time of authorship of and transfer. The availability of third party time-stamping services, and other simple methods of dating documents (pre-published hash, 3rd party vouching for time of authorship) limits the assurances provided by the above approaches. Another avenue might be designated verifier signatures where the signature sheme necessarily requires collaboration of a verifier, and the verifier will take instructions from the current owner. Or better where only the current owner in collaboration with the designated verifier can assist a user in verifying a signature. (eg using pro-active security to re-split the key on nym sale so the old owner isn't able to collaborate in verification). In this way the new owner gets to vet which signatures the public can verify. Adam On Fri, Nov 30, 2001 at 01:56:52PM -0800, Wei Dai wrote:
On Fri, Nov 30, 2001 at 04:28:58PM -0500, Adam Shostack wrote:
Following which, Alice pulls out the pre-dated revocation certificate, and generates confusion as to the validity of Bob's key change message.
I guess we would need a distributed public registry of key change/revocation messages that guarantees only one such message will be posted per key, and any revocation messages not posted to this registry would be ignored.
Again, I don't think reputation capital is the best solution to the problem that it tries to solve. I'm just trying to defend it against the charge that it's a nonsensical idea. I still propose b-money as a better alternative. Maybe Tim has found an even better solution, and if so I certainly look forward to seeing it.