Subject: [plasma] Fwd: New Version Notification for draft-freeman-plasma-requirements-11.txt

From: Trevor Freeman <[email-masked]>
Date: Sun, 08 Mar 2015 22:55:07 -0700

Fyi a new version of the requirements draft was just published

Sent from my iPad

Begin forwarded message:

> From: [email-masked]
> Date: March 8, 2015 at 5:27:15 PM PDT
> To: Patrick Patterson <[email-masked]>, Jim Schaad <[email-masked]>, Jim Schaad <[email-masked]>, Patrick Patterson <[email-masked]>, Trevor Freeman <[email-masked]>, Trevor Freeman <[email-masked]>
> 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
>