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.