[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ECC in OpenPGP -00.txt is posted as a draft
-----BEGIN PGP SIGNED MESSAGE-----
On May 2, 2008, at 7:01 AM, David Crick wrote:
> On Fri, May 2, 2008 at 2:32 PM, Derek Atkins <derek@xxxxxxxxx> wrote:
>>> 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
Since I'm being invoked, I must clarify. I don't think it's a bad idea
at all. But I think in the interests of minimalism, nothing is better
In other words, leaving as much to the implementation as possible is
But that also includes some flag that says the implementation does
SuiteB strictly. It's good to have it, but I'm not sure much more
needs to be said. It isn't our job to go into the gory details of what
> * 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
>> 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 Atkins 617-623-3745
>> derek@xxxxxxxxx www.ihtfp.com
>> Computer and Internet Security Consultant
-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.6.3
-----END PGP SIGNATURE-----