Hi Bryce, I am not quite sure why you keep asserting Plasma is attempting DRM when it's not. All its doing is providing the same access controls for email content as the same content is published via the web - and why should an organization expect anything less. It help the sender make sure that recipients are entitled to receive the information and that the sender has complied with the information protection policy for the information in the email. Unlike DRM, Plasma does not raise expectations that the recipient does the right thing with the information. Plasma did show it is possible to provide additional controls to ensure it is appropriate only disseminate the decryption keys when policy has been satisfied. We do not set expectations beyond that because the only strong control is the act of releasing the decryption key. In the Plasma PoC we showed it was possible to drive Plasma via a simple combo box selection as a one stop shop which hid the specifics of each policy. One of the vendors who participated in the project also did a user trial to test Plasma against the check box options of today and we got back positive results that user preferred Plasma to the encrypt message check box.
Trevor -----Original Message----- From: Endymail [mailto:[email protected]] On Behalf Of Nordgren, Bryce L -FS Sent: Wednesday, June 03, 2015 3:20 PM To: Phillip Hallam-Baker Cc: Trevor Freeman; [email protected] Subject: Re: [Endymail] FW: Group/Enterprise encrypted email >Trying to absolutely control the flow of information has a lousy track record. >And not just in the US but FOIA means that the US examples are rather >more obvious. Trying to lock everything down resulted in security >systems so complicated, even an MIT professor was unable to figure them out >when he was made CIA director. >The lesson we have learned is that imperfect security systems that are >acceptable to end users are much more effective than theoretically >perfect schemes that users bypass. It is possible that the US federal govt. >will learn the same lesson someday. > If they ever do, they know where to look. I think we are in agreement that top down micromanagement of information flow is bad. My comments are intended to align the language in the doc with the actual security provided, not cause anyone to fix perceived security holes. :) It does very much read like the intent is to set up a DRM such that conforming systems provide certain guarantees. It shouldn't. I'm not certain I've been persuaded that the DRM-esque aspects are worthwhile. Sticking with normal, un-augmented email semantics simplifies this proposal to the point that implementers may be able to make the encryption process completely transparent to users, or at least boil it down to a checkbox. Much of the value associated with generalizing the available policies beyond "encrypt this message and disseminate keys to the email recipients" seems to be predicated on prose making guarantees of policy enforcement across organizational boundaries. A very much clearer and more precise value statement is warranted. Perhaps this is answered in that other spec, but I don't yet see how the mail client knows what parameters are expected by the policy. Does it need to understand and implement a UI for some sort of policy schema language? Best, Bryce _______________________________________________ Endymail mailing list [email protected] https://www.ietf.org/mailman/listinfo/endymail _______________________________________________ Endymail mailing list [email protected] https://www.ietf.org/mailman/listinfo/endymail
