[Top] [All Lists]

Re: I have a technical idea/change for the ECC draft

2008-04-14 14:03:45

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- 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.
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.

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 alternative.