One probably stupid idea on this *G*
On Wed, Jan 28, 2009 at 7:48 PM, "Hal Finney" <hal(_at_)finney(_dot_)org> wrote:
5) Chapter 5.2.3.3. also says what should happen when multiple
self-signatures are encountered by an implementation.
Wouldn't it be more secure to require that ONLY the most recent self
signature of a given type (per primary key in the case of 0x1F, per
User ID in the case of 0x10-0x13 and per subkey in the case of 0x18)
may be used and if that one could not be parsed (e.g. because of
unknown subpackets with the critical bit set) no self-signature MUST
be considered as valid?
I would encourage you to consider this design concept in your software.
I thought about how this "issue" could be solved with the current
means of the standard. I mean how can I secure that only the most
recent self-signature (no matter whether 0x10-0x13, 0x1F or 0x18) is
used by ANY conforming implementation.
Perhaps this is really stupid, so better sit down ;-)
What if I'd revoke the old self-signatures to mark them clearly as
superseded and to force ANY conforming OpenPGP implementation not to
use them.
0x10-0x13 self-sigs could be revoked with a 0x30 certification
revocation signature
0x18 self-sigs could be revoked with a 0x28 subkey revocation signautre
0x1F: which one would I have to use for that? A 0x20 key revocation
signature? Or would the completely revoke the whole key.
What would be the most fitting reasons for revocation?
For 0x10-0x13 probably 32 (user id information no longer valid), but
for the others? Or should one use 0 (no reason specified).
Does the whole thing make sense anyway? I mean would it be a clean or
at least working way to force ANY implementation to use only the most
recent self-signatures?
Would it work with the mayor implementations, PGP and GnuPG?
Lots of thanks for your comments and ideas,
Peter :-) *who is now going home*