Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Jon Callas <jon@callas.org>
In-Reply-To: <6F1173CD-290C-4A38-BD80-152C5E553D1F@jabberwocky.com>
Date: Tue, 5 Mar 2013 08:10:30 -0800
Message-Id: <B18461E9-7F88-4B85-AAD7-83E31C79DBD4@callas.org>
References: <5135BDE6.1070200@fifthhorseman.net>
 <6F1173CD-290C-4A38-BD80-152C5E553D1F@jabberwocky.com>
To: David Shaw <dshaw@jabberwocky.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Cc: IETF OpenPGP <openpgp@ietf.org>, Jon Callas <jon@callas.org>,
 Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Subject: Re: [openpgp] marking subkeys as constrained for specific use -- new
 key usage flags?
Precedence: list

On Mar 5, 2013, at 7:19 AM, David Shaw <dshaw@jabberwocky.com> wrote:

>=20
> I'd do this with a notation (option B, which can be marked as critical =
if you desire).  The Usage flags are helpful but I don't think they have =
the ability to carry enough information to really state what you are =
trying to say.  Usage is more "this key can may be used for =
authentication", and it sounds like what you're looking for is "this key =
may be used for authentication, but only in the context of OTR".

Usage flags are there for broad declarations. For example, so that you =
use an RSA key for encryption but not signing, or a signing key for =
authentication-based signing, but not documents.

If you're really going to put protocol-specific notes in, then notations =
are the way to go.

>=20
> I can't speak for all OpenPGP implementations, but GPG will correctly =
reject a subkey binding signature if it has a critical notation that GPG =
doesn't know about.  I'm not sure if that helps or hurts your plan, =
though, as without adding code to GPG to understand your notation, you =
won't easily be able to show a connection from your OpenPGP key to the =
OTR subkey.

There's a problem with criticality as a concept in general, and that is =
that if you really do private development, it can cause things to =
explode in ways that are not useful.

In this case, we have an authentication-only subkey that's intended to =
be used for OTR. If you mark it as authentication-only, it's not going =
to be used for document signing, which is really what you want. It's =
possible that some other authentication protocol could grab it, but is =
that really a problem?

This brings us to the problem with criticality. It's supposed to keep =
some item from being used in an unknown way. But it can also fail in =
unexpected ways. I've seen criticality flags cause all sorts of weird =
issues in other systems, and the usual fix is not to make it critical.

	Jon