lhshas at googlemail.com
Mon Apr 14 16:46:33 CEST 2008
I've got some questions...
1) When creating a new UID, why does gpg have a minimum size of 5
characters? This is not imposed by RFC4880? Where can I report this bug.
2) I have a key that is already published to keyservers. Unfortunately it
uses old SHA1 as hasing algorithm.
Now I want to recreate the selfsignature (but using SHA512) and mark the old
selfsignature(s) (the 0x13's on my UIDs) that they _can_ not longer be used.
Most OpenPGP would simply only use the newer self-sig (according to the
creation time) but RFC4880 says that an implementation might use any other
means to resolve ambiguites so just having to self-sigs published doesn't go
far enought for me. I want the old selfsigs revoked (btw: what would be a
good reason for revocation?) and have a new self-sig on the (same) UIDs.
Main reason for this is probably to prevent downgrade attacks or similar
While the standard seems to allow this,.. gpg does not (it won't sign a UID
when the a self-sig has been revoked before).
How can I solve this?
3) On an existing key,.. how can I change the key usage flags with gpg?
4) gpg stores most (all) of the preferences in 0x13 self-sigs. I know that
this could make sense for the preferred algorithms and the features but I
think that I prefer to have a sort of default preferences in an 0x1F
self-sig. e.g. I'd like to set the algorithm preferences globally on a 0x1F
and only set it "locally" for one UID if the environment where that UID is
used hast different settings.
The key usage and key-server-prefs should be always on a 0x1F selfsig and
not und 0x13's because these are information about the key itself,... and
not a UID,... and they don't have that role-style as with the
algorithm-prefs and key features. Yes I know that RFC4880 allows key usage
flags and key server prefs on 0x13's,... but I think that's still not the
How can I change this in gpg, that it puts these on 0x1F?
5) Last but not least,... when setting the algorithm preferences gpg always
automatically adds 3DES, SHA1 and uncompressed. I now that all of these are
must-implement algorithms. But RFC4880 does not say, that the preference
subpacktes must include them. It just says it's good behaviour.
I think the export mode should allow it to not have them set.
My reason therefore is this:
An OpenPGP implementation MUST implement these algorithms,... if they are
part of the subpackets or not.... so communication will work anyway. But
when I despite the good-behaviour stuff remove those algorithms from the
preference subpacktes, I make a statement like saying: I don't care what
RFC4880 says,.. I consider 3DES as unsafe for my needs and won't accept
anything using it... same idea goes with the hashing algorithms.
For the compression preference,.... you now that there are attacks that are
thwarted by using compression, right?
Well removing uncompressed from the list, could say something like: Although
I support uncompressed datapackets (of course every implementation does) I
don't want,.. that anybody sends me uncompressed data,.. because I fear
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gnupg-users