David Crick wrote:
We need 3DES as a fallback default to smoothly integrate ECC keys
into existing installed base, as I mentioned earlier.
then (reluctantly, but not violently against) how about:
MAY implement ECC
o MUST implement SHA256
o MUST implement ECC256
[ o MUST implement 3DES - directly inherited from 4880, like it or not]
o MUST implement AES128 [or just inherit the SHOULD from 4880??]
o SHOULD implement AES256-SHA512-521ECC
o MAY implement AES256-SHA384-384ECC
o SHOULD try to match cipher strength with ECC strength, where
recipient key preferences allow.
(then need to add wording in about restrictions required for if strict
Suite B compliance is required.)
David, I agree with this.
Assuming this is consensus, I will change section 11.1 to "MUST
implement curve with ID 1 and SHOULD implement curve with ID 3". Also in
section 11.1, I will change to "MUST implement SHA2-256 and should
implement SHA2-512,", dropping curve ID 2 and dropping SHA2-384 as MUST
for OpenPGP profile.
I will add a few sentences about Suite B and RFC4880 (in)compatibility.
The problems are very very similar to the issue of FIPS mode of
operation and RFC 4880.
Regarding algorithm tupples, Section 12 already lists
AES256-SHA512-521ECC and AES256-SHA384-384ECC as SHOULD combinations.
I think it is better to break tupples into 3 pieces and address them
independently. The choice of symmetric algorithm is governed by key
preferences of (multiple) recipients. We shouldn't disregard preference
list and prefer AES-256 (even for ECC keys). So section 11.1 tell
MUST/SHOULD for individual algorithms and section 12 gives SHOULD
recommendations regarding dependencies between algorithms.
After above changes to section 11.1, the only missing correction there
is "SHOULD implement AES-256".