ietf-openpgp
[Top] [All Lists]

OpenPGP keys and Suite-B

2008-05-03 14:27:16

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

<Prev in Thread] Current Thread [Next in Thread>