Miscellaneous questions

[David Shaw]

On Tue, Apr 15, 2008 at 02:31:07AM +0200, Herbert Furting wrote:
> On Mon, 2008-04-14 at 18:06 -0500, Robert J. Hansen wrote: 
> > 1.  You didn't ask for the option to allow zero-length UIDs.  If you'd
> >     asked for that option, I would have given it.  You asked "why does
> >     GnuPG have a minimum size of five characters", "is this imposed by
> >     RFC4880", and "where can I report this bug".  Your questions were
> >     answered.  Don't blame me if you asked the wrong questions.
> Well I don't want to go into such quibbling, but I've seen that gpg
> complained for UIDs shorter than 5 characters,... I've seen that RFC4880
> doesn't require this, and I've asked why.
> Not more not less.
> 
> btw: as far as I remember,... zero-length UIDs are allowed by the
> standard, aren't they?
> While this doesn't make sense ("nothing" is bound to the key) it
> wouldn't hurt either.

There are a lot of things that fall into the category of "legal by the
standard, but not good in the real world".  A zero-length UID is one
of them.  GPG handles this the way it handles most such things - it
will accept such a key from the outside world, but will not generate
it itself.

> > A specification does not set a high-water mark for implementations.  It
> > sets a low-water mark.  Implementations are free to restrict keys in any
> > way they want, so long as the low-water mark is met.  If you want to
> > write an RFC2440 implementation that supports only DSA, SHA-1 and 3DES,
> > nobody will stop you.  You're meeting the low-water mark.
> Of course. But I didn't talk about this at all? Did you read my
> arguments? I probably didn't explain it correctly (*not a native English
> speaker*):
> Preferred * Algorithm => Tells what the user prefers (and not what his
> implementation support.

Not exactly.  It contains what the user prefers **among the algorithms
that his implementation supports**.  It's the intersection of the
algorithms the user prefers for one reason or another and the
algorithms that his implementation supports.

> However,.. all of this does not answer my original question,.. whether
> it works and makes sense (from a security and not interoperability point
> of view) do revoke the old SHA1 selfsigs and create new (e.g.) SHA512,
> if it works with _current_ versions of gpg, if it's possible at all, and
> which revocation reason one should use.

It will work.  It's foolish and you'll hurt yourself doing it, but it
will work.

> > > I mean it exists,.. and there are several things (e.g. the examples 
> > > from my inital post) that would be better of with an 0x1F?
> > You're ascribing magical meanings to things.  You're not going to be
> > safer under your scheme.  It's different--it's not better.
> Not?
> When looking at the prefered * algos it definitely makes sense to allow
> putting them on UIDs, because one might e.g. have different locations
> (home, work) with different implementations that support different
> algos.
>
> But I think that actually it _is_ better to make a global (key wide)
> setting first (on a 0x1F) and just modify UIDs that really need other
> settings. This is common sense in the world of computing, like you
> have /etc/vim/vimrc with global settings first,.. and only create a
> ~/.vimrc if you relly need to do so.

This is another thing that GPG will accept from the outside, but not
generate itself.

> But for the preferred * algo subpackets I agree that it is not really
> necessary (although I think it would be cleaner).
> But I consider other subpackets e.g. key usage to be really key and nod
> UID related. So why putting them on 0x13 selfsigs if we have the
> possibility to use the indented signature on key. (Yes I know that the
> RFC allows it on all self-sigs, but I think that could be improved).
> 
> 
> > And this is the problem: you _are_ including it.  The RFC requires them
> > to be present, and if they're not present, requires all implementations
> > to add them.
> Could you please show me the place where it says, that those algorithm
> IDs must be part of the prefered algorithm subpacktes?

Like Robert said, the RFC requires them to be either present, or if
they are not present, the implementation must act as if they were
present.

Section 13.2:

   Since TripleDES is the MUST-implement algorithm, if it is not
   explicitly in the list, it is tacitly at the end.  However, it is
   good form to place it there explicitly.  Note also that if an
   implementation does not implement the preference, then it is
   implicitly a TripleDES-only implementation.

"...it is good form to place it there explicitly..."

Feel free to change your preferences to not have it there if it makes
you happier.  Any program that reads your key will act as if it was
there anyway.

> > Speak for yourself.  My personal-cipher-preferences has 3DES explicitly
> > listed as my first preference.
> Fine. If mine has listed AES256 (and yours too) first and lacks 3DES gpg
> should choose AES256,... if yours doesn't list it,.. it should choose
> 3DES (or of course another working match).
> But imagine the following:
> Yours: 3DES, AES256
> Mine: AES256, 3DES
> Which one is chosen now? But when I only include AES256 I can at least
> somewhat control it. 

No, you can't.  If you only include AES256, your preference list is
effectively "AES256, 3DES".  You can't get rid of the 3DES.

In the example above, you may end up with either 3DES or AES256.  The
spec requires that it is one of the two - it does not require a
particular one to be chosen.  That's why GPG has the
personal-cipher-preference option, where users can set what they like
in ranked order.  OpenPGP puts most of the power in the hands of the
sender, so the sender decides which algorithm to pick from the list.

David