[Top] [All Lists]

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

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.


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