[Top] [All Lists]

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

2008-04-14 19:49:51

Hash: SHA1

On Apr 14, 2008, at 3:33 PM, David Crick wrote:
* 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,  
it would work well, it's simple, and elegant. End of story.

are you referring to a "key" or "application" preference (or both?!)

I was thinking a signature subpacket of some sort. That's a "key"  
preference. Strictly speaking, OpenPGP is a data protocol, and doesn't  
define applications preferences any more than SMTP tells you how to  
set up your sendmail or postfix conf file.

Any application-level things are beyond the scope of this group.

* Test, for interop purposes, 3DES with Suite B.

sounds sound

If you don't like this, you could do what David Crick suggested,
but with reverse polarity. I mean that instead of having an "-- 
suiteB" option, you have a "--loose-suiteB" option that you have to  
to allow anything that's not strict.

Note that these are not exclusive. You can do both.

So are you saying we have:

o Strict Suite B key flag ("legislative"; allows recipient to  
specify strongly)

*plus* (potentially out of scope of the [legistlative] spec?)

o an --enforce-suiteB application flag (self-evident)
o a --loose-suiteB application flag (but can it override a key-flag?  
- or
are you using this instead of a keyflag)

I'm saying that I like the idea of a legislative solution. However, it  
would be reasonable for us to punt the legislative issue.

We did this with DSA/DSS. If you want to be strictly FIPS, you always  
use DSA with SHA-1, etc. and that gives you DSS. If, however, you look  
askance at SHA-1, you can use DSA with RIPE-MD/160. There are explicit  
and implicit issues with that, but you can do it within 4880.

We could similarly just not worry about it. Let the implementers  
handle it. Thems what care about strict-SB can implement it the right  

I like the legislative solution, but I prefer doing nothing and  
letting the implementers handle it. This is a style issue. I believe  
that a standard exists for interoperability, and to make sure you  
don't end up with two implementations that *cannot* talk to each  
other. Beyond that, I am a minimalist. A standard is not a how-to  
guide for an implementer.

I were an implementer, I would not generate a "loose-Suite-B" message,  
*ever*. I'd decrypt them, but I wouldn't give my users the option to  
create them.

Even better would be for implementations to just not offer an


If all applications were to by default add AES (one or both) to
the head of any ECC generated keys, *and* prefer AES over
3DES as implicit, *but* still be able to "understand" messages
that are encrypted by non-AES ciphers.

Frankly, I believe that an application should prefer AES or Twofish  
over 3DES, period.

Note that 4880 *explicitly* says that you take the intersection of  
Alice's and Bob's preferences and resolve them any way you see fit. It  
is acceptable for an implementation to use 3DES only when nothing else  
exists. It's acceptable for an implementation, thus, in Suite B, to  
always be strict. (To do Suite B, you have to have AES as an option.)

That's the way I'd do it. I'd do it in the code, not in the standard.

However, I realize that not everyone has my matters of taste, and so  
therefore, I support the legislative solution. I just prefer not  
worrying, as it's less work here.


Version: PGP Universal 2.6.3
Charset: US-ASCII


<Prev in Thread] Current Thread [Next in Thread>