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

[Jon Callas <jon@xxxxxxxxxx>]

-----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@xxxxxxxxx> 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@xxxxxxxxx             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-----