Miscellaneous questions

[Christoph Anton Mitterer]

Dear Robert.

On Tue, 2008-04-15 at 20:35 -0500, Robert J. Hansen wrote:
> Christoph Anton Mitterer wrote:
> > But it does not say that it has to contain the must-have algos.
> As has been mentioned here at least twice now, see section 13.2, where
> it explicitly says if the MUSTs are not listed, they are tacitly listed.
> I do not understand how much clearer I can make this.  By the plain
> black-letter of RFC4880, the MUST algorithms are always present.
> Always.
I'm not sure if the meaning of tacitly is something different in English
as its translation in German, but as my dictionary lists implicit as
synonym it is probably not.
So while I actually couldn't care about, why is it wrong why I say the
binary representation doesn't have to contain it, but it is
automatically added internally?
However I became bored of this... either read again what I've posted
(that big section where I tried to describe what I consider to be
improvable in the RFC) understand it or not, I don't care.

> If you want this to change, take it to the WG.
I think I've actually said this at least one time, didn't I?


> > I think this passage is very strongly influenced from a developers view:
> > Tacitly (implicit) at the _end_ simply says,... by putting 3DES at the
> > end we automatically have a fallback if no other algorithm is found,
> > without the need of any code.
> It's unwise to ascribe semantic meaning to a syntactic specification.
> The specification says what it says: nothing more, nothing less.
Yeah,.. that part was about how I could think that current handling of
that stuff came into existence. It was not a "That's what the standard
says" it was a "I think that's the original reason". It was just a step
to justify my proposed changed.


> Arguing "GnuPG should support a nonconformant extension to the spec" is
> probably not going to get much of anywhere.
> > But I'd like to know it this leads to improved security or not:
Specs are moving,... and implementations do so, too. And as others have
already pointed out, there are several places where gpg is
non-conformant (or at least doesn't care about some SHOULDs), e.g. it
allows you to export non-exportable signatures.
And if you argue that way "GnuPG should support a nonconformant
extension to the spec", you should also condemn reasonable things like
GnuPG's default minimum size of UIDs.
We all agree that this makes definitely sense, but it is as if gpg would
add it's own rule to OpenPGP saying, "UIDs should be longer than 5
characters".

While this is not forbidden, it is _like_ an addition to the standard.
Imagine I'd say "Oh lets add zz to the ISO 3166 list because it might be
reasonable"

(btw: I think that it's good that gpg allows this)


Best wishes,
-- 
Dipl.-Inf. (FH) Christoph Anton Mitterer

eMail:
christoph.anton.mitterer at physik.uni-muenchen.de
mail at christoph.anton.mitterer.name

Jabber/XMPP:
chat at christoph.anton.mitterer.name

Ludwig-Maximilians-Universität München
Lehrstuhl für experimentelle Physik – Elementarteilchenphysik
Sektion Physik
Am Coulombwall 1
85748 Garching bei München
Germany