From jimsch@augustcellars.com Thu Dec 6 12:53:15 2012 Return-Path: X-Original-To: plasma@ietfa.amsl.com Delivered-To: plasma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 403CD21F8925 for ; Thu, 6 Dec 2012 12:53:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mu28eiAKe6oQ for ; Thu, 6 Dec 2012 12:53:14 -0800 (PST) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 9154021F88CD for ; Thu, 6 Dec 2012 12:53:14 -0800 (PST) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id DD8A038F0B for ; Thu, 6 Dec 2012 12:53:13 -0800 (PST) From: "Jim Schaad" To: Date: Thu, 6 Dec 2012 12:53:03 -0800 Message-ID: <014001cdd3f3$af7c3940$0e74abc0$@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: Ac3TfgPXLLtPG003SzOgdHO5bPZNBQ== Content-Language: en-us Subject: [plasma] Plasma Document Updates X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.12 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, 06 Dec 2012 20:53:15 -0000 I am currently in the middle of doing a large revision of the two documents that I am the primary author on. In the process of doing this update, I have a few issues that I would like people to comment on. 1. I am considering changing the element "WS-Token" in "AuthenticationType". Since the only place where this is currently being used is for dealing with role tokens, I believe it would be useful to change the name of the element to "RoleToken" as this would make it clearer what goes here. 2. In the CMS document I have change the label from being an ASN.1 encoded string to being the XML encoded string. However, I am wondering if we should make this an OCTET STRING which holds the XML encoded string so that we can allow for compression to occur as an optional method of encoding it. Does anyone see any problems with this? I have been thinking about the suggested on renaming from Ed and looking at XAML. I have decided to use Policy and PolicySet as the replacements for Label/Leaf in this update. However there are still some things that I have not really made any conclusions for. 3. Should we switch from using a simple string, or augment the simple string, by allowing the XACML PolicyCombiningAlgId URIs this means that "urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:deny-overrides" and "and" are the same thing. There is no equivalent to "except", but it is also possible this one is a figment of my imagination and there is no real need for it. One can do this in XACML by combining default-permit and default-deny policies but I don't know if it is needed in real life or not. The benefit of allowing the additional URIs is that there are a set of policy combining algorithms already defined by XACML that should correspond to things that are real and it makes it easier to augment the set of combining strings. The downside is that URIs are longer than the set of short strings - does anyone have opinions on this? The other downside of using URIs is that the server may need to give the list of supported combining algorithms to the client or we need to have an error for saying that a combining algorithm is not supported. 4. I am still working my way through the ways of specifying policy options and have not made any decisions for myself let along ones that I would be willing to impose on the document. Any other options and opinions that anyone wants to put in as input, I would be more than willing to get that input at this time. Jim From Ed.Simon@titus.com Thu Dec 6 18:27:33 2012 Return-Path: X-Original-To: plasma@ietfa.amsl.com Delivered-To: plasma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29C5C21E8039 for ; Thu, 6 Dec 2012 18:27:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHWZx2nsWk+m for ; Thu, 6 Dec 2012 18:27:30 -0800 (PST) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.255.50]) by ietfa.amsl.com (Postfix) with ESMTP id 9482521E8043 for ; Thu, 6 Dec 2012 18:27:30 -0800 (PST) Received: from [216.82.254.243:17050] by server-11.bemta-7.messagelabs.com id CA/3B-14264-21451C05; Fri, 07 Dec 2012 02:27:30 +0000 X-Env-Sender: Ed.Simon@titus.com X-Msg-Ref: server-5.tower-203.messagelabs.com!1354847248!12376467!1 X-Originating-IP: [67.210.173.99] X-StarScan-Received: X-StarScan-Version: 6.6.1.8; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3713 invoked from network); 7 Dec 2012 02:27:29 -0000 Received: from 67-210-173.99.static.tel-ott.com (HELO snakeskin.titus.com) (67.210.173.99) by server-5.tower-203.messagelabs.com with AES128-SHA encrypted SMTP; 7 Dec 2012 02:27:29 -0000 Received: from E10MB3.tituscorp.local ([fe80::84f4:cfbe:f32f:9a5]) by E10CH1.tituscorp.local ([192.168.200.115]) with mapi id 14.03.0099.000; Thu, 6 Dec 2012 21:27:27 -0500 From: Ed Simon To: Jim Schaad , "plasma@ietf.org" Thread-Topic: [plasma] Plasma Document Updates Thread-Index: Ac3TfgPXLLtPG003SzOgdHO5bPZNBQAiVlKQ Date: Fri, 7 Dec 2012 02:27:26 +0000 Message-ID: References: <014001cdd3f3$af7c3940$0e74abc0$@augustcellars.com> In-Reply-To: <014001cdd3f3$af7c3940$0e74abc0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [plasma] Plasma Document Updates X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.12 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, 07 Dec 2012 02:27:33 -0000 Thanks Jim, 1. I agree about switching from to . 2. I agree with OctetString to accommodate compressed XML (e.g. EXI). 3. Re combining algorithms, my opinion is that we should use the full XACML= combining algorithm identifiers and, of course, clients would provide frie= ndly names/interfaces (e.g. "AND" instead of "urn:oasis:xacml:...:deny-over= rides"). Re which combining algorithms are supported, could PLASMA * for at least v1, define a limited set (just "AND" and "OR"); or * require all mandatory XACML-specified combining algorithms.=20 4. Re specifying policy options, maybe borrowing the XACML element= would be sensible; would not PLASMA policy options basically equivalent to= AND'ing a GetCMSToken // with the server's //? (Not that the server's policy engine has to be X= ACML, but even in other policy languages, the "AND'ing of targets" concept = would still apply.) Ed ________________________________________ From: plasma-bounces@ietf.org [plasma-bounces@ietf.org] on behalf of Jim Sc= haad [jimsch@augustcellars.com] Sent: Thursday, December 06, 2012 15:53 To: plasma@ietf.org Subject: [plasma] Plasma Document Updates I am currently in the middle of doing a large revision of the two documents that I am the primary author on. In the process of doing this update, I have a few issues that I would like people to comment on. 1. I am considering changing the element "WS-Token" in "AuthenticationType". Since the only place where this is currently being used is for dealing with role tokens, I believe it would be useful to chang= e the name of the element to "RoleToken" as this would make it clearer what goes here. 2. In the CMS document I have change the label from being an ASN.1 encoded string to being the XML encoded string. However, I am wondering if we should make this an OCTET STRING which holds the XML encoded string so that we can allow for compression to occur as an optional method of encoding it. Does anyone see any problems with this? I have been thinking about the suggested on renaming from Ed and looking a= t XAML. I have decided to use Policy and PolicySet as the replacements for Label/Leaf in this update. However there are still some things that I have not really made any conclusions for. 3. Should we switch from using a simple string, or augment the simple string, by allowing the XACML PolicyCombiningAlgId URIs this means that "urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:deny-overrides" an= d "and" are the same thing. There is no equivalent to "except", but it is also possible this one is a figment of my imagination and there is no real need for it. One can do this in XACML by combining default-permit and default-deny policies but I don't know if it is needed in real life or not. The benefit of allowing the additional URIs is that there are a set of policy combining algorithms already defined by XACML that should correspond to things that are real and it makes it easier to augment the set of combining strings. The downside is that URIs are longer than the set of short strings - does anyone have opinions on this? The other downside of using URIs is that the server may need to give the list of supported combining algorithms to the client or we need to have an error for saying that a combining algorithm is not supported. 4. I am still working my way through the ways of specifying policy options and have not made any decisions for myself let along ones that I would be willing to impose on the document. Any other options and opinions that anyone wants to put in as input, I would be more than willing to get that input at this time. Jim _______________________________________________ plasma mailing list plasma@ietf.org https://www.ietf.org/mailman/listinfo/plasma From trevorf@exchange.microsoft.com Fri Dec 14 13:47:35 2012 Return-Path: X-Original-To: plasma@ietfa.amsl.com Delivered-To: plasma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4DF621F8A7C for ; Fri, 14 Dec 2012 13:47:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWTKhOMsUF03 for ; Fri, 14 Dec 2012 13:47:35 -0800 (PST) Received: from NA01-SN2-obe.outbound.o365filtering.com (na01-sn2-obe.ptr.o365filtering.com [157.55.158.23]) by ietfa.amsl.com (Postfix) with ESMTP id DED4F21F880B for ; Fri, 14 Dec 2012 13:47:34 -0800 (PST) Received: from BL2SR01CA102.namsdf01.sdf.exchangelabs.com (10.255.109.147) by BL2SR01MB606.namsdf01.sdf.exchangelabs.com (10.255.109.168) with Microsoft SMTP Server (TLS) id 15.0.586.11; Fri, 14 Dec 2012 21:47:32 +0000 Received: from BY1FFOFD002.ffo.gbl (64.4.22.92) by BL2SR01CA102.outlook.com (10.255.109.147) with Microsoft SMTP Server (TLS) id 15.0.596.2 via Frontend Transport; Fri, 14 Dec 2012 21:47:32 +0000 Received: from hybrid.exchange.microsoft.com (131.107.1.27) by BY1FFOFD002.mail.o365filtering.com (10.1.16.84) with Microsoft SMTP Server (TLS) id 15.0.586.6 via Frontend Transport; Fri, 14 Dec 2012 21:47:31 +0000 Received: from DFM-TK5MBX15-04.exchange.corp.microsoft.com (157.54.110.23) by DF-G14-02.exchange.corp.microsoft.com (157.54.87.56) with Microsoft SMTP Server (TLS) id 14.3.118.0; Fri, 14 Dec 2012 13:46:26 -0800 Received: from PIO-MLT-06.exchange.corp.microsoft.com (157.54.94.24) by DFM-TK5MBX15-04.exchange.corp.microsoft.com (157.54.110.23) with Microsoft SMTP Server (TLS) id 15.0.516.32; Fri, 14 Dec 2012 13:46:26 -0800 Received: from DF-M14-12.exchange.corp.microsoft.com ([fe80::7c94:4036:120:c95f]) by PIO-MLT-06.exchange.corp.microsoft.com ([fe80::d57f:521a:3ae6:c130%10]) with mapi id 14.03.0118.000; Fri, 14 Dec 2012 13:46:26 -0800 From: Trevor Freeman To: "plasma@ietf.org" Thread-Topic: PLASMA URL Authenticated Attribute Thread-Index: Ac3aRBodWiAB42HpQTKebWE+2de3vA== Date: Fri, 14 Dec 2012 21:46:25 +0000 Message-ID: <3020AC5E95452D43B5D8D0FB02F881D3118C15@DF-M14-12.exchange.corp.microsoft.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.94.16] Content-Type: multipart/alternative; boundary="_000_3020AC5E95452D43B5D8D0FB02F881D3118C15DFM1412exchangeco_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.1.27; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51856001)(49866001)(33656001)(56776001)(76482001)(56816002)(47976001)(55846006)(876001)(5343635001)(4396001)(16236675001)(47736001)(16406001)(47446002)(15202345002)(54356001)(74502001)(46102001)(54316002)(44976002)(512954001)(74662001)(31966008)(5343655001)(77982001)(59766001)(53806001)(50986001)(217873001); DIR:OUT; SFP:; SCL:1; SRVR:BL2SR01MB606; LANG:en; X-Forefront-PRVS: 06952FC175 X-OriginatorOrg: DuplicateDomain-6c178e33-aecb-4786-8220-9afceeddbaf3.exchange.microsoft.com Subject: [plasma] PLASMA URL Authenticated Attribute X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.12 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, 14 Dec 2012 21:47:36 -0000 --_000_3020AC5E95452D43B5D8D0FB02F881D3118C15DFM1412exchangeco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jim, I was just looking at the CMS document in section 3.3 and noticed that the = Plasma URL is defined as a single UTF8Sting. aa-plasma-url ATTRIBUTE ::=3D {TYPE UTF8String IDENTIFIED BY id-aa-plasma-u= rl} This should be a Set of UTF8Stings as we can have more than one Plasma serv= er on a message. Trevor --_000_3020AC5E95452D43B5D8D0FB02F881D3118C15DFM1412exchangeco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jim,

 

