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