Re: OpenPGP keys and Suite-B


On May 4, 2008, at 12:34 PM, David Crick wrote:

On Sun, May 4, 2008 at 5:13 PM, David Shaw <dshaw(_at_)jabberwocky(_dot_)com>wrote:


On Sat, May 03, 2008 at 02:11:07PM -0700, Andrey Jivsov wrote:

===================================================================
  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.
===================================================================


I vote for C.  Keep the policies out of the standard and leave it up
to the implementers.  I'm not against having policies specified, but
I'd rather see them in a different document for use by those people
who need them.  There is precedence here: OpenPGP specifies DSA and
not DSS.

David


4880 13.6 starts with:

13.6.  DSA

  An implementation SHOULD NOT implement DSA keys of size less than
  1024 bits.  It MUST NOT implement a DSA key with a q size of less
  than 160 bits.  DSA keys MUST also be a multiple of 64 bits, and the
  q size MUST be a multiple of 8 bits.

and ends with:

 Note that earlier versions of this standard only allowed a 160-bit q
  with no truncation allowed, so earlier implementations may not be
  able to handle signatures with a different q size or a truncated
  hash.

which I would say would be "on using DSA in OpenPGP." But then in
the middle of those two bits has all of this:

The Digital Signature Standard (DSS) [FIPS186] specifies that DSA be
used in one of the following ways:

    * 1024-bit key, 160-bit q, SHA-1, SHA-224, SHA-256, SHA-384, or
      SHA-512 hash

    * 2048-bit key, 224-bit q, SHA-224, SHA-256, SHA-384, or SHA-512
      hash

    * 2048-bit key, 256-bit q, SHA-256, SHA-384, or SHA-512 hash

    * 3072-bit key, 256-bit q, SHA-256, SHA-384, or SHA-512 hash

  The above key and q size pairs were chosen to best balance the
  strength of the key with the strength of the hash.  Implementations
  SHOULD use one of the above key and q size pairs when generating DSA
  keys.  If DSS compliance is desired, one of the specified SHA hashes
  must be used as well.  [FIPS186] is the ultimate authority on DSS,
  and should be consulted for all questions of DSS compliance.


which by your argument "shouldn't be in" OpenPGP.

Not at all. There is a very substantial difference between mentioningin passing the difference between the specification and a popularstandard and the addition of new semantics to enforce a differencebetween the specification and a popular standard. Notice we don'thave a "Strict DSS" flag or anything like that. If someone wants toenforce it and draw a distinction, that's fine. OpenPGP gives peoplea lot of crypto parts they can put together in different ways.

We've got the same thing with Suite-B, only the fact that it's notjust
a case of Suite-B being a restricted subset of OpenPGP ECC (as DSS is
of 4880), but that there's a conflict between the 4880 spec andSuite-B
(i.e. (at least) the issue of 3DES).

Then publish an additional RFC giving whatever semantics are desired.I wouldn't want to load down the basic "ECC in OpenPGP" spec with it,any more than I'd want to see the traditional PGP trust modelspecified in 4880.


David