Re: I have a technical idea/change for the ECC draft
Jon Callas wrote:
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-
I think that there is implicit assumption here that "Suite-B" and "only
AES" are synonymous for this discussion, but clearly, only one of these
terms is crystal clear while another one is not.
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*-
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.
As it stands right now, Suite-B is vaguely defined, thus there will be a
lot of questions as to what that Suite-B key is. What do we loose if we
instead use "this key replaces TrippleDES implicit algorithm with
AES-128" notation? This would be beneficial for RSA keys too.
* 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