[openpgp] marking subkeys as constrained for specific use -- new key usage flags?

[Daniel Kahn Gillmor <[e-mail]>]

Hi good OpenPGP people--

I use both OpenPGP and OTR.  my OTR implementation has its own public key.

I can see a use case for indicating my OTR public key directly as a
subkey on my main OpenPGP key, so that anyone who knows me via the
OpenPGP web of trust could have their tools automatically authenticate
me (without having to do any of the various OTR authentication
handshakes explicitly).

I also think i would like this subkey to be unambiguously identified as
an OTR public key, so that it is not accepted for use in any other
context (e.g. it would be bad if someone who was able to compromise my
OTR client and steal my OTR key was able to use the secret key material
to impersonate me over SSH).

How could i indicate such a clear constraint?

I have a couple of ideas, and would be happy to hear people's thoughts:

A) allocate 0x40 of the usage flags [0] to mean "use in OTR".

  What kind of work needs to be done to get a new bit allocated there?
  Is allocating a new bit reasonable?

B) use the "authentication" usage flag with a critical notation.

   Since the OTR subkey is clearly used for authentication purposes,
   perhaps the right way to go is to mark the key as authentication-
   capable in the usage flags, but also add a critical notation that
   indicating that the scope of use is limited to otr.  Does such a
   thing already exist?

Option A seems cleaner to me (since no existing implementations would
mistake such a marked subkey as useful for anything else), but i worry
about how it would scale in the bigger picture -- how many such bits are
we going to need to allocate if keys can be useful elsewhere?

OTOH, maybe that's not a big deal.  And option B seems risky in the near
term -- how many OpenPGP implementations will actually respect the
critical bit and reject that subkey binding signature if they know that
they are not in the OTR context?

Suggestions?  Is there some other way i should approach this?

	--dkg

[0] https://tools.ietf.org/html/rfc4880#section-5.2.3.21