>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
