[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Requiring self-signed uids? (was Re: PoP & Signer's User ID subpacket?)

Hash: SHA1

On Mon, Jul 14, 2003 at 01:39:04PM -0400, Michael Young wrote:

> I find it strange that you'd use the term "primary" for a top-level
> encrypt-only key.  It can't have subkeys; there is no "secondary".

I call it primary because 2440 calls it primary.  It doesn't matter if
there are no subkeys on it.  That's just wording.  I think we all know
what I am talking about when I say encrypt-only primary: a version 4
public key (tag 6) that is of an encrypt-only algorithm.

> > Can you explain what troubles you about encrypt-only primaries?
> Aside from being an unclean exception to a simple model :-?

I don't see exceptions here.  The model is quite clearly and simply
stated in 2440.  Any key can be of any type.  There are no exceptions.
Does this mean that there are possible arrangements of packets that
make no sense?  Sure, so don't do that.

I see your suggestion as adding an exception: any key can be of any
type, except that the primary must be able to certify.

> I think there is value in requiring uids to be self-signed.  To allow
> encrypt-only top-level keys, one has to make a special case.  Given
> that they are only very limitedly useful, I'd rather not have the
> special case.

Keep in mind that this renders valid 2440 keys invalid under 2440bis.
I can't imagine why we'd do such a thing just to gain the ability to
require self-signed user IDs.  To be honest, I've never seen an
encrypt-only primary in nature.  I know of no program that generates
them.  I've never used one except to test.  But who am I to dictate -
in the absence of an actual security-related reason - to someone else
what type of key they may have?

Note that GnuPG doesn't have any special support for encrypt-only
primary keys, but because of the nice general design of v4 keys, where
any key (primary or subkey) can be of any type, encrypt-only primaries
work just fine.  I don't have a copy of PGP handy (I'm traveling), but
I suspect that they'll "just plain work" in PGP as well.  My point
here is that it would take additional code and additional complexity
to *prevent* encrypt-only primaries from working... so why mess around
with this, especially since there is no security-related reason for

> I recognize that requiring self-signatures on uids restricts some
> otherwise valid uses, and that it doesn't provide any additional
> security given a strong trust model and a proper understanding of
> its limitations.  I still think it's worthwhile.

Allow me to restate the original problem that spawned this thread: It
would be nice to require self-signatures on user IDs.  We cannot do
that since an encrypt-only primary is unable to issue such a

So, as a solution, rather than ripping into the key construction
rules, why not just put in a line saying "user IDs and user attributes
SHOULD have a self-signature", and call it a day?

This has a few nice details:

* It doesn't render perfectly valid 2440 encrypt-only primary keys
  invalid with the swipe of a pen.

* It doesn't render perfectly valid 2440 non-self-signed keys invalid
  with the swipe of a pen.

* It accomplishes the intent of pointing out that implementations
  should really be self-signing user IDs (which they are already
  doing anyway).

Version: GnuPG v1.2.3rc1 (GNU/Linux)
Comment: Key available at http://www.jabberwocky.com/david/keys.asc