I was just looking at the CMS document in section 3.= 3 and noticed that the Plasma URL is defined as a single UTF8Sting.

 

aa-plasma-url ATTRIBUTE ::=3D {TYPE UTF8Stri= ng IDENTIFIED BY id-aa-plasma-url}

 

This should be a Set o= f UTF8Stings as we can have more than one Plasma server on a message.<= /o:p>

 

Trevor

--_000_3020AC5E95452D43B5D8D0FB02F881D3118C15DFM1412exchangeco_-- From ietf@augustcellars.com Sat Dec 15 16:35:12 2012 Return-Path: X-Original-To: plasma@ietfa.amsl.com Delivered-To: plasma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 616E021F8536 for ; Sat, 15 Dec 2012 16:35:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.854 X-Spam-Level: X-Spam-Status: No, score=-2.854 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXW7SjgwBoM7 for ; Sat, 15 Dec 2012 16:35:11 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 0A22121F852D for ; Sat, 15 Dec 2012 16:35:10 -0800 (PST) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 49C3F38F18; Sat, 15 Dec 2012 16:35:10 -0800 (PST) From: "Jim Schaad" To: "'Trevor Freeman'" , References: <3020AC5E95452D43B5D8D0FB02F881D3118C15@DF-M14-12.exchange.corp.microsoft.com> In-Reply-To: <3020AC5E95452D43B5D8D0FB02F881D3118C15@DF-M14-12.exchange.corp.microsoft.com> Date: Sat, 15 Dec 2012 16:34:56 -0800 Message-ID: <000401cddb25$2c986470$85c92d50$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01CDDAE2.1E76AB10" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQM3hlRRyoVD+URqobjX0v7NF/lJ/ZVHPWvQ Content-Language: en-us Subject: Re: [plasma] PLASMA URL Authenticated Attribute X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 16 Dec 2012 00:35:12 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0005_01CDDAE2.1E76AB10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit No this is correct, the SET OF comes based on if you use the single attribute macro or the multiple attributes macro. You need to look at how signed attributes are defined for CMS> Jim From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of Trevor Freeman Sent: Friday, December 14, 2012 1:46 PM To: plasma@ietf.org Subject: [plasma] PLASMA URL Authenticated Attribute Hi Jim, I was just looking at the CMS document in section 3.3 and noticed that the Plasma URL is defined as a single UTF8Sting. aa-plasma-url ATTRIBUTE ::= {TYPE UTF8String IDENTIFIED BY id-aa-plasma-url} This should be a Set of UTF8Stings as we can have more than one Plasma server on a message. Trevor ------=_NextPart_000_0005_01CDDAE2.1E76AB10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

No this is correct, the = SET OF comes based on if you use the single attribute macro or the = multiple attributes macro.  You need to look at how signed = attributes are defined for CMS>

 

Jim

 

 

From:= = plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of = Trevor Freeman
Sent: Friday, December 14, 2012 1:46 = PM
To: plasma@ietf.org
Subject: [plasma] PLASMA URL = Authenticated Attribute

 

Hi = Jim,

 

I was just looking at the CMS document in section 3.3 = and noticed that the Plasma URL is defined as a single UTF8Sting. =

 

aa-plasma-url ATTRIBUTE = ::=3D {TYPE UTF8String IDENTIFIED BY id-aa-plasma-url} =

 

This should be a Set of UTF8Stings as we = can have more than one Plasma server on a message.

 

Trevor

------=_NextPart_000_0005_01CDDAE2.1E76AB10--