Hi list. 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 stuff. 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 best idea. 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 those attacks. Regards, H.F.
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
