On Tue, Apr 15, 2008 at 3:22 AM, Jon Callas <jon(_at_)callas(_dot_)org> wrote:
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.
good.
Any application-level things are beyond the scope of this group.
again, this is what I was expecting.
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 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.
I agree with you on all the above.
>> 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.
It's what NIST says (of AES and 3DES; AES is the FIPS, while
3DES has been downgraded to a Special Recommendation).
NSA's blessing of AES (first for classified usage, and then an
even stronger endorsement through Suite B) as far as I'm
concerned is a very clear signal. In fact, Suite B itself (and I
include SHA2 here, despite people's misgivings given SHA1)
is a strong signal about "what" we (crypto implementers)
should be doing - and why I've been pushing for us to focus
on Suite B (and AES with it) when looking at OpenPGP ECC.
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.)
yes, although there *is* a section in 4880 that says about
the preference listing being ordered. The two things together
*aren't* incompatible; rather they say, together, that here's
some information you *could* use, but really it's up to you.
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 think the legislative solution should give clear enough
guidelines to the implementers about what they should
be doing!