Thanks for the feedback Ken! Some thoughts below:
From: Swinson, Ken [mailto:[email protected]] Sent: Monday, February 8, 2016 3:04 PM To: Daniel Mihai <[email protected]>; Lioy, Marcello <[email protected]>; [email protected]; [email protected] Cc: [email protected]; Dominique Chanet (QEO LLC) <[email protected]>; Josh Spain <[email protected]>; [email protected] Subject: RE: [Allseen-core] Security 2.0 status, and proposals for improvements Dan, Thanks for the list, Has device certificates dropped from the active discussions? I suspect code changes would be desirable regardless of the decision to move forward with a single root CA or multiple root CAs selected by individual OEMs. [DM] This one is currently not on my radar at all. Please bring it up in the Core WG meetings if it's important. See inline for other comments. Ken From: Daniel Mihai [mailto:[email protected]] Sent: Friday, February 05, 2016 2:11 PM To: Lioy, Marcello; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; Dominique Chanet (QEO LLC); Swinson, Ken; Josh Spain; [email protected]<mailto:[email protected]> Subject: RE: [Allseen-core] Security 2.0 status, and proposals for improvements This is the current high-level wish list of improvements that we are investigating at MSFT. It is still unclear how many and when we'll be able to implement them. 1. Add new Manifest format, more granular, as I proposed in the attached email. - Also consider removing the support for the problematic 15.09 Manifest format [kens] I need clarification on what you are proposing. Is it as Phil summarized in the e-mail you attached? In which case then more granular refers to segmenting the manifest? The 15.09 manifest should not be supported if it is replaced. [DM] We will share our detailed proposal as soon as possible. We are currently reviewing one such proposal in our team - stay tuned. 2. Add XML-based public methods for Policy, Manifest, Manifest Template. - Consider removing the current public methods, if they are superseded by the new methods [kens] I agree with removing superseded methods that would fall under the developer preview for sec 2 3. Add StartManagement + EndManagement methods, called by a Security Manager to notify the target app that its Security settings are about to change. [kens] I'll reply to your later email on the topic. 4. Add public C APIs corresponding to the most useful public C++ methods. 5. Significant changes to the implementation of the Key Store - to address ASACORE-2661, ASACORE-2664, and other shortcomings. 6. Make it easier to share a single Key Store between two processes running on a single machine. [kens] This should include making it easy for a security manager to determine that the key store is shared so that it can construct policies and manifests. [DM] Agreed that would be a worthy goal. Let's see how close we can get to that goal in 16.04. We'll provide our detailed proposal as soon as we can. 7. Add a new SPEKE auth mechanism - similar but better than the current PSK. 8. Introduce the concept of "Recommended Security Level". For example: - Manufacturer of an "org.Contoso.GunSafe" device might want to recommend that interface as accessible just to "Privileged" users - Manufacturer of an "org.Contoso.WirelessSpeaker" device might want to recommend that interface as "NonPrivileged" - Manufacturer of an "org.Contoso.LightSwitch" device might want to recommend that interface as "Unauthenticated" [kens] I like it. Consider mapping the recommendation to the peer types for consistency. [DM] Peer types would definitely be used by the Security Manager behind the scenes, to implement the Security Levels mentioned above: "Unauthenticated" maps well to PEER_ALL. I look at a particular implementation of Security Manager as having more flexibility when it wants to implement "NonPrivileged" and/or "Privileged" Levels. For example, we're currently still debating in our team if we want to use just PEER_FROM_CERTIFICATE_AUTHORITY, or just PEER_WITH_MEMBERSHIP, or a combination of these two, for our particular scenarios. Each of these choices seems to have advantages and disadvantages. 9. Investigate the numerous active JIRA tickets related to Security and fix those that the Core WG decides are important. If anyone has questions or other kind of feedback, please speak up. Dan -----Original Message----- From: Lioy, Marcello [mailto:[email protected]] Sent: Thursday, February 4, 2016 11:39 AM To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Cc: Daniel Mihai <[email protected]<mailto:[email protected]>> Subject: RE: [Allseen-core] Security 2.0 status There are some changes being proposed, however, I think it is developer API changes rather than the interface definitions on the wire. I have CC'ed Dan Mihai who is driving the updates to Security 2.0. He can correct or elaborate as appropriate. -----Original Message----- From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of [email protected]<mailto:[email protected]> Sent: Monday, January 25, 2016 2:08 AM To: [email protected]<mailto:[email protected]> Subject: [Allseen-core] Security 2.0 status Hi everyone, Is it possible to release the latest 15.09(a)-related Security 2.0 HLD ? As both the https://na01.safelinks.protection.outlook.com/?url=allseenalliance.org&data=01%7c01%7cDaniel.Mihai%40microsoft.com%7c1761def47b9b40ff54da08d32d9adcb0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=8t3KSB3ksxrk%2fFOPp7gcPWW%2btMdZsmovppbK0g3%2fwzQ%3d documentation and wiki seem to point to out-of-date documents. Also, is the production-grade 16.04 Security 2.0 roadmap decided upon (e.g. things like interface description servers and like) ? Thanks, Ondrej T _______________________________________________ Allseen-core mailing list [email protected]<mailto:[email protected]> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2flists.allseenalliance.org%2fmailman%2flistinfo%2fallseen-core&data=01%7c01%7cDaniel.Mihai%40microsoft.com%7c1761def47b9b40ff54da08d32d9adcb0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=%2fZzxaUmnFC9opwKhE%2bnozXKB04TnGNL3Kxw%2bn3FtYtM%3d
_______________________________________________ Allseen-core mailing list [email protected] https://lists.allseenalliance.org/mailman/listinfo/allseen-core
