Re: OpenPGP keys and Suite-B

[Jon Callas <jon@xxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On May 7, 2008, at 6:31 AM, Greg Troxel wrote:

>
> Andrey Jivsov <openpgp@xxxxxxxxxxxx> writes:
>
>> Many of these issues, such as the security level of information, is
>> outside of traditional domain of OpenPGP. I suppose an e-mail
>> application in Suite-B environment might have a UI combobox with
>> SECRET/TOP SECRET choices in the compose window that magically (based
>> on content or at worst manually) are set to the correct level. The
>> rest is easier to program: this would allow software to check that
>> [TS] information is being sent to [S] key(s) and block it.
>
> I am a bit boggled as to the point of this discusion.  It seems rather
> unlikely that an OpenPGP software implementation will be approved to
> handle classified traffic, and even less likely that a user on a
> computer running a GUI will have available adequate MLS facilities to
> choose the level of a message.


Actually, I don't think it at all unlikely. Certainly it's unlikely  
without SuiteB in the protocol, an OpenPGP implementation would be at  
a disadvantage. Implementers of software often do things that other  
people think is unlikely.

>
>
> Are we talking about being able to have an OpenPGP implementation be
> configured to follow Suite B guidelines for S or TS, intended for use
> with unclassified information?  This would perhaps follow the  
> reasonable
> theory that such guidelines define best practices for algorithm  
> choice.
>
> Are we talking about hardened implementations that would implement  
> mail
> gateways between enclaves?
>
> Or something else?  I don't mean to be difficult, but I really don't  
> get
> it.
>

We're talking about the standards work that is needed for people who  
want to implement SuiteB within OpenPGP to be able to do so.

I think a number of your comments are in line with what I perceive the  
consensus to be. Building software is different from creating the  
protocol, and we seem to think that the protocol aspects should be  
minimal.

But we don't want to preclude quasi-SuiteB. Let me give as an example,  
the SuiteB ECC with Camellia rather than AES. The protocol should not  
preclude this.

So let's suppose I have an ECC key, and my symmetric cipher prefs say  
Twofish, Camellia, AES, [3DES]. Let's suppose that you implement  
Camellia and AES and 3DES.

The standard says you can pick any of those. You might pick Camellia,  
because I listed that before AES. If there were a "I-Like-SuiteB"  
flag, you might use that as a hint that I want you to use AES, even  
though Camellia is first. Or, you might be a system designed to do  
SuiteB, and you ignore all non-SuiteB algorithms, in which case you  
use AES, no matter what I say. You might even just use AES when I  
*don't* have it, even though it is a technical violation of the  
standard. We'd have to slap your wrist, but you might do it anyway.

The advantage of a SuiteB preference is that it would permit the  
implementation to make sense of options. If I create an ECC  
certificate with the SuiteB preference, then it makes sense to ensure  
that AES is in the preferences. If I see an ECC cert with SuiteB and  
no AES, I can throw an error, as this is inconsistent, or just deal.

The disadvantage of a SuiteB preference is that it's just more stuff  
to have to cope with. That's why I'm happy either way.

	Jon


-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.6.3
Charset: US-ASCII

wj8DBQFIMhJ5sTedWZOD3gYRAlfxAJ91jkeEmJqDjXXOm+DjPO+VF91pIACdHLvK
qV0UhETP3rSAbRwlB0qMvBM=
=n6u5
-----END PGP SIGNATURE-----