From wwwrun@core3.amsl.com Thu Feb 3 11:54:24 2011 Return-Path: X-Original-To: plasma@ietf.org Delivered-To: plasma@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id DEC1A3A6ACC; Thu, 3 Feb 2011 11:54:24 -0800 (PST) From: IETF Secretariat To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110203195424.DEC1A3A6ACC@core3.amsl.com> Date: Thu, 3 Feb 2011 11:54:24 -0800 (PST) Cc: plasma@ietf.org Subject: [plasma] New Non-WG Mailing List: plasma -- The PoLicy Augmented S/Mime (plasma) bof discussion list X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 03 Feb 2011 19:54:25 -0000 A new IETF non-working group email list has been created. List address: plasma@ietf.org Archive: http://www.ietf.org/mail-archive/web/plasma/ To subscribe: https://www.ietf.org/mailman/listinfo/plasma Description: Current S/MIME mechanisms provide cryptographic access to the message based on the identity of the recipient at the time of transmission. Any additional access control enforcement depends on the configuration of the recipients email client. Several Internet-Drafts have been submitted that establish a more robust access control mechanism where cryptographic access to the message is only granted after the access check. This list is devoted to the discussion of these drafts and any related future submissions. For additional information, please contact the list administrators. From hallam@gmail.com Fri Feb 4 07:59:45 2011 Return-Path: X-Original-To: plasma@core3.amsl.com Delivered-To: plasma@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14A1B3A6903 for ; Fri, 4 Feb 2011 07:59:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.626 X-Spam-Level: X-Spam-Status: No, score=-3.626 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 eyms6uJuQtT8 for ; Fri, 4 Feb 2011 07:59:43 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id A43993A6969 for ; Fri, 4 Feb 2011 07:59:43 -0800 (PST) Received: by gwb20 with SMTP id 20so1096460gwb.31 for ; Fri, 04 Feb 2011 08:03:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=Jpap5N+75c4RFV72/1NkCSm4KHpR0Te4zxltyAG3mAE=; b=m4mJNfTDgCiu1OXF+271oiMHfnT3GcwdikdxWQMQQXWkHbhrbhecXlAXeXzUP2QQ2r Kd4af/amZ63TOUhs6Ng9kkTY7yHs+5/Rh0Na5NZJtQp0s+8ggO/x4b8Wyw9wVpTI+J4N mrwLLt9Y1McWQU1ShCbmkPDBE7M9FJMy+JM5Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=nFyDBOCEu/wR3MLGI8yUQeUoSoauwIE/2OdD1MEc5XxFKBeSdbMAHK4HsQVd8uB0Dn DAZAU7v/DmSd6oS2JdpIE7o2orFrZEYCxk/wMQ4O3199NlnPoccIGw7YonQRU0drSsf8 zSEfk/Rl0ERMzdc+DcP26KzwEnnOUefcWnEEU= MIME-Version: 1.0 Received: by 10.100.48.3 with SMTP id v3mr7738761anv.154.1296835388497; Fri, 04 Feb 2011 08:03:08 -0800 (PST) Received: by 10.100.242.14 with HTTP; Fri, 4 Feb 2011 08:03:08 -0800 (PST) Date: Fri, 4 Feb 2011 11:03:08 -0500 Message-ID: From: Phillip Hallam-Baker To: plasma@ietf.org Content-Type: multipart/alternative; boundary=0016e645b8c4a9e0c0049b770443 Subject: [plasma] S/MIME for document control X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 04 Feb 2011 15:59:45 -0000 --0016e645b8c4a9e0c0049b770443 Content-Type: text/plain; charset=ISO-8859-1 I have been thinking for a while that S/MIME is probably less useful as a mail security feature as a document security feature. Imagine that I could tag a file from Word or Excel with a security policy so that it woud be automatically saved in an encrypted CMS package with decryption keys for both me and a document server. That would be the best way to make sure that the document is encrypted end-to-end which these days means securing the document in the end point mobile device as at least as great a priority as on the wire. There are CMS systems for inside enterprises, but use seems to be marginal at best and the most interesting/confidential documents in a commercial environment are almost exclusively those that have to be passed to other companies to fullfil their function. I.e. the ones exchanged with lawyers, customers etc. Even patient records need to be exchanged with specialists from other hospitals. There is a relevant patent that covers the efficient way to do this - http://www.freepatentsonline.com/5481613.html, issued in 1994. Currently assigned to Entrust I believe. Thats only three years and a few months. -- Website: http://hallambaker.com/ --0016e645b8c4a9e0c0049b770443 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have been thinking for a while that S/MIME is probably less useful as a m= ail security feature as a document security feature.

