|
Re: I have a technical idea/change for the ECC draft
2008-04-15 00:18:10
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,
and
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 "--
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.
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
way.
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 favor this too.
One additional issue I realized that we didn't address is the mixing of
keys for two levels of Suite-B profile. It is similar to the issue of
mixing non-Suite-B and Suite-B keys.
TOP SECRET must use AES-256, SECRET must use AES-128 or AES-256. We
cannot make TOP SECRET keys use AES-128, yet this is what happens with
implicit AES-128. Making AES-256 implicit will not work either, because
now SECRET keys will be picked as compatible with TOP SECRET keys.
Finally, having no implicit preferences disallows TOP SECRET keys to
receive SECRET information.
Do we now need two Suite-B flags?
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
alternative.
yes!
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.
Jon
|
|