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

[Nicholas Cole]

On Thu, Mar 14, 2013 at 4:02 PM, Daniel Kahn Gillmor
<dkg at fifthhorseman.net>wrote:

> 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.
>

I think we just disagree, and I completely respect your opinion and what
you are trying to achieve.  I don't (quite) see the point of having keys
dedicated to (e.g.) email vs instant messaging, but I do see what you are
trying to achieve.

Of course, you are right that UIDs attach to the primary key not the subkey.

But the second part of what you've written above is not really true.  Most
UID packets contain an email address, or things that look very much like
email addresses.  I know that email addresses are sometimes used as IDs on
different services, but it would be very possible (if you were prepared to
have different primary keys for different purposes) to specify a service
that they key was used for in the UID (either in the "email" or the
"comment" part.  There is already a huge blurring of the line between
identity and application in the UID, both by design and in use.

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?


Again, I'm not sure this is true.  The subkey was intended to do two things:

First and foremost to make sure that the same key was not used for both
signing and encryption (generally, not on an application-sepcific basis).

Second to make sure that it was possible to change encryption (and perhaps
signing) keys while preserving the trust of the primary key (in an attempt
to solve the problem of a reluctance to change primary keys every few
years).

What you are trying to do is introduce the idea of application-sepcific
keys.  It seems like a niche area to me.  Totally fine if you can achieve
it with notations, of course, but probably not something with wide
application.

I put my initial point badly, and perhaps what I mean to propose is this:

- don't get rid of the usage flags, because I think there is an importance
of saying "it's ok to use this key for encryption" or for signing or
whatever.  But make sure that your application uses BOTH the notations and
the usage flags when deciding whether to use a particular subkey for a
given purpose.  Set the critical notation bit for those subkeys that you
absolutely never want to be used outside of a specific application, and
hope that OpenPGP software respects the standard enough to ignore them.



> 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.


Well, as I say, isn't it the case that the critical notation bit achieves
this without removing the flags?


>
> > 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?


Well, this is a bigger problem with openpgp.  You are quite right.  The web
of trust has never worked quite as easily as hoped (is this related to the
Eternal September problem?) and the problem looks set to get worse if a new
key standard introduces even longer fingerprints that people will be even
more reluctant to exchange.

I don't have a solution, of course.

I completely accept that you don't want to maintain different primary keys
for different purposes.  Though just for the sake of completeness I'll
point out that you could use Trust Signatures and multiple primary keys to
achieve the effect of what you want.  Maybe.

There is a practical security point here, too.  In the real world, it would
be much easier, (for example) when leaving an employer, to leave a copy of
a primary key and subkeys than to leave a collection of subkeys (even
though I know it is technically possible.)

N.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20130314/d7680dd0/attachment-0001.html>