-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On May 2, 2008, at 7:01 AM, David Crick wrote:
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
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
than something.
In other words, leaving as much to the implementation as possible is
good.
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
that means.
...
* 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
-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.6.3
Charset: US-ASCII
wj8DBQFIG5DwsTedWZOD3gYRApUbAKDNKq2ouFglE2+0ckWGtsvjJ8LBCgCfULUi
XXedj8ZUuZUf4SHJMMpMM98=
=F+Yn
-----END PGP SIGNATURE-----