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. If you want this to change, take it to the WG. > 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. > Even if those subpacktes would be used in my suggested way, each > implementation would know "Nanana, 3DES is a fallback, so in each case I > can find my algorithm match", but in addition to that a user could force > his implementation (via a non conforming switch) to ignore that fallback > stuff, and just look at the preference. If he'll have problems with this > (interoperability) it's his own problem. 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: Define "security" first. _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