Ima= gine that I could tag a file from Word or Excel with a security policy so t= hat it woud be automatically saved in an encrypted CMS package with decrypt= ion keys for both me and a document server.

That would be the best way to make sure that the docume= nt is encrypted end-to-end which these days means securing the document in = the end point mobile device as at least as great a priority as on the wire.=

There are CMS systems for inside enterprises, but use s= eems to be marginal at best and the most interesting/confidential documents= in a commercial environment are almost exclusively those that have to be p= assed to other companies to fullfil their function. I.e. the ones exchanged= with lawyers, customers etc. Even patient records need to be exchanged wit= h specialists from other hospitals.


There is a relevant patent that covers t= he efficient way to do this - =A0http://www.freepatentsonline.com/5481613.html, issued i= n 1994. Currently assigned to Entrust I believe. Thats only three years and= a few months.

--0016e645b8c4a9e0c0049b770443-- From trevorf@exchange.microsoft.com Fri Feb 4 09:58:01 2011 Return-Path: X-Original-To: plasma@core3.amsl.com Delivered-To: plasma@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85F713A69B3 for ; Fri, 4 Feb 2011 09:57:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 t04Nog97-N6l for ; Fri, 4 Feb 2011 09:57:51 -0800 (PST) Received: from mail.exchange.microsoft.com (mail7.exchange.microsoft.com [131.107.1.27]) by core3.amsl.com (Postfix) with ESMTP id 332453A69CD for ; Fri, 4 Feb 2011 09:57:36 -0800 (PST) Received: from df-h14-02.exchange.corp.microsoft.com (157.54.78.140) by DF-G14-02.exchange.corp.microsoft.com (157.54.87.56) with Microsoft SMTP Server (TLS) id 14.1.218.15; Fri, 4 Feb 2011 10:01:01 -0800 Received: from DF-MLT-01.exchange.corp.microsoft.com (157.54.94.40) by DF-H14-02.exchange.corp.microsoft.com (157.54.78.140) with Microsoft SMTP Server (TLS) id 14.1.270.2; Fri, 4 Feb 2011 10:01:01 -0800 Received: from DF-M14-12.exchange.corp.microsoft.com ([fe80::7c94:4036:120:c95f]) by DF-MLT-01.exchange.corp.microsoft.com ([157.54.94.40]) with mapi id 14.01.0218.012; Fri, 4 Feb 2011 10:01:01 -0800 From: Trevor Freeman To: Phillip Hallam-Baker , "plasma@ietf.org" Thread-Topic: [plasma] S/MIME for document control Thread-Index: AQHLxIUGzegIBrtNEUyNiy5kHWJPY5PxnR3A Date: Fri, 4 Feb 2011 18:01:01 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.104] Content-Type: multipart/alternative; boundary="_000_E545B914D50B2A4B994F198378B1525D1AC868A7DFM1412exchange_" MIME-Version: 1.0 Subject: Re: [plasma] S/MIME for document control X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 04 Feb 2011 17:58:01 -0000 --_000_E545B914D50B2A4B994F198378B1525D1AC868A7DFM1412exchange_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Phil, I think document or files are a good direction to go as an extension of the= work. Ultimately the goal is to be able to provide consistent policy enfor= cement of polices on information regardless where that information is in em= ail or in a file. As a byproduct we have to be able to use a much broader s= et of credential types e.g. this must work if the user just has a password.= The motivation to split the WS-trust piece out was that it can be reused = for other scenarios such as document protection. We have discussed drafting= how to use CMS with OPC which would deliver both generic file protection a= s well as cover the major document format standards. We felt stating with e= mail was a good first step. There are a lot of scenarios playing out today = where email would be the logical chose IF it could deliver higher assurance= on the privacy front. My bank cannot send be my statement via email, nor c= an my doctor send me test results. Just protecting documents and files is not a good paradigm. Users would hav= e to understand that the information they type in the message was insecure = but the information in the attachment was secure. That is way too much of a= leap of trust in the user. If we start with email they that will cover the= attachments which makes things better than they are today. If we have enou= gh volunteers to draft specs we can look to add documents and files using t= he same approach sooner rather than later. We need to get the first set of = deliverables underway before we extend the scope. Trevor From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of= Phillip Hallam-Baker Sent: Friday, February 04, 2011 8:03 AM To: plasma@ietf.org Subject: [plasma] S/MIME for document control I have been thinking for a while that S/MIME is probably less useful as a m= ail security feature as a document security feature. Imagine that I could tag a file from Word or Excel with a security policy s= o that it woud be automatically saved in an encrypted CMS package with decr= yption keys for both me and a document server. That would be the best way to make sure that the document is encrypted end-= to-end which these days means securing the document in the end point mobile= device as at least as great a priority as on the wire. There are CMS systems for inside enterprises, but use seems to be marginal = at best and the most interesting/confidential documents in a commercial env= ironment are almost exclusively those that have to be passed to other compa= nies to fullfil their function. I.e. the ones exchanged with lawyers, custo= mers etc. Even patient records need to be exchanged with specialists from o= ther hospitals. There is a relevant patent that covers the efficient way to do this - http= ://www.freepatentsonline.com/5481613.html, issued in 1994. Currently assign= ed to Entrust I believe. Thats only three years and a few months. -- Website: http://hallambaker.com/ --_000_E545B914D50B2A4B994F198378B1525D1AC868A7DFM1412exchange_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Phil,

 

