[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PoP & Signer's User ID subpacket?
-----BEGIN PGP SIGNED MESSAGE-----
"David Shaw" <dshaw@xxxxxxxxxxxxxxx> writes:
> Do I strongly care about encrypt-only primaries in particular? Not
> really. I do care about clean design, though, and adding a special
> additional "no encrypt-only primaries" rule on top of the current
> clean primary/subkey design seems without clear benefit.
I think that the rules are cleaner without encrypt-only standalone
keys: "Every key has a primary that can sign and any number of subkeys
(of any type)." Just one rule, no special cases, nothing "on top".
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".
> Can you explain what troubles you about encrypt-only primaries?
Aside from being an unclean exception to a simple model :-?
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
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. [Note that the same is
true of the signing-subkey problem. I acknowledge that the problem
was more serious there, and the uses of non-owned subkeys are more
limited. (By the way, I like David's signature-in-a-subpacket
solution.) The same is also true of the requirement that a key have
at least one uid.]
Hal observed that all *existing* encrypt-only algorithms really can
support signing anyway. Who knows whether that will hold up over time?
If we're convinced that it will, I'd rather remove the encrypt-only
notion from the algorithm entirely (putting it in the key preferences
-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3
-----END PGP SIGNATURE-----