-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I don't think this is a bad idea at all, but I also think I should
bring up something that Jeff Schiller made clear to me years ago, and
that's the difference between mandatory-to-implement, and mandatory-to-
use.
In this group, we create what are legislative systems. There are also
market systems, and we cannot create those. Let me give two examples.
As a result of various decisions made at the 1997 Munich IETF, there's
broad "MUST" requirement of Discrete Log PK Crypto and 3DES for
symmetric. This was an artifact of the patents for Discrete Log
expiring in 1997, and the RSA patents expiring in 2000. However, in
the X.509 certificate world, you will almost *never* see a DSA
certificate. I have heard it said that there have been no DSA
certificates created in the real world, only ones needed for "interop"
testing for the "mandatory" algorithm.
Quibble with this if you want, but it's still true that in the real
world there are only RSA certificates, despite RSA being an *optional*-
to-implement algorithm.
Similarly, I would expect that in the OpenPGP world, you'll now see
little to no use of 3DES. Mostly, you'll see AES. I have no supporting
facts for my expectation, but I'd bet a beer on it.
In these cases, market trumped legislation. In the RSA case, people
agreed to the political discrete log compromise, and then went on
doing what they'd been doing -- using RSA. In the AES case, AES has
replaced 3DES in the real world through organic growth.
So here's what we can do:
* I like David Crick's suggestion of a preference that says, "I'm
going to be strict about Suite B." This is a legislative solution, and
it would work well, it's simple, and elegant. End of story.
* Test, for interop purposes, 3DES with Suite B. But as an
implementor, *don't* *do* *it*. This is similar to what they did with
DSA in X.509. As an implementor, don't do anything other than strict
Suite B. Don't put it in the UI, don't give any options. Just do Suite
B. If you don't like this, you could do what David Crick suggested,
but with reverse polarity. I mean that instead of having an "--enforce-
suiteB" option, you have a "--loose-suiteB" option that you have to do
to allow anything that's not strict.
Note that these are not exclusive. You can do both. There can be a SSB
preference, and if enough people do it by default, then there's no
issue. Even better would be for implementations to just not offer an
alternative.
Jon
-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.6.3
Charset: US-ASCII
wj8DBQFIA7M4sTedWZOD3gYRAsBCAKD7Yt/Qbw+9Sihf1TkjWed5hQhD1gCgoIqt
G7C+2QmpmmTen5+en9A4v0g=
=XmeX
-----END PGP SIGNATURE-----