I think document or fi= les are a good direction to go as an extension of the work. Ultimately the = goal is to be able to provide consistent policy enforcement of polices on information regardless where that information is in email or= in a file. As a byproduct we have to be able to use a much broader set of = credential types e.g. this must work if the user just has a password.  = ;The motivation to split the WS-trust piece out was that it can be reused for other scenarios such as document p= rotection. We have discussed drafting how to use CMS with OPC which would d= eliver both generic file protection as well as cover the major document for= mat standards. We felt stating with email was a good first step. There are a lot of scenarios playing out toda= y where email would be the logical chose IF it could deliver higher assuran= ce on the privacy front. My bank cannot send be my statement via email, nor= can my doctor send me test results.

 

Just protecting docume= nts and files is not a good paradigm. Users would have to understand that t= he information they type in the message was insecure but the information in the attachment was secure. That is way too much of a le= ap of trust in the user. If we start with email they that will cover the at= tachments which makes things better than they are today. If we have enough = volunteers to draft specs we can look to add documents and files using the same approach sooner rather than= later. We need to get the first set of deliverables underway before we ext= end the scope.

 

Trevor

 

From: plasma-b= ounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of Phillip Hallam-Baker
Sent: Friday, February 04, 2011 8:03 AM
To: plasma@ietf.org
Subject: [plasma] S/MIME for document control

 

I have been thinking for a while that S/MIME is prob= ably less useful as a mail security feature as a document security feature.=

 

Imagine that I could tag a file from Word or Excel w= ith a security policy so that it woud be automatically saved in an encrypte= d CMS package with decryption keys for both me and a document server.<= /o:p>

 

That would be the best way to make sure that the doc= ument is encrypted end-to-end which these days means securing the document = in the end point mobile device as at least as great a priority as on the wi= re.

 

There are CMS systems for inside enterprises, but us= e seems to be marginal at best and the most interesting/confidential docume= nts in a commercial environment are almost exclusively those that have to b= e passed to other companies to fullfil their function. I.e. the ones exchanged with lawyers, customers etc. Even = patient records need to be exchanged with specialists from other hospitals.=

 

 

There is a relevant patent that covers the efficient= way to do this -  http://www.freepatentsonline.com/5481613.html, issued in 1994. C= urrently assigned to Entrust I believe. Thats only three years and a few months.

 

