usage flags for bitcoin addresses on OpenPGP keys [was: Re: human readable key algorithm]

[NIIBE Yutaka]

On 2014-01-16 at 17:00 -0500, Daniel Kahn Gillmor wrote:
> I agree with the suggestion to use a notation.  In fact, i'd rather not
> see such a key marked as authentication-capable, because that would
> imply that it should be used in other authentication contexts (like
> SSH).  I also don't think the key is really used in bitcoin in
> authentication contexts -- aiui, in bitcoin, the wallet's key is only
> used for signing an outbound transaction.  this isn't an authentication
> step, it's clearly a digital signature.
> 
> That said, it's not an OpenPGP digital signature, so maybe the
> traditional signing flag doesn't make sense either.  I certainly
> wouldn't want attaching such a key to my OpenPGP certificate to make it
> so that when i sent mail it signed my mail with my bitcoin wallet's key!

Thank you for your suggestion.  You are right (and I am a kind of
stupid to have such a strange subkey, even for my own experiment :-).

> I note that gpg's notion of "capabilities" doesn't map directly to the
> usage-flags subpacket anyway (since E maps to multiple usage flags, and
> some defined usage flags aren't settable).  I wonder if gpg should
> expose a "bitcoin address" capability (within --expert mode) and set
> such a subkey up as having no usage flags set, and a notation like:
> 
>  extended-usage at gnupg.org=bitcoin
> 
> in human-readable form, gpg could indicate this as "Usage: B"

Makes sense.  I think that no key usage flags set would be better
than newly defined key flag, because it's out of scope of OpenPGP.

I'm going to look the code for user interface when there's no key
usage flags.

By the way, let me speak about how I was stupid.  Adding a secp256k1
subkey (and upload it to keyserver), I had expected advertising my
Bitcoin address only to those who have the development version of
GnuPG.  No, I was wrong.  Keyserver didn't accept my upload.  Reading
sks-keyserver implementation (parse_ecdsa_pubkey in parsePGP.ml), it
handles curves defined in RFC6637, but fails at oid_to_psize if its
OID is not listed in RFC6637.
--