ietf-openpgp
[Top] [All Lists]

Re: ECC in OpenPGP -00.txt is posted as a draft

2008-05-02 07:20:45

On Fri, May 2, 2008 at 2:32 PM, Derek Atkins <derek(_at_)ihtfp(_dot_)com> wrote:
David,

 > The submitted version doesn't (yet) have mention of the
 > proposed (and generally, it seems, well-received notion of)
 > a StrictSuiteB flag / flags.

 Actually, it was not well received.

oh.  I counted at least (quick search of the archive):

Jon Callas:
I don't think this is a bad idea at all
...
* 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.

Werner Koch (quoting the "i like David Crick's" paragraph above):
I support this.


Further, Andrey Jivsov continued the discussion:
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?
(end quoting Andrey)


so I thought this had some momentum behind it?

The "OpenPGP way" of doing this
 is an application putting in the "accepted ciphers" into the public
 key notation.  This document doesn't need to describe that because
 it's already well documented in RFC 4880.

but the problem was that a recipient currently has no
way of saying "strict suite B" beyond setting one/both
of the AESes as higher up in their preference list and
then *hoping* all of the implementations that ever
send messages use this "advisory" information rather
than (legitimately) taking some other arbitrary intersection
of recipient preferences and choosing something other
than the AES of the correct length.

 Using the notation packet also allows us to support different "Strict
 Suites"..  If some other country wants their own stuff in there we don't
 need to extend anything; applications just set the appropriate
 supported cipher list.  Et Voila, you've got your "flag".

perhaps I'm not using correct terminology here?  My "flag"
(or "flags," if we decide we need one for each of the Suite
B profiles, as per Andrey's last message, quoted above)
was intended to be "something" on the key that the user
can set to say "Strict Suite-B."  Is my "flag"/key "something"
the same as what you are calling a "notation packet" ?

I don't think it is?

But I emphasis again that the key cipher preference list
*cannot* be guaranteed to make us Suite-B compliant,
as implementations can choose their own intersections.

So we need something "more."

 -derek
 --
       Derek Atkins                 617-623-3745
       derek(_at_)ihtfp(_dot_)com             www.ihtfp.com
       Computer and Internet Security Consultant