-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On May 7, 2008, at 6:31 AM, Greg Troxel wrote:
Andrey Jivsov <openpgp(_at_)brainhub(_dot_)org> 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-----