Miscellaneous questions

[Herbert Furting]

On Tue, Apr 15, 2008 at 3:43 AM, Robert J. Hansen <rjh at sixdemonbag.org> 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.
Don't see why,.. but... however.


> > 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?
Yes why not,... but only in an expert mode.


> 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.
Ah you think cryptography is engineering? Always thought it would be math.
However I never said that gnupg should suggest those unusual stuff,
but it does not make sense to forbid them. A user who whishes to make
a terbit key can simply modify the source.
I had hoped that gnupg neither shares the philosophy from Windows nor
that of GNOME,... keep as much away from the user as possible, in
other words, think he must be stupid.


> > 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.
In all doing respect,.. I hope there are really few. Otherwise we
really should consider "thorwing away" our current standard an release
only a small subset of it as new standard.

However,.. I didn't intend this as (nearly) a flame war.

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

> I can think of ten without needing to hit Google.
So much? Wow... really, thought there would be at best 5 or so.


> > 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.
Ok,.. but actually I'm no longer interested why you think so.


> 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.
Yes,... but despite of the the only thing I hear from you is,.. don't
need this, don't need that, etc. etc.
lol


> > 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.
I know about RFC2119, too.
Anyway,.. gpg isn't probably targeted as implementation for embedded
systems only. So of course an implementation doesn't have to implement
all that features,... but despite of that, I have the opinion that
gnupg should. Yeah I know,.. I haven't submittet patches...
Apart from that I had some discussions with Christoph and we both
think, that the RFC should be much stricter, especially in what is
required.
I know that OpenPGP says, that it's "wishy-washy" style is a feature
but there are several places where I think that could be a security
problem.
e.g. afaik the RFC does not require to implement the reason for
revocation subpacket. If it get's a key with a revocation signature on
it, it may simply behave, as if the key was superseeded (the rfc
doesn't require that an implementation has to consider all signatures
by a key invalid, if it doesn't understand its reason for revoc
subpacket), but the keyholder might actually used the key was
compromised reason.

However,.. more on such ideas when Christoph has finished his text
(which he'll probably post to WG list).

> > 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.
Apart from the fact that most of such organisations probably use X509
(unfortunately),... what would they do if an security update to gpg is
published?
Anyway if we always say that someone might have problems with new
features,.. we can never add them.
And for your specific example, no one forces the insurance company or
the bank to use the newer versions/features.
But as with every software, it makes only to some degree sense to
stick with historic reason. The applys to gpg as to the linux
kernel...


> > 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?
Of course,.. but I still can make feature requests.
So perhaps let's ask David. He's both member of the WG (and even a
named author since 4880 :-) ) and gnupg developer. Why did he agreed
to the features in 4880 (as author) if (as developer) he thinks nobody
needs 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."
So I'm right, or not? It doesn't have to be explicitly in the list.
And we already agreed that the proper place to suggest my (of course
only in my opinion) cleaner meaning of the (user) prefered algorithm
subpacktes, is the WG list, so we really don't need to discuss that
the standard implies a mixing of user preference and implementation
capabilities at this place.


> > *g* who decides which sense matters?
> Please don't try and engage me in a silly freshman-level philosophy
> argument.
Ah interesting,.. I actually thought you were trying to do so...


my 0,02€