Hi,<br><br>For those not on yesterday&#39;s IDS call and not members of the MFP TC mailing list, here&#39;s<br>Brian Smithson&#39;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="" target="_blank">Brian Smithson</a> has started a new discussion: <a href=";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&#39;s a summary:<br><br>
As you probably know, the last big piece of the puzzle has been data 
encryption on HDDs/SSDs/SEDs. We&#39;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>
I&#39;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&#39;ve included assurance activities
 from the FDE AA and EE SDs (with very little review, mostly just copy 
and paste).<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&#39;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&#39;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 
<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&#39;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>
I think it would also be helpful to make a little roadmap to help 
navigate this PP. It&#39;s hard to tell what is conditionally mandatory, 
what is truly optional, and which selection-based requirements go with 
which selections. I&#39;ve started working on that.<br><br>
Finally (one hopes there is a &quot;finally&quot; 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>
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>
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&#39;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>