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

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Tue, 05 March 2013 09:42 UTC

Return-Path: <dkg@fifthhorseman.net>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81AE421F882F for <openpgp@ietfa.amsl.com>; Tue, 5 Mar 2013 01:42:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rsgR8Tl666C for <openpgp@ietfa.amsl.com>; Tue, 5 Mar 2013 01:42:09 -0800 (PST)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id D498D21F8739 for <openpgp@ietf.org>; Tue, 5 Mar 2013 01:42:08 -0800 (PST)
Received: from [192.168.13.131] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 9AFFCF979 for <openpgp@ietf.org>; Tue, 5 Mar 2013 04:42:03 -0500 (EST)
Message-ID: <5135BDE6.1070200@fifthhorseman.net>
Date: Tue, 05 Mar 2013 04:41:58 -0500
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130112 Icedove/17.0.2
MIME-Version: 1.0
To: IETF OpenPGP <openpgp@ietf.org>
X-Enigmail-Version: 1.6a1pre
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="----enig2ECKHHSAGDABWTNSASOOH"
Subject: [openpgp] marking subkeys as constrained for specific use -- new key usage flags?
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/openpgp>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Mar 2013 09:42:09 -0000

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