This message is not directly relevant for the ongoing discussions, just a few
thoughts inspired by them. The short summary is that I am advocating a
conservative approach, and arguing against changing anything in the minimal
requirements.
Historically OpenPGP (and PGP) has been designed with the hypotetical NSA as
an adversary in mind. As long as being secure against extremely well-funded
adversaries does not put unnecessary burden on those of us, who only have less
powerful enemies to worry about, this approach is more than welcome. It is
great marketing, a safe bet, etc., etc., etc.
The low cost of OpenPGP-based encryption of email has made it the solution
of choice for the majority of those who care at all, even in the face of the
fact that S/MIME is supported out-of-the-box on all popular email clients,
while adding OpenPGP support requires non-trivial effort. This feat alone
justifies the general approach of OpenPGP.
I am extremely greatful to this WG of IETF for your choice of MUST
algorithms, as it allowed me to implement the standard on the J2SE 1.4
platform without implementing any cryptography. Even on the somewhat
crypto-crippled versions of Java, it is a full-strength, interoperable
implementation. It allowed me to implement java applets weighing a few dozen
kilobytes(!) that perform various PGP-operations and run on the vast
majority of java-enabled browsers. A full-fledged GUI-client that does
everything except key management fits into 140 kilobytes, including the gui.
It is precisely the 3DES, SHA1, MD5, RSA-s, DSA-s, RSA-e and ELG-e choice of
alrogithms that made this possible. Requiring AES or IDEA would have made
it much more difficult, although I understand that letting go of IDEA and
excluding Rijndael were both controversial choices at the time.
If the standard's requirements exceed the bare minimum that one can count on
in all sorts of legacy systems still in wide use, just to keep everybody
secure against the hypotetical NSA (not the real one, by the way --
cryptography alone cannot achieve that), it would put an unnecessary burden
on all sorts of practical applications where this is not a requirement.
I think, that the standard should definitely allow building heavy-duty
super-secure and super-efficient cryptosystems, if someone feels like that,
but _requiring_ excessive strength and efficiency would be, well, excessive.
--
Daniel