[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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@xxxxxxxxxxxxxxx>
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
4880 13.6 starts with:
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
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
* 2048-bit key, 224-bit q, SHA-224, SHA-256, SHA-384, or SHA-512
* 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 mentioning
in passing the difference between the specification and a popular
standard and the addition of new semantics to enforce a difference
between the specification and a popular standard. Notice we don't
have a "Strict DSS" flag or anything like that. If someone wants to
enforce it and draw a distinction, that's fine. OpenPGP gives people
a 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 not
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 and
(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 model
specified in 4880.