--_000_E545B914D50B2A4B994F198378B1525D1AC868A7DFM1412exchange_-- From ietf@augustcellars.com Fri Feb 4 14:36:56 2011 Return-Path: X-Original-To: plasma@core3.amsl.com Delivered-To: plasma@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 045F63A69D4; Fri, 4 Feb 2011 14:36:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 E8Htq1IwplPu; Fri, 4 Feb 2011 14:36:55 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by core3.amsl.com (Postfix) with ESMTP id EE8003A6998; Fri, 4 Feb 2011 14:36:54 -0800 (PST) Received: from TITUS (static-66-14-119-7.bdsl.verizon.net [66.14.119.7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTP id 57EE76EFB8; Fri, 4 Feb 2011 14:40:20 -0800 (PST) From: "Jim Schaad" To: , References: <20110203195424.DEC1A3A6ACC@core3.amsl.com> In-Reply-To: Date: Fri, 4 Feb 2011 15:00:18 -0800 Message-ID: <005701cbc4bf$4ba0fb30$e2e2f190$@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: AQFp21AcUcEMBZHlO9sjhNrVDy5kBgEZvIDHlKz2J5A= Content-Language: en-us X-Mailman-Approved-At: Fri, 04 Feb 2011 14:48:09 -0800 Subject: Re: [plasma] [abfab] FW: New Non-WG Mailing List: plasma -- The PoLicy Augmented S/Mime (plasma) bof discussion list X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 04 Feb 2011 22:36:56 -0000 I would like to add a few additional things to this as well. We are currently looking at a proposal that is based on WS-Trust (SOAP based token system) for communications between the mail client and the mail policy server and, while using SAML, are placing how the SAML assertion(s) are obtained is out of scope. However I think that a good alternative to this might be to look at using the ABFAB architecture. We would then have the mail client talking some protocol to the mail policy server which would be using the ABFAB architecture to talk AAA to the correct identity service. In some cases the identity service and the mail policy server would be co-located, but this would be invisible to the mail client. Doing this would simplify things as the correct SAML assertion would be obtained by the policy server and it can ask for the type of details that it wants without the client having to try and guess what is required. On the other hand it might complicate issues as we are looking at the ability for the mail policy service to issue "short-term" tokens to the mail client after having gone through a full policy check that stands in for abilities. Thus not all of the ABFAB EAP would be used all of the time. If you have an interest in talking about this, it would be better to join the PLASMA mailing list and respond there. Jim > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf Of > Trevor Freeman > Sent: Thursday, February 03, 2011 2:56 PM > To: abfab@ietf.org > Cc: jimsch@nwlink.com; Trevor Freeman > Subject: [abfab] FW: New Non-WG Mailing List: plasma -- The PoLicy > Augmented S/Mime (plasma) bof discussion list > > PLASMA - Policy Augmented S/Mime > > Description: Current S/MIME mechanisms provide cryptographic access to the > message based on the identity of the recipient at the time of transmission. Any > additional access control enforcement depends on the configuration of the > recipients email client. Several Internet-Drafts have been submitted that > establish a more robust access control mechanism where cryptographic access > to the message is only granted after the access check. > > This proposed working group would develop a framework for enforcing a more > robust access control mechanism, based on existing CMS, S/MIME and SAML- > based policy enforcement standards. The working group will also develop any > necessary extensions to these base protocols specific to this problem space. > > Given the mutual interest in SAML - this work may be of interest to some of > you. > > -----Original Message----- > From: IETF Secretariat [mailto:ietf-secretariat@ietf.org] > Sent: Thursday, February 03, 2011 11:54 AM > To: IETF Announcement list > Cc: plasma@ietf.org; jimsch@nwlink.com; Trevor Freeman > Subject: New Non-WG Mailing List: plasma -- The PoLicy Augmented S/Mime > (plasma) bof discussion list > > A new IETF non-working group email list has been created. > > List address: plasma@ietf.org > Archive: http://www.ietf.org/mail-archive/web/plasma/ > To subscribe: https://www.ietf.org/mailman/listinfo/plasma > > Description: > Current S/MIME mechanisms provide cryptographic access to the message > based on the identity of the recipient at the time of transmission. Any > additional access control enforcement depends on the configuration of the > recipients email client. Several Internet-Drafts have been submitted that > establish a more robust access control mechanism where cryptographic access > to the message is only granted after the access check. This list is devoted to the > discussion of these drafts and any related future submissions. > > For additional information, please contact the list administrators. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From Josh.Howlett@ja.net Tue Feb 8 02:26:55 2011 Return-Path: X-Original-To: plasma@core3.amsl.com Delivered-To: plasma@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F39E3A70D2 for ; Tue, 8 Feb 2011 02:26:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 NV3i2uMwNWkA for ; Tue, 8 Feb 2011 02:26:54 -0800 (PST) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id 2D35C3A70D0 for ; Tue, 8 Feb 2011 02:26:54 -0800 (PST) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id A94F54A6B72_D511A73B for ; Tue, 8 Feb 2011 10:26:59 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 7C9AC4A6B71_D511A73F for ; Tue, 8 Feb 2011 10:26:59 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0218.012; Tue, 8 Feb 2011 10:27:20 +0000 From: Josh Howlett To: "plasma@ietf.org" Thread-Topic: [abfab] FW: New Non-WG Mailing List: plasma -- The PoLicy Augmented S/Mime (plasma) bof discussion list Thread-Index: AQHLxLycoN3Dez2g2UeJkPb7uChTz5P3aZNA Date: Tue, 8 Feb 2011 10:27:20 +0000 Message-ID: <55DC663C2F4F9F439F23543E0078E8B30A6D3B@EXC001> References: <20110203195424.DEC1A3A6ACC@core3.amsl.com> <005701cbc4bf$4ba0fb30$e2e2f190$@augustcellars.com> In-Reply-To: <005701cbc4bf$4ba0fb30$e2e2f190$@augustcellars.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [194.82.140.76] Content-Type: multipart/mixed; boundary="_002_55DC663C2F4F9F439F23543E0078E8B30A6D3BEXC001_" MIME-Version: 1.0 Cc: Josh Howlett Subject: Re: [plasma] [abfab] FW: New Non-WG Mailing List: plasma -- The PoLicy Augmented S/Mime (plasma) bof discussion list X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 08 Feb 2011 10:26:55 -0000 --_002_55DC663C2F4F9F439F23543E0078E8B30A6D3BEXC001_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank you. After a quick review of your docs, my sense is that Abfab could = make sense in your scenarios. If I have understood you correctly, I think you are suggesting refactoring = Schaad-eps-trust such that it can use alternative bindings: WS-Trust or AAA. I'm still undecided whether we are best served using a general purpose AAA-= XML attribute, or domain-specific AAA-SAML and AAA-PLASMA attributes. They = both share certain requirements of the AAA layer. The consideration that weighs most in my mind is the implementation implica= tions of a general purpose XML attributes. We definitely don't want to requ= ire AAA proxies to parse the attribute's XML blob to determine the next hop. However, there's a similar issue in the AAA-SAML case where AAA proxies nee= d to disambiguate between different types of SAML Issuers. I have suggested= (see attached) using standard function-specific identifiers in the AAA Net= work Access Identifier. So, PLASMA could perhaps also define an identifier(= s) that provide the necessary routing cue(s). Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG --_002_55DC663C2F4F9F439F23543E0078E8B30A6D3BEXC001_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Tue, 08 Feb 2011 10:27:17 GMT"; modification-date="Tue, 08 Feb 2011 10:27:17 GMT" Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0218.012; Tue, 18 Jan 2011 16:08:57 +0000 From: Josh Howlett To: Sam Hartman CC: Leif Johansson , "abfab@ietf.org" , Josh Howlett Subject: RE: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml Thread-Topic: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml Thread-Index: AQHLtyVPIyHwctNWOUmE/oDJ1svZrpPW4XIg Date: Tue, 18 Jan 2011 16:08:56 +0000 Message-ID: <55DC663C2F4F9F439F23543E0078E8B307F21D@EXC001> References: <55DC663C2F4F9F439F23543E0078E8B305A4C9@EXC001> <55DC663C2F4F9F439F23543E0078E8B305A7B8@EXC001> <7EE86E89365CA94F8E7B8251F9260710035160@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100351DE@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F9260710035299@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100352B9@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F926071003532C@CIO-KRC-D1MBX01.osuad.osu.edu> <4D3406DF.2050106@sunet.se> <55DC663C2F4F9F439F23543E0078E8B30779F3@EXC001> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Internal X-MS-Exchange-Organization-AuthMechanism: 04 X-MS-Exchange-Organization-AuthSource: EXC001.atlas.ukerna.ac.uk X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 > >> Control question for Sam and Scott: is it possible (and > >> reasonably easy) to do SP-centric attribute aggregation for > >> abfab, by which I mean having the SP issue additional attribute > >> queries to IdPs within the AAA-centric trust model proposed by > >> Sam and Josh? > > Josh> Yes, possible and easy (assuming, obviously, we can assume > Josh> that the SPs and IdP have a common identifier for the > Josh> subject). > > Josh, I suspect you are right, but the details are not clear to me. Nor me in truth; I suspect that I am about to discover it was inadvisable o= f me to claim 'easy' :-) > How does the SP address the request to a particular AA? The model that I have in mind is that we specify a set of standard endpoint= locator names for different type of Issuer roles. These can be used, in co= njunction with the NAI realm of the Issuer, to construct a complete NAI. e.g. say we specify the "saml-20-aa" name to mean a SAML 2.0 attribute auth= ority. An SP wanting to route a message to this actor to example.com prefix= es the realm of the intended Issuer with this, thus "saml-20-aa.example.com= ". The AAA SAML attribute within this request message contains a SAML Reque= st message containing the identifier for the subject. Josh. --_002_55DC663C2F4F9F439F23543E0078E8B30A6D3BEXC001_--