Suite-B has two profiles: TOP SECRET [TS] and SECRET [S] and it requires
that
TOP SECRET must use AES-256
SECRET must use AES-128 or AES-256
Labeled security is usually required with these standards. Information
is labeled with certain classification, which assures that the
processing of this information will match the label as data travels
through the system. This results in:
TOP SECRET keys can receive TOP SECRET and SECRET information
SECRET keys can only receive SECRET information
Information | |
level | Keys | "Send to" action
--------------------------------------------
[TS] | [TS],[S] | fail
[S] | [TS],[S] | allow with AES-256
[TS] | [S] | fail
[S] | [TS] | allow with AES-256
[TS] | [TS] | allow with AES-256
[S] | [S] | allow with AES-256/128
Note that two first rows represent the same mix of keys but result in
different behavior. This aspect is orthogonal to OpenPGP.
For completeness,
Key level | Key preferences
--------------------------------------------
[TS] | {AES-256}
[S] | {AES-256, AES-128}
I see three approaches.
===================================================================
A. Use key notations "suite-b-key(_at_)pgp(_dot_)com"
with values "top secret" and "secret".
===================================================================
Leave the interpretation of these values to applications. The rationale
is that we don't recite government documents in the document like "ECC
in OpenPGP". There are other requirements that must be satisfied beyond
the scope of the "ECC in OpenPGP" document, such as authentication and
how the private keys are unlocked. For example, we cannot enforce the
use of PIN pad devices.
(If all we have to say is the sentence under A, I would say we keep it
out of the document.)
===================================================================
B. Use feature bits of a key 0x02, 0x4 of
"5.2.3.24. Features" as follows:
0x02: The default symmetric alg. of the key is AES-128
0x04: The default symmetric alg. of the key is AES-256
These bits can be combined (i.e. they are not mutually
exclusive).
===================================================================
TOP SECRET (TS) must have 0x02
SECRET must have 0x02|0x04=0x06
The existence of 0x02 or 0x04 tells that the implicit default algorithm
TripleDES is replaced by (either of) corresponding AES algorithm(s).
This specification may appeal to these who don't want to see Suite-B
mentioned in the "protocol/format" document. It also specifies narrow
feature using the concepts compatible with the scope of RFC 4880.
The Suite-B meaning need to be layered on top of these bits.
Yet, the proposals A and B lack following details:
* It is not sufficient to rely on key holder to tell which information
level it is eligible to receive. Everyone wants TOP SECRET. This
statement must come from a trusted source, like a certification by a
trusted key or looked up online. The above proposals A and B put data
into a self-signature. OpenPGP "0x50: Third-Party Confirmation
signature" may be needed. It is "may" because in some cases keys are
managed, making this notary signatures unnecessary, or keys may be
looked up in some online directory.
* Furthermore, what a sender does with the information and how it
interprets the flags on a key is not enforceable by a recipient. This
must be enforced by higher levels.
* I thought about how a [TS] information might be encrypted to a Suite-B
recipient with hypothetical command line tool. For example, like this:
openpgpcmd --suite-B-information=secret
--trusted-certifier-top-secret=XXX -trusted-certifier-secret=YYY recipients
v.s.
openpgpcmd --suite-B-information=secret --trusted-certifier=ZZZ recipients
In one case the type of certifier ([TS]/[S]) is determined from key
properties, in another case the types of certifiers are passed
explicitly. The commands look similar, especially if there are two
trusted certifiers in each case.
Finally:
===================================================================
C. Higher layers of application will govern compliance
with Suite B. "ECC in OpenPGP" document will define
reasonable superset of features required for Suite-B
or similar government documents, but exact
specification of the policies to use ECC in OpenPGP
is out of scope.
===================================================================
In other words, A and B are really C+policies. Regardless of which route
we take, we will need "protocol/format" document. This is what
implementors need first. This is what is needed to establish
interoperability base. This is what will make messages flow. This layer
alone may get incorrectly encrypted [TS] information with TripleDES, so
higher layer will be needed. However, as an implementor I see value in
splitting a Suite-B cloud into layers that we can implement and test
independently.
Here is promised ballot. "x" for "yes".
As an editor I think that voting C will result in faster progress of the
document.
Andrey:
A:
B:
C: x