-----BEGIN PGP SIGNED MESSAGE-----
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
it?
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
self-signature.
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).
David
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3rc1 (GNU/Linux)
Comment: Key available at http://www.jabberwocky.com/david/keys.asc
iD8DBQE/E1RS4mZch0nhy8kRAvIcAKDBrriAl95R+I9w93/C62i67HTiXQCglsBK
xDKiWu0MMeNqKsLbYpDrWdk=
=clPi
-----END PGP SIGNATURE-----