I'm imagining an RPC call something like:
signtext <bitcoinaddress> "MESSAGE..." ... returns signature, in some standards-compliant format, assuming bitcoinaddress corresponds to a public key in our wallet.
There should also be: verify <bitcoinaddress> "MESSAGE" "SIGNATURE" ... which return true or false or "I have no idea what the public key for <bitcoinaddress> is".
I disagree with this. Bitcoin keys should be used for one purpose only - creating bitcoins. Any other use will erode the anonymity that the system can afford.
Sounds like what you really want is GPG.
I don't see how this erodes anonymity if you don't use it.
And being able to prove that you own a given bitcoin address can be used for all sorts of interesting things for cases where you specifically do NOT want to be anonymous.
OK, I'll go along with that.
I've been thinking about this some more. Rather than sign an arbitrary message (which is generally frowned on by those smarter than me at cryptography; as I recall, a carefully-crafted message can make it easier to perform certain types of known-plaintext attacks)... um, where was I? Oh, yeah, what about adding specific RPC commands to issue a specific message? For example, if you want to prove you own(ed) a particular coin, you could issue a command something like "getproofofownership <address>". Of course, under the hood that would be implemented using a routine that signs a message string, but the contents of the message string would be under the program's control.
That would also force us to think through the specific use-cases for which this feature is needed.
What if you created a temporary key, signed the message with that and then signed the signature or the address of the temp key with your main key. Would this be more secure?