Hi,
For those not on yesterday's IDS call and not members of the MFP TC mailing
list, here's
Brian Smithson's written summary.
Cheers,
- Ira
------------------------------------------------------------
12/8/2014 7:37:53 PM Brian Smithson
<https://ccusersforum.onlyoffice.com/products/people/profile.aspx?user=bsmithson>
has started a new discussion: MFP PP development update
<https://ccusersforum.onlyoffice.com/products/projects/messages.aspx?prjID=239468&ID=279755>:
I gave a brief update during the IDS teleconference time slot this morning,
and here's a summary:
As you probably know, the last big piece of the puzzle has been data
encryption on HDDs/SSDs/SEDs. We've been trying to extract requirements and
assurance activities from the Full Disk Encryption cPP draft. A new draft
(v 0.9) is nearly done:
I've removed the old disk encryption requirements which were based on the
NIAP SWFDE PP, and replaced them with a new OSP, a new objective, and SFRs
from the FDE AA and EE cPPs. I've included assurance activities from the
FDE AA and EE SDs (with very little review, mostly just copy and paste).
We need to resolve some SFRs that perform the same function but are
specified differently, see below in the detailed change notes:
- I did not include A.INITIAL_DRIVE_STATE, A.STRONG_CRYPTO, and
OE.STRONG_ENVIRONMENT_ CRYPTO for now. Mario wondered about them and I
don't think they really help this PP.
- I corrected the definition of P.STORAGE_ENCRYPTION in ¶84 so that it
is consistent with the more precise definition that appears in Table 18.
- Added P.KEY_MATERIAL and O.KEY_MATERIAL with some re-wording:
- P.KEY_MATERIAL: Cleartext keys, submasks, random numbers, or any
other values that contribute to the creation of encryption keys
for storage
of confidential User Data or TSF Data must be protected from unauthorized
access and must not be stored on that storage device.
- In Appendix C (these are optional, or at least conditionally mandatory
SFRs)
- Added the proposed modified FPT_KYP_EXT.1. Added a subset of the
FPT_KYP_EXT assurance requirements from FDE AA SD v.13. We need an ECD for
FPT_KYP_EXT.1.
- Added the proposed modified FDP_DSK_EXT.1. We need an ECD for this as
well.
- Added FCS_COP.1(f). We certainly need to review the assurance
activities on this one. Also, it's not clear how a vendor would satisfy
FCS_COP.1(f) if it uses a CC certified SED.
- Also, FCS_COP.1(f) (AES encryption) for DAR is similar to FCS_COP.1(1)
(AES encryption) for DIM. They cover the same thing in different ways.
FCS_COP.1(f) is from the FDE cPPs v.13, and FCS_COP.1(1) is from NDPP v1.1
err3.
- Similarly, FCS_COP.1(b) (cryptographic hashing), a selection option
for key chaining, is similar to FCS_COP.1(3) (cryptographic hashing), in
the MFP draft for trusted update verification. They are different.
FCS_COP.1(b) is from FDE AA cPP v.13, and FCS_COP.1(3) is from NDPP v1.1
err3.
- The same issue exists for FCS_RBG_EXT.1 and FCS_CKM_EXT.4. The
versions from FDE cPPs v.13 are different from the ones in the MFP draft
which were taken from NDPP v1.1 err3.
- As for FCS_CKM.4 (key destruction), we have a similar SFR
FCS_CKM.4(Purge Data) but it simplified compared to the version in FDE cPP.
I think we need to figure out what to do with the duplicated SFRs before
posting the draft to the TC: keep the FDE versions, or keep the NDPP
versions, or keep both as separate SFRs (if there is a really good reason
to do so). Once we've sorted that out, I would update the rationale tables
and send it back to NIAP and IPA for a quick review before posting it to
the TC.
I think it would also be helpful to make a little roadmap to help navigate
this PP. It's hard to tell what is conditionally mandatory, what is truly
optional, and which selection-based requirements go with which selections.
I've started working on that.
Finally (one hopes there is a "finally" for this PP), I think it would be
useful to move the conditionally mandatory items into either (a) the main
body of the PP, but clearly marked as conditionally mandatory -- this is
the way they were in an earlier draft -- or, (b) make a new Appendix for
them which is separate from the Appendix that contains truly optional
functions like Local Audit Storage, Purge Data, and Image Overwrite. This
could happen as part of draft 0.9 or we could wait and do it later. Later
is probably a little better, as long as there is the aforementioned roadmap
to help vendors and labs review the draft.
This pre-release draft has been given to NIAP and IPA for review and
comment, and IPA has already provided many useful comments. I think it
should be wrapped up and ready to post to the whole MFP TC on Thursday.
It will be important for all vendors to look at this draft and the
accompanying roadmap to see if and how their products could comply. It
would be especially useful if vendors could provide feedback: what path
would you likely take though the PP for your product (so we can identify
unused paths that could be removed from the PP), or if your product
couldn't comply, what would we need to add or remove or change to make it
work.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ids/attachments/20141209/a9295534/attachment.html>