[Top] [All Lists]

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

2008-04-14 13:07:47

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- 

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  


Version: PGP Universal 2.6.3
Charset: US-ASCII