Fyi a new version of the requirements draft was just published Sent from my iPad
Begin forwarded message: > From: [email protected] > Date: March 8, 2015 at 5:27:15 PM PDT > To: Patrick Patterson <[email protected]>, Jim Schaad > <[email protected]>, Jim Schaad <[email protected]>, Patrick > Patterson <[email protected]>, Trevor Freeman > <[email protected]>, Trevor Freeman <[email protected]> > Subject: New Version Notification for draft-freeman-plasma-requirements-11.txt > > > A new version of I-D, draft-freeman-plasma-requirements-11.txt > has been successfully submitted by Trevor Freeman and posted to the > IETF repository. > > Name: draft-freeman-plasma-requirements > Revision: 11 > Title: Requirements for Message Access Control > Document date: 2015-03-05 > Group: Individual Submission > Pages: 49 > URL: > http://www.ietf.org/internet-drafts/draft-freeman-plasma-requirements-11.txt > Status: > https://datatracker.ietf.org/doc/draft-freeman-plasma-requirements/ > Htmlized: > http://tools.ietf.org/html/draft-freeman-plasma-requirements-11 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-freeman-plasma-requirements-11 > > Abstract: > S/MIME delivers confidentiality, integrity, and data origination > authentication for email. However, there are many situations where > organizations also want robust access control applied to information > in messages. The Enhanced Security Services (ESS) RFC5035 for S/MIME > defines an access control mechanism for email, but the access check > happens after the data is decrypted by the recipient which devalues > the protection afforded by the cryptography and provides very weak > guarantees of policy compliance. Another major issues for S/MIME is > its dependency on a single type of identity credential, an X.509 > certificate. Many users on the Internet today do not have X.509 > certificates and therefore cannot use S/MIME. Furthermore, the > requirement to discover the X.509 certificate for every recipient of > an encrypted message by the sender has proven to be an unreliable > process for a number of reasons. > > This document presents requirements for an alternative model to ESS to > address the identified issues with access control in order to deliver > more robust compliance for S/MIME protected messages. This document > describes an access control model which uses cryptographic keys to > enforce access control policy decisions where the policy check is > performed prior to the decryption of the message contents. This > authorization model can be instantiated using many existing standards > and is in not intended to be a one off just for email, being > applicable to other data types. > > This document also presents requirements for the abstraction of the > specifics of the authentication technologies used by S/MIME users. The > abstraction makes it possible for other forms of authentication > credentials to be used with S/MIME thereby enabling much broader > adoption. The authentication abstraction model also removes the > dependency on the need to discover encryption keys by the sender. This > abstraction can be used independently from access control to enable > simple scenarios where authentication of the recipient is sufficient > to grant access to the message. > > The name Plasma was assigned to this effort as part of the IETF > process. It is derived from PoLicy enhAnced Secure eMAil. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat >
_______________________________________________ plasma mailing list [email protected] https://www.ietf.org/mailman/listinfo/plasma
