Miscellaneous questions

[Robert J. Hansen]

Herbert Furting wrote:
> While this doesn't make sense ("nothing" is bound to the key) it 
> wouldn't hurt either.

It violates a de-facto standard.  That hurts.

> I just think, that an implementation should not forbid things, that
> are allowed by the standard.

The standard allows for terabit RSA keys.  Should GnuPG allow them?

All real-world implementations of real-world standards have to make
decisions about what will be supported and how it will be supported.
This is what engineering is all about.

> If that breaks the best practise idea of the RFC,... it think - in
> all doing respect - the RFC should be changed in that matter.

Take it up with the working group and get the RFC changed.

> gpg is probably THE main implementation of OpenPGP (sorry to the 
> commercial PGP folks ;) ),... as such I think it should support most
> of the stuff from OpenPGP, or not?

Depends on who you ask.  A few people on-list (myself being one of them)
think GnuPG supports too much of OpenPGP.

> How many other major implementations are there? Not too much right?

I can think of ten without needing to hit Google.

> I know that this is opensource and all have their own lives and 
> business, but I have the felling that the attitude here is,.. most 
> average people don't need it,... it will perhaps break older/other or
> even historical implementations (which ones ;) ) so don't even talk 
> about it or think about the idea the we could implement it.
> 
> Got the point?

Yes, but you're still wrong.

If the GnuPG developers had that attitude, GnuPG would have only
supported DSA, Elgamal, SHA-1 and 3DES.  The fact that GnuPG supports
essentially all of RFC 2440/4880, despite the fact the average person
really doesn't need most of it, is strong evidence against your argument.

> Interoperability,.. of course important,... but we should perhaps (at
> least slowly) move to newer stuff (e.g. the sha512 sigs) or we won't
> have any advancement at all...

This is a WG issue.  Take it up with them.

> Ease of use,.. of course important to,... but that does not mean,..
> that one shouldn't be able to use every little bit of the standard

Sure it does.  What do you think SHOULDs and MAYs mean?  Only the MUSTs
in the standard must be present.  Everything else is optional.

> You're funny ;) You just said,.. an implementation can do what it
> want (as long as it's meeting the lower mark) now you said it should
> not.

Yes.  Where's the problem?

You can play Russian roulette.  You probably shouldn't.

> And to be honest,... it's not so difficult to update gpg ;)

A lot of groups can't do this.  For instance, a bank's insurance company
may require that any software used go through an expensive certification
process.  If it costs $50,000 to get the software certified, you're not
going to want to upgrade for anything short of the direst emergency.

GnuPG is used in a lot of places besides just people's desktops.  In a
lot of these places, upgrading is an uphill battle.

> Ah,.. I waited for such a comment... this is the 
> you-dont-develop-so-you-dont-have-any-rights-to-ask-or-discuss
> answer...

Not at all.  Discuss it all you like.  But if you can't convince the
developers of the correctness of your opinion, why should they spend
time writing code to implement this opinion?

There is something sociopathic about saying "I cannot convince you
to do this, but you should do it anyway, and if you elect to tell me to
do it myself I'm going to say you're denying me my rights."

> btw: are you a gpg developer?

GnuPG development is done primarily by g10 Code GmbH.  I work for the
National Science Foundation as a researcher in electronic voting
security.  There's no overlap between my work and GnuPG.

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

Section 13.2 of RFC4880.  "Since TripleDES is the MUST-implement
algorithm, if it is not explicitly in the list, it is tacitly at the end."

> But they should...

If this is what you want the RFC to say, take it up with the WG.

> But in the meantime I fear,.. that he will run against closed doors
> and highly conservative (not to say narrow-minded) attitudes :-(

Just because someone disagrees with you vigorously does not make them
"highly conservative" or "narrow-minded".  It very often means they've
been burned more than you have, and want to spare other people the
anguish which will result if you are allowed to play with matches.

> 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.  3DES is appended to the end.  If you want this behavior
to change, talk to the WG.

> Because A user might think 3DES is unsafe for his needs.

Then they need to use something other than OpenPGP.

OpenPGP is not meant to be all things to all people.

> I cannot discuss with you about algorithm details (have only little 
> knowledge about this)... but I know that e.g. NIST decided to replace
>  DES by AES and the only thing I can do is follow such hints,... to 
> decide which algorithm is currently "the best".

NIST replaced DES because it was a 56-bit cipher.

3DES is a different beast.

> That's not completely true...

Close enough for jazz.

> *g* who decides which sense matters?

Please don't try and engage me in a silly freshman-level philosophy
argument.