Re: [smime] FW: I-D Action:draft-freeman-message-access-control-req-00.txt
"Jim Schaad" <ietf@augustcellars.com> Fri, 21 January 2011 18:33 UTC
Return-Path: <ietf@augustcellars.com>
X-Original-To: smime@core3.amsl.com
Delivered-To: smime@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7398328C0FF for <smime@core3.amsl.com>; Fri, 21 Jan 2011 10:33:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.573
X-Spam-Level:
X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDLs-lNAhP3c for <smime@core3.amsl.com>; Fri, 21 Jan 2011 10:33:22 -0800 (PST)
Received: from new-smtp02.pacifier.net (new-smtp02.pacifier.net [64.255.237.176]) by core3.amsl.com (Postfix) with ESMTP id 5CD0D28C0F5 for <smime@ietf.org>; Fri, 21 Jan 2011 10:33:22 -0800 (PST)
Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by new-smtp02.pacifier.net (Postfix) with ESMTPSA id AA3762CA13 for <smime@ietf.org>; Fri, 21 Jan 2011 10:36:08 -0800 (PST)
From: Jim Schaad <ietf@augustcellars.com>
To: 'Smime' <smime@ietf.org>
References: <20110120231501.13170.67353.idtracker@localhost> <E545B914D50B2A4B994F198378B1525D1564B0D6@DF-M14-12.exchange.corp.microsoft.com>
In-Reply-To: <E545B914D50B2A4B994F198378B1525D1564B0D6@DF-M14-12.exchange.corp.microsoft.com>
Date: Fri, 21 Jan 2011 10:54:39 -0800
Message-ID: <021501cbb99c$a8512cc0$f8f38640$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIjIdhr+nesR763fQZAaCkXLQV6lAH0dYeukx1RJaA=
Content-Language: en-us
Subject: Re: [smime] FW: I-D Action:draft-freeman-message-access-control-req-00.txt
X-BeenThere: smime@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SMIME Working Group <smime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/smime>, <mailto:smime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/smime>
List-Post: <mailto:smime@ietf.org>
List-Help: <mailto:smime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/smime>, <mailto:smime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Jan 2011 18:33:23 -0000
I have additionally released two documents which provide a potential method of implementing the requirements These are: http://www.ietf.org/id/draft-schaad-eps-smime-00.txt which describes the additions to the CMS and S/MIME formats to support the concept and http://www.ietf.org/id/draft-schaad-eps-trust-00.txt which gives a possible description of how to communicate between the mail client and the enforcement server. Jim > -----Original Message----- > From: smime-bounces@ietf.org [mailto:smime-bounces@ietf.org] On Behalf > Of Trevor Freeman > Sent: Friday, January 21, 2011 9:28 AM > To: Smime (smime@ietf.org) > Subject: [smime] FW: I-D Action:draft-freeman-message-access-control-req- > 00.txt > > This should be of interest to members of the members of the list. > > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- > bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org > Sent: Thursday, January 20, 2011 3:15 PM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-freeman-message-access-control-req-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Requirements for Message Access Control > Author(s) : T. Freeman, et al. > Filename : draft-freeman-message-access-control-req-00.txt > Pages : 17 > Date : 2011-01-20 > > There are many situations where organizations want to include > information which is subject to regulatory or other complex access > control policy in email. Regulated information requires some form of > robust access control to protect the confidentiality of the > information. The Enhanced Security Services for S/MIME [rfc2634] > defines an access control mechanism for S/MIME (eSSSecurityLabel). > This is a signed attribute of a SignedData object which indicates the > access control policy for the message. The fact that this is a signed > attribute protects the integrity of the data and the binding of the > label to the message but does not protect the confidentiality of the > information i.e. at the point where you lean the access control policy > to the data you also have access to the data. While the signature > provides integrity for the label over the clear text, it is > susceptible to unauthorized removal i.e. if you only have SignedData > message, any MTA in the mail path can remove a signature layer and > therefore remove the access control data. Encrypting the signed > message protects the confidentiality of the data and protects the > SignedData from unauthorized removal but this hides the ESS security > label. > > From a regulatory enforcement perspective this is an extremely weak > form of access control because cryptographic access to the data is > given before the access check. The correct enforcement of the access > check totally depends on the configuration of the recipients email > client. Since the cryptographic access is granted before the access > checks, there is no significant impediment for a recipient who is > unauthorized under the policy to access the data. A stronger > enforcement model is needed for regulatory control for email where > cryptographic access is only granted after the access check. > > There are also many users on the Internet today who have some form of > authentication credential but they are not X.509 certificates and who > therefore cannot use S/MIME. There are now available, standard based > services (e.g. [SAML-overview]) which abstract the specifics of a > technology used to authenticate uses from the application itself (S/MIME in > this case). Adoption of this abstraction model would enable > a broader set of users who have other types to authentication > credentials to be able to use S/MIME to secure email. It also allows > for new authentication technology to be deployed without impacting the > core S/MIME protocol. > > This document specifies the requirements for:- > > > Providing robust access control for S/MIME > > > An abstraction layer for supporting other types of credentials for > > using S/MIME. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-freeman-message-access- > control-req-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the Internet- > Draft.
- [smime] FW: I-D Action:draft-freeman-message-acce… Trevor Freeman
- Re: [smime] FW: I-D Action:draft-freeman-message-… Paul Hoffman
- Re: [smime] FW: I-D Action:draft-freeman-message-… Trevor Freeman
- Re: [smime] FW: I-D Action:draft-freeman-message-… Jim Schaad