David Shaw wrote: > But then, once we have algorithm agility, that means we must have a > means for dealing with that agility (preference lists being the > defined OpenPGP mechanism for that). And then, having such means, > why do we care all that much whether an algorithm is present or not?
To quote one of the best, most promising, and most vastly underused, statements in engineering: Hmm. I need to think about that... > Do we want to add every cipher that comes down the pike? Certainly > not. Do we want to add well designed ciphers that have strong > evidence behind them? Maybe, but still, why bother? We have that > already. Do we want to add well designed ciphers with strong > evidence behind them that people actually want to use (as opposed to > the oft-heard "Yeah, it would be neat if OpenPGP had the new BLAH-256 > cipher")? Sure we do. Or at least, I do. This doesn't explain Twofish, Blowfish, RIPEMD160, etc., etc. These are well-designed algorithms that very few people use, and they're still littering the standard. I don't think it's at all unreasonable to say "Camellia has users supporting it, sure, but before we go about adding new algorithms, let's prune out old ones." The cruft needs to be removed, and I don't see the WG addressing the problem. (I'm on the WG mailing list, although I rarely speak up there.) > I think the 4880 language here is very clear: you MUST support 3DES > (the protocol requires it), you SHOULD support AES and CAST5 (we > recommend this, but you're free to disagree, and the protocol will > work just fine either way), and you MAY support anything else you > like (i.e. completely optional, do what you like). Clear to you, yes. Clear to me, yes. It seems that it is not clear to others. People say "well, CAST5 is in the RFC, so I'll use it," not "well, CAST5 isn't a MUST, so I shouldn't depend on it being present." > My understanding is that you do not favor Camellia in OpenPGP I favor it being defined for the people who need it. I also favor putting in forty-eight-point boldface type "don't depend on other people supporting this because they probably won't and it's probably a good idea not to support it unless you have a pressing need." You say this is already conveyed by the fact it's optional. I disagree. > How? You don't think they'd have just asked for all of the > algorithms in "Appendix A" rather than "Section 9.2" ? My counterargument of, "it's a conformant implementation that matches all the MUSTs of the RFC, that's what I said I'd do, that's what I did," fell on deaf ears. After all, how could be be a conformant implementation if it didn't have double-width SHA or HAVAL? They're right there in the spec, after all. If I had said, "I have total coverage of the entire spec, the appendices are optional, that's why they're in appendices," I think it would have gone over better. However, counterfactuals being historical fiction, I can't definitively say it would have helped, only that I think it would have. As simple as we tend to think MUST, MAY, SHOULD, etc., are, Management is often not capable of understanding those words. _______________________________________________ Gnupg-users mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
