Miscellaneous questions

[David Shaw]

On Mon, Apr 14, 2008 at 04:46:33PM +0200, Herbert Furting wrote:
> 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.

Not a bug.  It's there to protect people from making poor UIDs.  you
can turn off the check with --allow-freeform-uid.
 
> 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?

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.

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.  These are
not changeable, so even if you purge SHA1 from your key, note that
you're still using SHA1.  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.

> 3) On an existing key,.. how can I change the key usage flags with gpg?

Modify the source.

> 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?

Modify the source.

> 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.

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.

David