From nobody Sun Mar 8 22:55:31 2015 Return-Path: X-Original-To: plasma@ietfa.amsl.com Delivered-To: plasma@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38C3B1A6FF7 for ; Sun, 8 Mar 2015 22:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRj37tCpU-dD for ; Sun, 8 Mar 2015 22:55:27 -0700 (PDT) Received: from mr11p24im-asmtp002.me.com (mr11p24im-asmtp002.me.com [17.110.78.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70DB81A6EF1 for ; Sun, 8 Mar 2015 22:55:27 -0700 (PDT) Received: from [192.168.1.7] (c-24-17-210-106.hsd1.wa.comcast.net [24.17.210.106]) by mr11p24im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Dec 4 2014)) with ESMTPSA id <0NKX00FVDKFUZK50@mr11p24im-asmtp002.me.com> for plasma@ietf.org; Mon, 09 Mar 2015 05:55:09 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2015-03-09_01:2015-03-06,2015-03-08,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1503090065 References: <20150309002715.4237.43431.idtracker@ietfa.amsl.com> From: Trevor Freeman Content-type: multipart/alternative; boundary=Apple-Mail-42E91483-33C3-45B6-87B1-A1DA961C90C4 X-Mailer: iPad Mail (12B466) Message-id: Date: Sun, 08 Mar 2015 22:55:07 -0700 To: "plasma@ietf.org" Content-transfer-encoding: 7bit MIME-version: 1.0 (1.0) Archived-At: Subject: [plasma] Fwd: New Version Notification for draft-freeman-plasma-requirements-11.txt X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The PoLicy Augmented S/Mime \(plasma\) bof discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 05:55:30 -0000 --Apple-Mail-42E91483-33C3-45B6-87B1-A1DA961C90C4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Fyi a new version of the requirements draft was just published Sent from my iPad Begin forwarded message: > From: internet-drafts@ietf.org > Date: March 8, 2015 at 5:27:15 PM PDT > To: Patrick Patterson , Jim Schaad , Jim Schaad , Patrick Patterson , Trevor Freeman , Trevor Freeman= > Subject: New Version Notification for draft-freeman-plasma-requirements-11= .txt >=20 >=20 > 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. >=20 > 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-r= equirements-11.txt > Status: https://datatracker.ietf.org/doc/draft-freeman-plasma-requ= irements/ > Htmlized: http://tools.ietf.org/html/draft-freeman-plasma-requiremen= ts-11 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-freeman-plasma-re= quirements-11 >=20 > 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. >=20 > 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. >=20 > 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. >=20 > The name Plasma was assigned to this effort as part of the IETF > process. It is derived from PoLicy enhAnced Secure eMAil. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submissi= on > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail-42E91483-33C3-45B6-87B1-A1DA961C90C4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Fyi a new version of the requirements d= raft was just published

Sent from my iPad

Begin forward= ed message:

From: internet-drafts@ietf.org
Date= : March 8, 2015 at 5:27:15 PM PDT
To: Patrick Patterson <ppatterson@carillon.ca>, Jim S= chaad <ietf@augustcellars.com>, Jim Schaad <ietf@august= cellars.com>, Patrick Patterson <ppatterson@carillon.ca>, Trevor Freeman <trevor.freeman99@icloud.com>, Trevor Fre= eman <trevor.freeman99@icl= oud.com>
Subject: New Version Notification for draft-fre= eman-plasma-requirements-11.txt


A new version of I-D, draft-freeman-= plasma-requirements-11.txt
has been successfully submitted b= y Trevor Freeman and posted to the
IETF repository.
Name:        draft-freeman-plas= ma-requirements
Revision:    11
Ti= tle:        Requirements for Message Access Control
Document date:    2015-03-05
Group: &n= bsp;      Individual Submission
Pages:  =      49
URL:      &= nbsp;     http://www.ietf.org/internet= -drafts/draft-freeman-plasma-requirements-11.txt
Status:=         https://datatracker.iet= f.org/doc/draft-freeman-plasma-requirements/
Htmlized: &= nbsp;     http://tools.ietf.org/html/draft-freeman-= plasma-requirements-11
Diff:     &nb= sp;     http://www.ietf.org/rfcdiff?url2=3D= draft-freeman-plasma-requirements-11

Ab= stract:
 S/MIME delivers confidentiality, integrity, a= nd data origination
 authentication for email. However= , there are many situations where
 organizations also w= ant robust access control applied to information
 in m= essages. The Enhanced Security Services (ESS) RFC5035 for S/MIME
<= span>  defines an access control mechanism for email, but the  acc= ess check
 happens after the data is decrypted by the r= ecipient which devalues
 the protection afforded by th= e cryptography and provides very weak
 guarantees of p= olicy compliance. Another major issues for S/MIME is
 = its dependency on a single type of identity credential, an X.509
<= span>  certificate. Many users on the Internet today do not have X.509<= /span>
 certificates and therefore cannot use S/MIME.  Fu= rthermore, the
 requirement to discover the X.509 cert= ificate for every recipient of
 an encrypted message b= y the sender has proven to be an unreliable
 process f= or a number of reasons.

 This documen= t presents requirements for an alternative model to ESS to
&= nbsp;address the identified issues with access control in order to deliver
 more robust compliance for S/MIME protected messages. T= his document
 describes an access control model which u= ses cryptographic keys to
 enforce access control poli= cy decisions where the policy check is
 performed prio= r to the decryption of the message contents. This
 aut= horization 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 abstracti= on of the
 specifics of the authentication technologie= s used by S/MIME users. The
 abstraction makes it poss= ible for other forms of authentication
 credentials to= be used with S/MIME thereby enabling much broader
 ad= option. The authentication abstraction model also removes the
 dependency on the need to discover encryption keys by the sender. T= his
 abstraction can be used independently from access= control to enable
 simple scenarios where authenticat= ion of the recipient is sufficient
 to grant access to= the message.

 The name Plasma was as= signed to this effort as part of the IETF
 process. It= is derived from PoLicy enhAnced Secure eMAil.




Please note that it m= ay take a couple of minutes from the time of submission
unti= l the htmlized version and diff are available at tools.ietf.org.

The IETF Secreta= riat

= --Apple-Mail-42E91483-33C3-45B6-87B1-A1DA961C90C4--