subkey binding signature with no usage flags and/or a critical notation

[Daniel Kahn Gillmor]

On 03/14/2013 10:34 AM, Nicholas Cole wrote:

> Hints as to what a key should be used for are typically part of the User-id
> packets. 

I disagree with this pretty strongly.  User IDs are associated with
primary keys, and subkeys are also associated with primary keys.  There
is no linkage between User IDs and subkeys.

Also, a User ID is supposed to indentify the keyholder -- placing
non-identity-related text in the User ID can be problematic.

If a keyholder wants to indicate that a given subkey is for a specific
use, this should be done in the subkey binding signature; with key usage
flags if they are able to express the desired details, or with notations
(or other subpackets?) if key usage flags are insufficient.

> All the same, wanting to use one subkey for one application (email) and
> other for another service seems to me to be attempting to push the
> key-subkey framework beyond its design limitations.

This is precisely what the key-subkey framework is designed to do as far
as i understand it.  why is this pushing it beyond its design limitations?

> I *certainly* think
> you shouldn't be generating keys that have no usage flags.  That looks to
> me as if it is certain to (at best) introduce interoperability issues and
> (at worse) introduce the potential for some security-undermining errors.

Here's the concern: if we use a known usage flag, one that indicates
that keys should be acceptable in a given context, then they will most
likely be used in that context.  So if you want to add a subkey that
should *not* be used in any of those contexts, you need to ensure all
those usage flag bits are cleared.

Alternately, you can pick the broader category via the usage flag (e.g.
authentication-capablility), and supply a notation to indicate what
scope it is supposed to apply to.  If you do that, and you don't mark
the notation as "critical" then the key usage will be applied more broadly.

I don't really see a clear alternative, though i'm willing to consider
other proposals.

> At any rate, I've always thought that people would be best off generating a
> new key for each individual use (the classic case being home vs work)
> rather than attempting to do complicated operations involving subkeys and
> the like.

I think this would be a waste of the existing certification
infrastructure, and it would make it even harder to verify people across
domains.  How many fingerprints should two people need to exchange in
person to be able to identify each other online?

Practically, one fingerprint per person is about the upper limit of what
most people are willing to do.  OpenPGP's subkey mechanism permits
people to bootstrap a wide variety of keys useful for different contexts
off of a single exchange of a primary key fingerprint.

Suggesting that people maintain multiple primary keys as part of
managing a single identity seem like it would make it more difficult
for people to participate in a process that is already probably more
complicated than people want it to be.  I think that's a bad tradeoff.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1027 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20130314/53df44f7/attachment.sig>