On Mon, Apr 14, 2008 at 11:22:59PM +0200, Herbert Furting wrote: > > > 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? > > GPG allows this. Add "--expert" to your command line when you want to > > re-sign the UID, and GPG will allow you to do what you want. > Ah great,... and it will work with gpg,... I mean a layout like, > [pubkey packet] > [UID packet] > [positive user certification 1] > [revoc of positive user certification 1] > ???[positive user certification 2 (with better algos)]
It will work with GPG. I can't speak for other programs, but it's legal by the spec, so it should work everywhere. Mind you, you're going to hurt yourself, but it's legal by the spec. > > Mind you, while GPG can do it, I don't think what you are doing is a > > good idea: OpenPGP itself uses SHA1 in a number of places. > I know,.. but in the signatures,.. only the revocation key subpacket > uses it, right? > The signatures (even the certification sigs) are made directly on the > key (and additional data like the UID), right? > So as far as I understand,.. I should actually gain some security, at > least from the point that an attacker could no longer concentrate on > attacking my SHA1 sigs. > If he want's to do a downgrade attack (recreate an new SHA1 selfsig) he > would have to attack the signature algorithm itself (e.g. RSA) ... or > kick me until I gave him my private key ;) No, if he wants to do a downgrade attack, he can just strip off your revocation packet and the new selfsig packet and use the old selfsig. Revoking it doesn't make it vanish. > > These are > > not changeable, so even if you purge SHA1 from your key, note that > > you're still using SHA1. > btw: When is this going to be changed? i.e. the fingerprint algorithm? Most likely not until we tackle V5 keys. Current keys are V4. > > Also, SHA512 is not widely implemented yet. > > You can very easily render your key not usable by a large percentage > > of the population if you pick a hash they don't have. > Yeah,... I know this,... unfortunately (at least from my point of view) > gpg and this list, seems to be very conservative it such issues :-/ > (don't want to offend you ;) ) I'm not insulted. Being conservative with crypto is a compliment. > > > 3) On an existing key,.. how can I change the key usage flags with gpg? > > Modify the source. > Ok, if I modify it,.. and create a 0x1F with key usage, key > server-prefs, algorithm prefs, and so on... Will gpg understand this? No. > Last but not least,.. I've already browsed through the source code... > could you please point me at the functions where I can put together the > bits for a (signature) packet (the type of the sig, date, hashed > subpacktes, and so on),... and the function that creates the actual > signature (MPI and so on) on this data and the (in case of an 0x1F) on > the key and UID? See sign.c:make_keysig_packet(), and the functions that it calls internally. David _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
