attachment
Hi,<br><br>For those not on yesterday's IDS call and not members of the MFP TC mailing list, here's<br>Brian Smithson's written summary.<br><br>Cheers,<br>- Ira<br><br>------------------------------------------------------------<br clear="all"><div><div class="gmail_signature"><div dir="ltr"><p style="font-size:14px;line-height:18px;margin-top:20px;word-wrap:break-word!important">12/8/2014 7:37:53 PM <a href="https://ccusersforum.onlyoffice.com/products/people/profile.aspx?user=bsmithson" target="_blank">Brian Smithson</a> has started a new discussion: <a href="https://ccusersforum.onlyoffice.com/products/projects/messages.aspx?prjID=239468&ID=279755" target="_blank">MFP PP development update</a>: </p>
<p>I gave a brief update during the IDS teleconference time slot this morning, and here's a summary:<br><br>
<br><br>
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:<br><br>
<br><br>
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).<br><br>
<br><br>
We need to resolve some SFRs that perform the same function but are
specified differently, see below in the detailed change notes:</p><br>
<ul><br><li>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.</li><br><li>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.</li><br><li>Added P.KEY_MATERIAL and O.KEY_MATERIAL with some re-wording:<br>
<ul><br><li>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.</li><br></ul><br>
</li><br><li>In Appendix C (these are optional, or at least conditionally mandatory SFRs)</li><br><li>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.</li><br><li>Added the proposed modified FDP_DSK_EXT.1. We need an ECD for this as well.</li><br><li>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.</li><br><li>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.</li><br><li>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.</li><br><li>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.</li><br><li>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.</li><br></ul><br>
<p>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.<br><br>
<br><br>
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.<br><br>
<br><br>
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.<br><br>
<br><br>
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 <span tabindex="0" class="aBn"><span class="aQJ">on Thursday</span></span>.<br><br>
<br><br>
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.</p><br><br><div style="display:inline"></div><div style="display:inline"></div><div style="display:inline"></div><div></div><div></div><div></div><div></div></div></div></div>