Hi David.
On Mon, 2008-04-14 at 13:41 -0400, David Shaw wrote: > Not a bug. It's there to protect people from making poor UIDs. you > can turn off the check with --allow-freeform-uid. Ah thanks,.. wouldn't it make sense to merge this with the expert flag? > > 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)] > 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 ;) So the only left areas where I should use SHA1 is hmm the MDC and the fingprint right? When I always make signatures (of course with "something better" than SHA1) the SHA1 in the MDC is no problem at all... And for the fingerprint,... in principle,... I could not rely on the fingerprint (when singing other keys) but ask for a copy of the key itself,.. when meeting someone. Does this make sense? > 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? > 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 ;) ) > > 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? What will happen if I have both, e.g. a hash algo pref subpacket on a 0x1F and a 0x13? 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? Ah and,.. same question as to rjh,... (I hope you read my answer to his mail,.. and share me your thoughts on my ideas :) )... why does gpg make no use of them by default? > You can do this with "setpref" but there is no point. GPG is just a > computer program and doesn't care about making statements. If you > take 3DES, SHA1 and Uncompressed out, any program that sees your key > will just internally put them back in again as required by 4880. Yes of course,... but (hopefully) on the end of the _internal_ list. btw: What do you think about my ideas on this issue,.. that I wrote down in the reply to Robert? Regards, Herbert. _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
