Crypto WG changes to SFRs

[woodbe]

This is just a rough idea of how requirements may be changed (broadly). This is more about changing an EXT to a new SFR or adding/removing something.

• FCS_CKM.1 - leave (specific to DSC)
• FCS_CKM.1/KEK - leave (specific to DSC)
• FCS_CKM.2 - change to FCS_CKM_EXT.7
• FCS_CKM.4 & FCS_CKM_EXT.4 - change to FCS_CKM.6 (changed in CC:2022)
• FCS_CKM.1/AK - change to FCS_CKM.1/AKG
• FCS_CKM.1/SK - change to FCS_CKM.1/SKG
• FCS_CKM_EXT.5 change to FCS_CKM.5
• FCS_RBG_EXT.1 - change to FCS_RBG.1 need to review changes (some additional parts that aren't in the current)
• FCS_RBG_EXT.2 - change to FCS_RBG.2 need to review changes as requirements are a little different
• FCS_SLT_EXT.1 - change to FCS_OTV_EXT.1 need to review changes
• FCS_ENT_EXT.1 - change to FCS_RBG.6
• FCS_COP.1/HMAC - change to FCS_COP.1/KeyedHash
• FCS_COP.1/KeyEnc - changes to FCS_COP.1/KeyEncap and FCS_COP.1/KeyWrap
  • this seems to argue for some sort of other SFR that would make these selection-based since they were included as one in the original SFR
• FCS_COP.1/KAT - this is unclear as there is no specific FCS_COP equivalent in the new catalog. Maybe unnecessary as the algorithms are all specified elsewhere, but unclear
• FCS_COP.1/PBKDF - change to FCS_CKM_EXT.8 this is what has been proposed already, but unclear given the lack of alternatives to PBKDF as brute force attack proptection

Ones to "keep the same" where the SFR is the same, but updated in the latest draft

• FCS_COP.1/Hash
• FCS_COP.1/SigGen
• FCS_COP.1/SigVer
• FCS_COP.1/SKC

[woodbe]

A related question is whether we should replace FDP_ITC_EXT.1 with FCS_ITC_EXT.1 with the refinement of "keys" for "SDEs"

Similarly, should FDP_ETC_EXT.2 be replaced with FCS_ETC_EXT.1 with a similar refinement.

[woodbe]

Yi's review

2023-07-18_CryptoCatalog_ImpactOn_DSCcPP.docx

[smuellerDD]

Are you planning to integrate changes to comply with the crypto WG SFR suggestions? I would recommend to wait until the SFRs have been stabilized a bit more considering the number of comments around it.

Yet, when reviewing the crypto catalog (as Yi's catalog shows), we need to make sure that the crypto WG proposals do not contradict what the DSC needs.

[woodbe]

So my thinking at this point (hence the large pull request) is to move the current version in now (which also pointed out a lot of minor issues I wouldn't have seen otherwise) and then update them as they adjust things. It is easy to back changes out (since I can just copy from the earlier version and paste them back in), but this way we can look at the new requirements and discuss whether they are appropriate.

Overall I think that these are good updates, but having them in now will provide time to review and adjust them as needed.

Given that they don't expect to have the "final" version available until closer to the ICCC, if we wait until then before trying to update them we would have a harder time having our draft ready by that time. I don't see a problem making adjustments based on their updates as needed during the public review process (easy to note that we will be updating those requirements during the process).

The main benefit to making these changes now, is we can actually look at them in place and see what we need to change (either to bring back original SFRs or in editing these, even providing feedback to the WG).