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