From trevorf@exchange.microsoft.com Wed Aug 1 10:26:25 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 D9EC911E839C for ; Wed, 1 Aug 2012 10:26:25 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Y+wcahnJieN for ; Wed, 1 Aug 2012 10:26:17 -0700 (PDT) Received: from na01b.map.o365filtering.com (sn2c-ob.o365filtering.com [157.55.158.28]) by ietfa.amsl.com (Postfix) with ESMTP id F09D711E812A for ; Wed, 1 Aug 2012 10:26:16 -0700 (PDT) Received: from CH1SR01CA103.namsdf01.sdf.exchangelabs.com (10.255.157.20) by CH1SR01MB611.namsdf01.sdf.exchangelabs.com (10.255.157.39) with Microsoft SMTP Server (TLS) id 15.0.466.11; Wed, 1 Aug 2012 17:16:27 +0000 Received: from SN2FFOFD002.ffo.gbl (157.55.158.26) by CH1SR01CA103.namsdf01.sdf.exchangelabs.com (10.255.157.20) with Microsoft SMTP Server (TLS) id 15.0.485.4; Wed, 1 Aug 2012 17:16:27 +0000 Received: from hybrid.exchange.microsoft.com (131.107.1.27) by SN2FFOFD002.mail.o365filtering.com (10.111.201.21) with Microsoft SMTP Server (TLS) id 15.0.485.0; Wed, 1 Aug 2012 17:16:27 +0000 Received: from DFM-TK5MBX15-07.exchange.corp.microsoft.com (157.54.109.46) by DF-G14-02.exchange.corp.microsoft.com (157.54.87.56) with Microsoft SMTP Server (TLS) id 14.3.71.0; Wed, 1 Aug 2012 10:15:43 -0700 Received: from PIO-MLT-05.exchange.corp.microsoft.com (157.54.94.22) by DFM-TK5MBX15-07.exchange.corp.microsoft.com (157.54.109.46) with Microsoft SMTP Server (TLS) id 15.0.466.15; Wed, 1 Aug 2012 10:15:42 -0700 Received: from DF-M14-12.exchange.corp.microsoft.com ([fe80::7c94:4036:120:c95f]) by PIO-MLT-05.exchange.corp.microsoft.com ([fe80::d940:e316:1daa:5e6a%10]) with mapi id 14.03.0071.000; Wed, 1 Aug 2012 10:15:42 -0700 From: Trevor Freeman To: Jean-Paul Buu-Sao , "plasma@ietf.org" Thread-Topic: [plasma] Open-Environments Thread-Index: Ac1r4hLnx0xLfr9ARjCSuILVzpj/KQEJLz5g Date: Wed, 1 Aug 2012 17:15:41 +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.94.18] Content-Type: multipart/alternative; boundary="_000_E545B914D50B2A4B994F198378B1525D5B8F00A2DFM1412exchange_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.1.27; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(407274001)(377454001)(243025001)(13464001)(164054002)(5343635001)(5343655001)(16406001)(42186003)(33656001)(512954001)(266001)(31966006); DIR:INB; ; LANG:en; X-Forefront-PRVS: 0560A2214D X-OriginatorOrg: DuplicateDomain-6c178e33-aecb-4786-8220-9afceeddbaf3.exchange.microsoft.com Subject: Re: [plasma] Open-Environments 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: Wed, 01 Aug 2012 17:26:26 -0000 --_000_E545B914D50B2A4B994F198378B1525D5B8F00A2DFM1412exchange_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jean-Paul, The type of open I referred to was open world Assumption (http://en.wikiped= ia.org/wiki/Open_World_Assumption). This is essentially whether you conside= r your knowledge base to be complete (closed) or not (open). If you look at the sequence of plasma tokens (role token, message token, re= ad token) The role token is a closed world and the message and read tokens = are open world. The role token has to be a closed world as it generates the= finite set of policies the user can use. This collection of polices has al= so been referred to as a protection profile. It is configured by the admini= strator to meet the needs to the role. Subsequent tokens use an open world = assumption, so that a PDEP can discover as required new policies. That said= , the policy is in many ways no different to other attributes a PDP receive= s in that the PDEP has to have some policy around PAP it trusts. If a reque= st is made to a PDEP which requires a policy from a PAP it does not trusted= , then the PDEP would know to reply "don't know" just as it would if it cou= ld not reach the policy uri. The Plasma client can then try another PDEP. Trevor -----Original Message----- From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of= Jean-Paul Buu-Sao Sent: Friday, July 27, 2012 3:27 AM To: plasma@ietf.org Subject: [plasma] Open-Environments Thank you Patrick for forwarding the response from Trevor. Reading at them = I see that there is one remaining comment that needs discussion (given that= Richard Skedd has already created a thread on basic and Advanced Policies,= that I will not re-iterate here). This is the question of Open Environment= s. [JP] .... TSCP expected to see a workflow that could as well support an "op= en environment", whereas not all referenced policies are necessarily known = by the local PDP/PAP ahead of time. [TF] Since the PAP authors the policies and creates the policy reference, I= don't understand a client can have a policy reference that a PAP does not = know about so can you describe how this would occur. [JP] In earlier discussions that we had in TSCP forums, you pushed forward = the capability of PLASMA to operate in environments where not all policies = are known, which you called "open environments". In this context, what I me= ant by " ... not all referenced policies are necessarily known by the local= PDP/PAP ahead of time" is that the local PAP did not author such policy, w= hich was authored by a non-local (remote) PAP in a different domain. Is the= distinction between local PAP and remote PAP useful to the discussion? I t= hink it is, as this difference potentially implies a difference on the trus= t model. I believe that, in order to support open environments, a dedicated= trust model needs to be specified. Is it possible to discover a policy URI= , and dereference it, without ensuring of the trustworthiness of the source= ? Those are some of the issues that, IMO, need to be called out in the docu= ment. Thanks, JP -----Original Message----- From: Patrick Patterson [mailto:ppatterson@carillon.ca] Sent: Wednesday, July 25, 2012 17:08 To: Jean-Paul Buu-Sao Cc: plasma@ietf.org Subject: Re: [plasma] Comments on Message Access Control Requirements Draft The following message has been forwarded from Trevor, as he is still having= difficulties posting to the list: ----- BEGIN FORWARDED MESSAGE ----- Hi Jean-Paul, Just catching up from Holiday. I have just posted a new draft of the requirements doc you may want to chec= k out. We have has a lot of feedback on our terminology so this new draft h= as attempted to improve that area. We have changed PEP to be a Decision Requestor to more clearly indicate it = does not enforce decisions. We did not adopt the Access Requestor name from= the XACML model as we have other types of decisions such as integrity poli= cy decision requests. PDP has changed to Policy Decision and Enforcement Point to emphasize in th= e Plasma model these functions are logically one. That does not preclude im= plementations from implementing them as separate entities but that implemen= tations detail would not impact Plasma. You should also read the technical drafts from the implantation details. http://datatracker.ietf.org/doc/draft-schaad-plasma-cms/ http://datatracker.ietf.org/doc/draft-schaad-plasma-service/ More inline below Trevor -----Original Message----- From: plasma-bounces@ietf.org> [mailto:plasma-bounces@= ietf.org] On Behalf Of Jean-Paul Buu-Sao Sent: Monday, July 23, 2012 1:25 AM To: plasma@ietf.org> Subject: [plasma] Comments on Message Access Control Requirements Draft Greetings, Please find my comments on the PLASMA draft 01: http://tools.ietf.org/pdf/d= raft-freeman-plasma-requirements-01.pdf: 1) Policy Data Binding Section 4.2.1: "The chief strength of binding by names is once bound to the data the assoc= iation with the policy travels with the data. The chief weakness in binding= by name is it requires the reference to be strongly bound to the data [...= ] This model is choosing to use binding by name because we need to encrypt = the data which means we will [be] impacting the storage format anyway which= negates the main weakness of binding my name." TSCP approves of the choice of "binding by name". Another chief strength th= at you did not quote, and which is key differentiator to TSCP, is to allow = policy change, with no impact on the data. This requirement cannot be met w= ith binding by value or by description. [TF] Good Point will add this to the draft The draft is silent on how the name would be expressed. Can it be any arbit= rary identifier, which precise syntax and semantics could be defined by a c= ommunity of interest defined profile? [TF] If you read the plasma service draft you will see we use a URI. We bel= ieve that has sufficient flexibility to address the requirements you descri= be. 2) Closed versus Open environment Section 4.4: "(A) The PEP verifies the certificate in the signed metadata then determine= s <> if it want to process the protected information base= d on the identity of the PDP (D) The PDP decrypts the metadata, de-references the policy pointers and de= termines the set of access rules based on the <>. The PDP then determines the set of subject attributes it needs to evalu= ate the access rules. The PDP can the use PIP is has relationships with to = query attributers about the subject. The list of attributes the PDP is miss= ing is then returned to the PEP" As stated the workflow implies a "closed environment". TSCP expected to see= a workflow that could as well support an "open environment", whereas not a= ll referenced policies are necessarily known by the local PDP/PAP ahead of = time. [TF] Since the PAP authors the policies and creates the policy reference, I= don't understand a client can have a policy reference that a PAP does not = know about so can you describe how this would occur. There are a logical sequence of PDEPs in Plasma. These can be physically th= e same PDEP or they can be separate PDEPs. * The PDEP which generates the role token * The PDEP which generates the message token * The PDEP which generates the read token Only the first PDEP needs prior knowledge of the policies which is necessar= y for it to generate the policy collection in the role token. All subsequen= t PDEPs can use the URI to discover the policies. As a related topic, Policy Publication Point (PPP), lightly introduced in t= he Vocabulary section, is a good addition to [RFC3198] and [XACML-core]. In= view of the support for "open environments", TSCP expected to see more req= uirements on PPP. 3) Advanced Policies Section 4.5.2: "Advanced policy is intended to be used where one or more a= rbitrary policies are required on the content. It is intended to target mor= e complex scenarios such as content with regulated information or content s= ubject to other organization and contractual policies. The input set of att= ributes is defined by the policies and can be either primordial or derived = attributes or both. Multiple policies have a logical relationship e.g. they= can be <>. <>." [TF] The text was not intended to indicate only simple logical relationship= s would be expressed so I will change to say "AND and/or ORed together in a= n arbitrary combination". The technical draft uses a logic trees so already= supports what you describe. TSCP mandates a support for "advances policies". [TF] I understand some communities of interest would require use of Advance= s Polices. However I don't want to burden every Plasma client implementatio= n to support such policies. The basic policy set is aimed a simple set of s= cenarios where the Plasma client may well be bundled in at no charge so any= additional complexity would be a tax. A premium client which supports adva= nced polices can then be purchased where there is business value in doing s= o e.g. a mandate from a community of interest such as TSCP. A typical example is to support documents that must be simultaneously prote= cted under an Export Control policy (e.g. ITAR Technical Assistance Agreeme= nt) and an Intellectual Property policy (e.g. Proprietary Information Excha= nge Agreement). In this case of multiple policies, TSCP requires that all t= he applicable policies are to be evaluated, with each one of the specified = policy allowing the required access. So this cannot just be a simple OR, as the Plasma draft states. 4) Policy Expression Language The draft is silent on the positioning of PLASMA with Policy Expression Lan= guages. Is there one in particular that PLASMA mandates (if so, which one),= or is the specification agnostic (if so, what are the baseline requirement= s in terms of expressiveness)? [TF] For the requirements I intend to be language neutral. We do intend to = address PDAP-PAP interaction in a subsequent technical paper where the topi= c will have to be addressed. Some communities of interest have made signifi= cant investments in XACML but it has not been universally adopted so plasm= a has a tradeoff between mandating a specific language to improve interoper= ability and alienating communities to do not use XACML. I don't know the ri= ght answer at this time but that answer does not impact the current work. = We do need to support language negotiation between PDEP and PAP so at a min= imum so we can support communities of interest and also be forwards compati= ble. Some organizations have developed and validated a broad set of policies, ex= pressed in a Policy Expression Language of their choosing (e.g. XACML 2.0),= and need to be able to reuse them. Thanks, Jean-Paul Buu-Sao, TSCP ---- END FORWARDED MESSAGE ----- --- Patrick Patterson President and Chief PKI Architect Carillon Information Security Inc. http://www.carillon.ca tel: +1 514 485 0789 mobile: +1 514 994 8699 fax: +1 450 424 9559 _______________________________________________ plasma mailing list plasma@ietf.org https://www.ietf.org/mailman/listinfo/plasma --_000_E545B914D50B2A4B994F198378B1525D5B8F00A2DFM1412exchange_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jean-Paul,

 

The type of open I referred to was open world Assumption (= http://en.wi= kipedia.org/wiki/Open_World_Assumption). This is essentially whether you consider your knowledge base to be complete (closed) or not (o= pen).

 

If you look at the sequence of plasma tokens (role token, = message token, read token) The role token is a closed world and the message= and read tokens are open world. The role token has to be a closed world as it generates the finite set of policies the user can use= . This collection of polices has also been referred to as a protection prof= ile. It is configured by the administrator to meet the needs to the role. S= ubsequent tokens use an open world assumption, so that a PDEP can discover as required new policies. That sai= d, the policy is in many ways no different to other attributes a PDP receiv= es in that the PDEP has to have some policy around PAP it trusts. If a requ= est is made to a PDEP which requires a policy from a PAP it does not trusted, then the PDEP would know to reply= “don’t know” just as it would if it could not reach the = policy uri. The Plasma client can then try another PDEP.

 

Trevor

 

-----Original Message-----
From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of= Jean-Paul Buu-Sao
Sent: Friday, July 27, 2012 3:27 AM
To: plasma@ietf.org
Subject: [plasma] Open-Environments

 

Thank you Patrick for forwarding the response from Trevor.= Reading at them I see that there is one remaining comment that needs discu= ssion (given that Richard Skedd has already created a thread on basic and Advanced Policies, that I will not re-iterate here). This is = the question of Open Environments.

 

[JP] .... TSCP expected to see a workflow that could as we= ll support an "open environment", whereas not all referenced poli= cies are necessarily known by the local PDP/PAP ahead of time.

[TF] Since the PAP authors the policies and creates the po= licy reference, I don't understand a client can have a policy reference tha= t a PAP does not know about so can you describe how this would occur.

 

[JP] In earlier discussions that we had in TSCP forums, yo= u pushed forward the capability of PLASMA to operate in environments where = not all policies are known, which you called "open environments". In this context, what I meant by " ... not all referenced policies ar= e necessarily known by the local PDP/PAP ahead of time" is that the lo= cal PAP did not author such policy, which was authored by a non-local (remo= te) PAP in a different domain. Is the distinction between local PAP and remote PAP useful to the discussion? I think it is, = as this difference potentially implies a difference on the trust model. I b= elieve that, in order to support open environments, a dedicated trust model= needs to be specified. Is it possible to discover a policy URI, and dereference it, without ensuring of the trus= tworthiness of the source? Those are some of the issues that, IMO, need to = be called out in the document.

 

Thanks,

JP

 

-----Original Message-----

From: Patrick Patterson [mailto:ppatterson@carillon.ca]

Sent: Wednesday, July 25, 2012 17:08

To: Jean-Paul Buu-Sao

Cc: plasma@ietf.org

Subject: Re: [plasma] Comments on Message Access Control R= equirements Draft

 

The following message has been forwarded from Trevor, as h= e is still having difficulties posting to the list:

 

----- BEGIN FORWARDED MESSAGE -----

 

Hi Jean-Paul,

 

Just catching up from Holiday.

 

I have just posted a new draft of the requirements doc you= may want to check out. We have has a lot of feedback on our terminology so= this new draft has attempted to improve that area.

 

We have changed PEP to be a Decision Requestor to more cle= arly indicate it does not enforce decisions. We did not adopt the Access Re= questor name from the XACML model as we have other types of decisions such as integrity policy decision requests.=

 

PDP has changed to Policy Decision and Enforcement Point t= o emphasize in the Plasma model these functions are logically one. That doe= s not preclude implementations from implementing them as separate entities but that implementations detail would not impact Plasma.=

 

You should also read the technical drafts from the implant= ation details.

 

http://dat= atracker.ietf.org/doc/draft-schaad-plasma-cms/=

http:/= /datatracker.ietf.org/doc/draft-schaad-plasma-service/

 

More inline below

 

Trevor

 

-----Original Message-----

From: plasma-bounces@ietf.o= rg<mailto:plasma-bounces@ietf.org> [mailto:plasma-bounces@ietf.org]&= lt;mailto:[mailto:plasma-bounces@ietf.org]> On Behalf Of Jean-Paul Buu-Sao

Sent: Monday, July 23, 2012 1:25 AM

To: plasma@ietf.org<ma= ilto:plasma@ietf.org>

Subject: [plasma] Comments on Message Access Control Requi= rements Draft

 

 

 

Greetings,

 

 

 

Please find my comments on the PLASMA draft 01: http://tools.ietf= .org/pdf/draft-freeman-plasma-requirements-01.pdf:

 

 

 

1) Policy Data Binding

 

 

 

Section 4.2.1:

 

"The chief strength of binding by names is once bound= to the data the association with the policy travels with the data. The chi= ef weakness in binding by name is it requires the reference to be strongly bound to the data [...] This model is choosing to use binding = by name because we need to encrypt the data which means we will [be] impact= ing the storage format anyway which negates the main weakness of binding my= name."

 

TSCP approves of the choice of "binding by name"= . Another chief strength that you did not quote, and which is key different= iator to TSCP, is to allow policy change, with no impact on the data. This requirement cannot be met with binding by value or by description.

 

[TF] Good Point will add this to the draft

 

The draft is silent on how the name would be expressed. Ca= n it be any arbitrary identifier, which precise syntax and semantics could = be defined by a community of interest defined profile?

 

[TF] If you read the plasma service draft you will see we = use a URI. We believe that has sufficient flexibility to address the requir= ements you describe.

 

 

 

2) Closed versus Open environment

 

Section 4.4:

 

"(A) The PEP verifies the certificate in the signed m= etadata then determines <<via local policy>> if it want to proc= ess the protected information based on the identity of the PDP

 

(D) The PDP decrypts the metadata, de-references the polic= y pointers and determines the set of access rules based on the <<poli= cy published by the PAP>>. The PDP then determines the set of subject attributes it needs to evaluate the access rules. The PDP can the = use PIP is has relationships with to query attributers about the subject. T= he list of attributes the PDP is missing is then returned to the PEP"<= o:p>

 

As stated the workflow implies a "closed environment&= quot;. TSCP expected to see a workflow that could as well support an "= open environment", whereas not all referenced policies are necessarily known by the local PDP/PAP ahead of time.

 

[TF] Since the PAP authors the policies and creates the po= licy reference, I don't understand a client can have a policy reference tha= t a PAP does not know about so can you describe how this would occur.

 

There are a logical sequence of PDEPs in Plasma. These can= be physically the same PDEP or they can be separate PDEPs.

 

*        The PDEP which= generates the role token

 

*        The PDEP which= generates the message token

 

*        The PDEP which= generates the read token

 

Only the first PDEP needs prior knowledge of the policies = which is necessary for it to generate the policy collection in the role tok= en. All subsequent PDEPs can use the URI to discover the policies.

 

As a related topic, Policy Publication Point (PPP), lightl= y introduced in the Vocabulary section, is a good addition to [RFC3198] and= [XACML-core]. In view of the support for "open environments", TSCP expected to see more requirements  on PPP.

 

 

 

3) Advanced Policies

 

Section 4.5.2:  "Advanced policy is intended to = be used where one or more arbitrary policies are required on the content. I= t is intended to target more complex scenarios such as content with regulated information or content subject to other organization and contrac= tual policies. The input set of attributes is defined by the policies and c= an be either primordial or derived attributes or both. Multiple policies ha= ve a logical relationship e.g. they can be <<AND or ORed together>>. <<It is not expected th= at all Plasma clients support advances policy>>."

 

[TF] The text was not intended to indicate only simple log= ical relationships would be expressed so I will change to say "AND and= /or ORed together in an arbitrary combination". The technical draft uses a logic trees so already supports what you describe.=

 

 

 

TSCP mandates a support for "advances policies".=

 

[TF] I understand some communities of interest would requi= re use of Advances Polices. However I don't want to burden every Plasma cli= ent implementation to support such policies. The basic policy set is aimed a simple set of scenarios where the Plasma client may well be= bundled in at no charge so any additional complexity would be a tax. A pre= mium client which supports advanced polices can then be purchased where the= re is business value in doing so e.g. a mandate from a community of interest such as TSCP.

 

A typical example is to support documents that must be sim= ultaneously protected under an Export Control policy (e.g. ITAR Technical A= ssistance Agreement) and an Intellectual Property policy (e.g. Proprietary Information Exchange Agreement). In this case of multipl= e policies, TSCP requires that all the applicable policies are to be evalua= ted, with each one of the specified policy allowing the required access.

 

So this cannot just be a simple OR, as the Plasma draft st= ates.

 

 

 

 

 

4) Policy Expression Language

 

The draft is silent on the positioning of PLASMA with Poli= cy Expression Languages. Is there one in particular that PLASMA mandates (i= f so, which one), or is the specification agnostic (if so, what are the baseline requirements in terms of expressiveness)?=

 

 

[TF] For the requirements I intend to be language neutral.= We do intend to address PDAP-PAP interaction in a subsequent technical pap= er where the topic will have to be addressed. Some communities of interest have made significant investments in  XACML but it has no= t been universally adopted so plasma has a tradeoff between mandating a spe= cific language to improve interoperability and alienating communities to do= not use XACML. I don't know the right answer at this time but that answer does not impact the current work. = ; We do need to support language negotiation between PDEP and PAP so at a m= inimum so we can support communities of interest and also be forwards compa= tible.

 

 

 

Some organizations have developed and validated a broad se= t of policies, expressed in a Policy Expression Language of their choosing = (e.g. XACML 2.0), and need to be able to reuse them.

 

 

 

Thanks,

 

Jean-Paul Buu-Sao, TSCP

 

---- END FORWARDED MESSAGE -----

 

---

Patrick Patterson

President and Chief PKI Architect

Carillon Information Security Inc.

http://www.carillon.ca=

 

tel: +1 514 485 0789

mobile: +1 514 994 8699

fax: +1 450 424 9559

 

 

 

 

 

_______________________________________________=

plasma mailing list

plasma@ietf.org=

<= span style=3D"color:windowtext;text-decoration:none">https://www.ietf.org/m= ailman/listinfo/plasma

--_000_E545B914D50B2A4B994F198378B1525D5B8F00A2DFM1412exchange_-- From jimsch@augustcellars.com Mon Aug 6 14:04: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 F3BC411E80A4 for ; Mon, 6 Aug 2012 14:04:32 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRxS1cVXOKU3 for ; Mon, 6 Aug 2012 14:04:32 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 58AE611E80A5 for ; Mon, 6 Aug 2012 14:04:32 -0700 (PDT) Received: from Tobias (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 smtp2.pacifier.net (Postfix) with ESMTPSA id 256B22CA1F for ; Mon, 6 Aug 2012 14:04:32 -0700 (PDT) From: "Jim Schaad" To: Date: Mon, 6 Aug 2012 14:03:04 -0700 Message-ID: <009b01cd7416$dfc75ea0$9f561be0$@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: Ac10FaYARhwv/PzyR9qfX0+di64/4w== Content-Language: en-us X-Mailman-Approved-At: Mon, 06 Aug 2012 14:16:23 -0700 Subject: [plasma] Should ASN.1 Policy be changed to XML Policy 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: Mon, 06 Aug 2012 21:04:33 -0000 In the EPS-LockBox structure, there is a place to put a policy tree. This is currently coded as an ASN.1 structure with various leaf types. There is an equivalent structure, but encoded in XML in the server protocol document. There are some potential issues with having two different encodings and I am looking for input into the question of moving to a single encoding method. The ASN.1 encoding is going to be smaller, when placed in an ASN.1 context, such as the EPS-LockBox structure. It would probably not be smaller if we used the ASN.1 structure in an XML context because of the base64 expansion of all of the text strings associated with policy names and policy parameters. Having a single method of encoding would mean that there is a single method of encoding and the same parsing could be used in many places, however there is a question of what happens for schema tagging in the case of placing the XML into the ASN.1 context. If we use XML in the ASN.1 context, should we require that a full schema tag be added or would the XML parser be required to deal with any nodes found. There is a high probably that one would need to deal with schema strings for expanded sets of parameters which are currently incorrectly done in the ASN.1 document. I am currently in the process of updating the document and want to have it published before next Monday. I am currently on the fence about making the change to using the XML format of policies in the ASN.1 document. If you want to give me input please do so this week. We can always revisit later if we decide it is wrong, but the fewer times we change this, the better for implementers. Jim From alan.b.borland@googlemail.com Fri Aug 10 06:47:51 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 8A05921F8568 for ; Fri, 10 Aug 2012 06:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.209 X-Spam-Level: X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[AWL=-0.722, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YblFZdZLQkgl for ; Fri, 10 Aug 2012 06:47:50 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id C0C6C21F8501 for ; Fri, 10 Aug 2012 06:47:50 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so2772342pbb.31 for ; Fri, 10 Aug 2012 06:47:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=co4PEZmHHf4T1XHi4Zwg+6BIAZoAN+AIVEscJv7U2EA=; b=xvBd/w+JdO8c4P6X47Zf1wprDKMA1qDtnoIquCco5lhz54cQ+7+LwgrySlvOa6Aq57 8e5CIj2tkC3nO1u4w9G1zlUCzyN8NWzGvH6bGTyRYQWAx8KAZGudZaO0q36BAZDbNthC wg4IjbKdTGoJBFhdijdjQkLRaBVnG47Lg7VnYKQnjVZYycLyInGkUJ+DiXgQkQ9uWh8A pb7iKyPKAkJOsd49xhZi+RMRod1Of4lIlvUCk0RZFi6hFWZCJ7kgZIpicD9MVzRx3eLK ZZ5Evlk93F5Iu1KnCaAm09ndI0mUMfPka6Z1h0R6vmUHRhLC+en2fl2MGNaiwSNu23CE W67w== MIME-Version: 1.0 Received: by 10.68.190.102 with SMTP id gp6mr12923535pbc.5.1344606470468; Fri, 10 Aug 2012 06:47:50 -0700 (PDT) Received: by 10.66.158.168 with HTTP; Fri, 10 Aug 2012 06:47:50 -0700 (PDT) Date: Fri, 10 Aug 2012 14:47:50 +0100 Message-ID: From: Alan Borland To: plasma@ietf.org Content-Type: multipart/alternative; boundary=e89a8ff1c97c08f30404c6e9971b Subject: [plasma] Schema in EPS version '02' 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, 10 Aug 2012 13:47:51 -0000 --e89a8ff1c97c08f30404c6e9971b Content-Type: text/plain; charset=ISO-8859-1 I've just been looking at using the schema from the '02' document of the EPS Trust document. However, I have noticed a problem when compared to the '01' document. In the '01' document the PlasmaResponse "ResponseType" is a sequence of "xacml:Response", "PlasmaTokens", "CMSToken", "CMSKey" and "Authentication". In the '02' document the PlasmaResponse "ResponseType" is a sequence of "xacml:Response" and "PlasmaReturnToken" (PlasmaReturnToken only has a "DecisionId" attribute), meaning the elements from the '01' are no longer available. I suspect this is a work-in-progress issue, but I also understand a new version is imminent. Alan. (Boldon James) --e89a8ff1c97c08f30404c6e9971b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I've just been looking at using the schema from the '02' d= ocument of the EPS Trust document.=A0 However, I have noticed a problem whe= n compared to the '01' document.=A0
=A0
In the= '01' document the PlasmaResponse "ResponseType" is a seq= uence of "xacml:Response", "PlasmaTokens", "CMSTok= en", "CMSKey" and "Authentication".
=A0
In the '02' document the PlasmaResponse "Re= sponseType" is a sequence of "xacml:Response" and "Plas= maReturnToken" (PlasmaReturnToken only has a "DecisionId" at= tribute), meaning the elements from the '01' are no longer availabl= e.
=A0
I suspect this is a work-in-progress issue, but I also u= nderstand a new version is imminent.
=A0
Alan.
=A0
(Boldon James)

=A0

--e89a8ff1c97c08f30404c6e9971b-- From trevorf@exchange.microsoft.com Tue Aug 14 11:26:06 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 477A821F8630 for ; Tue, 14 Aug 2012 11:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.036 X-Spam-Level: X-Spam-Status: No, score=-102.036 tagged_above=-999 required=5 tests=[AWL=-1.896, BAYES_20=-0.74, J_CHICKENPOX_21=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKnRAimpZ52q for ; Tue, 14 Aug 2012 11:26:04 -0700 (PDT) Received: from na01b.map.o365filtering.com (by1c-gls.o365filtering.com [64.4.22.105]) by ietfa.amsl.com (Postfix) with ESMTP id A36AE21F8647 for ; Tue, 14 Aug 2012 11:26:04 -0700 (PDT) Received: from CH1SR01CA101.namsdf01.sdf.exchangelabs.com (10.255.157.18) by CH1SR01MB612.namsdf01.sdf.exchangelabs.com (10.255.157.40) with Microsoft SMTP Server (TLS) id 15.0.496.6; Tue, 14 Aug 2012 18:25:59 +0000 Received: from BY1FFOFD004.ffo.gbl (64.4.22.105) by CH1SR01CA101.outlook.com (10.255.157.18) with Microsoft SMTP Server (TLS) id 15.0.496.8 via Frontend Transport; Tue, 14 Aug 2012 18:25:59 +0000 Received: from hybrid.exchange.microsoft.com (131.107.1.27) by BY1FFOFD004.mail.o365filtering.com (10.1.16.61) with Microsoft SMTP Server (TLS) id 15.0.496.2 via Frontend Transport; Tue, 14 Aug 2012 18:25:59 +0000 Received: from DFM-TK5MBX15-01.exchange.corp.microsoft.com (157.54.110.8) by DF-G14-02.exchange.corp.microsoft.com (157.54.87.56) with Microsoft SMTP Server (TLS) id 14.3.71.0; Tue, 14 Aug 2012 11:25:37 -0700 Received: from PIO-MLT-05.exchange.corp.microsoft.com (157.54.94.22) by DFM-TK5MBX15-01.exchange.corp.microsoft.com (157.54.110.8) with Microsoft SMTP Server (TLS) id 15.0.485.6; Tue, 14 Aug 2012 11:25:34 -0700 Received: from DF-M14-10.exchange.corp.microsoft.com ([fe80::b076:a99f:3049:4c76]) by PIO-MLT-05.exchange.corp.microsoft.com ([fe80::d940:e316:1daa:5e6a%10]) with mapi id 14.03.0083.000; Tue, 14 Aug 2012 11:25:30 -0700 From: Trevor Freeman To: "Skedd, Richard (UK)" , "plasma@ietf.org" Thread-Topic: Basic and Advanced Policies Thread-Index: Ac1qfYzEE77XKwr7QLmya2XkWVhuzAPxQVAA Date: Tue, 14 Aug 2012 18:25:30 +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.102] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.1.27; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464001)(164054002)(377454001)(407274001)(42186003)(33656001)(16406001)(266001)(31966006); DIR:INB; LANG:en; X-Forefront-PRVS: 05739BA1B5 X-OriginatorOrg: DuplicateDomain-6c178e33-aecb-4786-8220-9afceeddbaf3.exchange.microsoft.com Subject: Re: [plasma] Basic and Advanced Policies 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: Tue, 14 Aug 2012 18:26:06 -0000 Hi Richard, The intent of basic policy is the former i.e. to replicate existing S/MIME = functionality where the sender designates the list of authorized recipients= . In the Plasma case basic policy has a parameter which is the list of reci= pients. The policy defines "anybody presenting an authenticated email attri= bute where the attribute value matches one of the named recipients and the = level of assurance of the identity matches that required under the policy w= ould pass the policy". We don't need a new policy ID per recipients list.=20 I agree we need a baseline of common functionality for the client. Technica= l all of the policy complexity is hidden from the client so a recipient is = unaware how many polices were applied to a message. Policy complexity would= only be manifest by the set of attributes the policy can request. In the a= dvanced case, the set of attributes is unbounded. What do we put into the e= conomy version of the Plasma client? The base client would likely have to e= xist as part of an email service as part of their baseline offering at very= little margin in order to be pervasive. Current proposal is to put enough= in to support the Personal to Addressee scenario. We should be able to bui= ld into the base profile, recognition that you need the full featured versi= on securely e.g. no "please clink on this link and install my latest malwar= e" kind of experience. The proliferation of app stores and marketplaces wil= l help here.=20 Trevor=20 -----Original Message----- From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of= Skedd, Richard (UK) Sent: Friday, July 27, 2012 2:35 AM To: plasma@ietf.org Subject: [plasma] Basic and Advanced Policies A follow-up on comments by Trevor Freeman, kindly forwarded by Patrick Patt= erson, and Jean-Paul Buu-Sao on the requirements for Basic v Advanced Polic= ies and the update of have draft-freeman-plasma-requirements-02 which now s= tates that: 4.6.1 Basic Policy Basic policy is intended to be universally usable by using a small fixed se= t of attributes. For example, basic policy is intended to be equivalent to = sending encrypted Email with S/MIME today. It is a simple policy that auth= enticated recipients of the Email get access to the message. Its intended = target is simple scenarios involving consumers and small businesses who are= using public PIP which issue a limited set of attributes. It is expected t= hat all Plasma clients and commercial IdP would be capable of supporting ba= sic policy due to their simplicity and basic attribute set. 4.6.2 Advanced Policy Advanced policy is intended to be used where one or more arbitrary policies= are required on the content . It is intended to target more complex scenar= ios such as content with regulated information or content subject to other = organization and contractual policies. The input set of attributes is defin= ed by the policies and can be either primordial or derived attributes or bo= th.=20 Multiple policies have a logical relationship e.g. they can be AND or ORed = together. It is not expected that all Plasma clients support advances polic= y. In my view the terminology proposed does not reflect the capabilities descr= ibed nor do the capabilities described align with typical use cases. If the intent of the "Basic Policy" is actually to replicate S/MIME functio= nality then it is an "Object Access Control List Policy". The mechanism of= S/MIME combined with the list of addressees effectively limits access to t= he addressees but without originator control over further use of the conten= t by the addressees. This is a valuable approach as it deals with the "Per= sonal to Addressee" and similar use cases by giving the originator bespoke = control over distribution. However, it does not involve a "Basic Policy" a= s a new policy with a unique ACL will need to be generated for every messag= e. If the intent of the "Basic Policy" is to address " simple scenarios involv= ing consumers and small businesses who are using public PIPs which issue a = limited set of attributes" then this must require the ability to create rul= es which include logical operators (AND, OR etc) to process the attributes.= eg "Customer for Product X AND Customer for Product Y", "Customer for Pro= duct X OR Retailer of Product X". This is effectively addressing the requi= rements of an object linked to a "Single Policy" rather than a "Basic Polic= y". Dealing with "Single Policies" rather than multiple policies would then be = consistent with the statement that "Advanced Policy is intended to be used = where one or more arbitrary policies are required on the content". Which r= aises a further question, is the ability to cope with content which referen= ces multiple policies an optional capability? The paper refers to a e-mail= thread in which the addition of information also adds additional policies.= Surely this scenario occurs everywhere all the time. Any request respons= e scenario could involve data that is sensitive to each party eg "Can you q= uote to supply X, My price for X is $$$" or "Can you come to a meeting abou= t X, No because I need to do Y". It thus seems to me that whilst there are different policy usage scenarios = (Bespoke, Single, Multiple) these must all be core PLASMA capabilities supp= orted by all PLASMA clients rather than add-ons for specialist applications= by some communities of interest. Regards Richard Skedd Strategy Manager - Office of the CIO T: +44 117 918 8034 (vnet 7658 8034) M: +44 780 171 8260 (vnet 777118260) BAE Systems plc Registered Office: 6 Carlton Gardens, London, SW1Y 5AD, UK Registered in En= gland & Wales No: 1470151 -----Original Message----- From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of= Patrick Patterson Sent: 25 July 2012 16:08 To: Jean-Paul Buu-Sao Cc: plasma@ietf.org Subject: Re: [plasma] Comments on Message Access Control Requirements Draft ----------------------! WARNING ! ---------------------- This message origi= nates from outside our organisation, either from an external partner or fro= m the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions o= n reporting suspicious email messages. -------------------------------------------------------- The following message has been forwarded from Trevor, as he is still having= difficulties posting to the list: ----- BEGIN FORWARDED MESSAGE ----- Hi Jean-Paul, Just catching up from Holiday. I have just posted a new draft of the requirements doc you may want to chec= k out. We have has a lot of feedback on our terminology so this new draft h= as attempted to improve that area. We have changed PEP to be a Decision Requestor to more clearly indicate it = does not enforce decisions. We did not adopt the Access Requestor name from= the XACML model as we have other types of decisions such as integrity poli= cy decision requests. PDP has changed to Policy Decision and Enforcement Point to emphasize in th= e Plasma model these functions are logically one. That does not preclude im= plementations from implementing them as separate entities but that implemen= tations detail would not impact Plasma. You should also read the technical drafts from the implantation details. http://datatracker.ietf.org/doc/draft-schaad-plasma-cms/ http://datatracker.ietf.org/doc/draft-schaad-plasma-service/ More inline below Trevor -----Original Message----- From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] O= n Behalf Of Jean-Paul Buu-Sao Sent: Monday, July 23, 2012 1:25 AM To: plasma@ietf.org Subject: [plasma] Comments on Message Access Control Requirements Draft Greetings, Please find my comments on the PLASMA draft 01: http://tools.ietf.org/pdf/draft-freeman-plasma-requirements-01.pdf: 1) Policy Data Binding Section 4.2.1: "The chief strength of binding by names is once bound to the data the assoc= iation with the policy travels with the data. The chief weakness in binding= by name is it requires the reference to be strongly bound to the data [...= ] This model is choosing to use binding by name because we need to encrypt = the data which means we will [be] impacting the storage format anyway which= negates the main weakness of binding my name." TSCP approves of the choice of "binding by name". Another chief strength th= at you did not quote, and which is key differentiator to TSCP, is to allow = policy change, with no impact on the data. This requirement cannot be met w= ith binding by value or by description. [TF] Good Point will add this to the draft The draft is silent on how the name would be expressed. Can it be any arbit= rary identifier, which precise syntax and semantics could be defined by a c= ommunity of interest defined profile? [TF] If you read the plasma service draft you will see we use a URI. We bel= ieve that has sufficient flexibility to address the requirements you descri= be. 2) Closed versus Open environment Section 4.4: "(A) The PEP verifies the certificate in the signed metadata then determine= s <> if it want to process the protected information base= d on the identity of the PDP (D) The PDP decrypts the metadata, de-references the policy pointers and de= termines the set of access rules based on the <>. The PDP then determines the set of subject attributes it needs to evaluate the access rules. The PDP can the use PIP is has relationships wit= h to query attributers about the subject. The list of attributes the PDP is= missing is then returned to the PEP" As stated the workflow implies a "closed environment". TSCP expected to see= a workflow that could as well support an "open environment", whereas not a= ll referenced policies are necessarily known by the local PDP/PAP ahead of = time. [TF] Since the PAP authors the policies and creates the policy reference, I= don't understand a client can have a policy reference that a PAP does not = know about so can you describe how this would occur. There are a logical sequence of PDEPs in Plasma. These can be physically th= e same PDEP or they can be separate PDEPs. * The PDEP which generates the role token * The PDEP which generates the message token * The PDEP which generates the read token Only the first PDEP needs prior knowledge of the policies which is necessar= y for it to generate the policy collection in the role token. All subsequen= t PDEPs can use the URI to discover the policies. As a related topic, Policy Publication Point (PPP), lightly introduced in t= he Vocabulary section, is a good addition to [RFC3198] and [XACML-core]. In= view of the support for "open environments", TSCP expected to see more req= uirements on PPP. 3) Advanced Policies Section 4.5.2: "Advanced policy is intended to be used where one or more a= rbitrary policies are required on the content. It is intended to target mor= e complex scenarios such as content with regulated information or content s= ubject to other organization and contractual policies. The input set of att= ributes is defined by the policies and can be either primordial or derived = attributes or both. Multiple policies have a logical relationship e.g. they= can be <>. <>." [TF] The text was not intended to indicate only simple logical relationship= s would be expressed so I will change to say "AND and/or ORed together in a= n arbitrary combination". The technical draft uses a logic trees so already= supports what you describe. TSCP mandates a support for "advances policies". [TF] I understand some communities of interest would require use of Advance= s Polices. However I don't want to burden every Plasma client implementatio= n to support such policies. The basic policy set is aimed a simple set of s= cenarios where the Plasma client may well be bundled in at no charge so any= additional complexity would be a tax. A premium client which supports adva= nced polices can then be purchased where there is business value in doing s= o e.g. a mandate from a community of interest such as TSCP. A typical example is to support documents that must be simultaneously prote= cted under an Export Control policy (e.g. ITAR Technical Assistance Agreement) and an Intellectual Property policy (e.g. Proprietary Informatio= n Exchange Agreement). In this case of multiple policies, TSCP requires tha= t all the applicable policies are to be evaluated, with each one of the spe= cified policy allowing the required access. So this cannot just be a simple OR, as the Plasma draft states. 4) Policy Expression Language The draft is silent on the positioning of PLASMA with Policy Expression Lan= guages. Is there one in particular that PLASMA mandates (if so, which one),= or is the specification agnostic (if so, what are the baseline requirement= s in terms of expressiveness)? [TF] For the requirements I intend to be language neutral. We do intend to = address PDAP-PAP interaction in a subsequent technical paper where the topi= c will have to be addressed. Some communities of interest have made signifi= cant investments in XACML but it has not been universally adopted so plasm= a has a tradeoff between mandating a specific language to improve interoper= ability and alienating communities to do not use XACML. I don't know the ri= ght answer at this time but that answer does not impact the current work. = We do need to support language negotiation between PDEP and PAP so at a min= imum so we can support communities of interest and also be forwards compati= ble. Some organizations have developed and validated a broad set of policies, ex= pressed in a Policy Expression Language of their choosing (e.g. XACML 2.0),= and need to be able to reuse them. Thanks, Jean-Paul Buu-Sao, TSCP ---- END FORWARDED MESSAGE ----- --- Patrick Patterson President and Chief PKI Architect Carillon Information Security Inc. http://www.carillon.ca tel: +1 514 485 0789 mobile: +1 514 994 8699 fax: +1 450 424 9559 _______________________________________________ plasma mailing list plasma@ietf.org https://www.ietf.org/mailman/listinfo/plasma From Richard.Skedd@baesystems.com Wed Aug 15 10:02:29 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 4647D21F8670 for ; Wed, 15 Aug 2012 10:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffv-c4s5OjHp for ; Wed, 15 Aug 2012 10:02:27 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 4866721F859C for ; Wed, 15 Aug 2012 10:02:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,774,1336345200"; d="p7s'?scan'208";a="263873604" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 15 Aug 2012 18:02:22 +0100 Received: from GLKXH0003V.GREENLNK.net ([10.109.2.34]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q7FH2MYl009525 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Aug 2012 18:02:22 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.170]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.02.0309.002; Wed, 15 Aug 2012 18:02:21 +0100 From: "Skedd, Richard (UK)" To: Trevor Freeman , "plasma@ietf.org" Thread-Topic: Basic and Advanced Policies Thread-Index: Ac1qfYzEE77XKwr7QLmya2XkWVhuzAPxQVAAAC5txXA= Date: Wed, 15 Aug 2012 17:02:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00D1_01CD7B10.1D6DA2F0" MIME-Version: 1.0 Subject: Re: [plasma] Basic and Advanced Policies 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: Wed, 15 Aug 2012 17:02:29 -0000 ------=_NextPart_000_00D1_01CD7B10.1D6DA2F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks Trevor, please see some further thoughts in response to your two comments below: Addressee Only Policy OK, understood, the PDP could use the information in the message to = process this policy, which will work where the PDP is capable of using a parameterized policy (eg asserted e-mail address matches one of the = message recipients e-mail addresses) rather than an explicit policy (eg asserted e-mail address is one of list of values). My understanding is that parameters are not well supported by today's policy expression languages = or my policy enforcement applications. If this is correct then it would be useful to flag these requirements. IMHO it would be good to use "Addressee Only Policy" or similar as the = name for this capability rather than the less precise "Basic Policy". Replying to and forwarding messages could introduce new addressees and = new sensitivities. There must be some definition of an addressee's scope = for action, possibly with options that are selectable by the sender. Can an addressee reply, reply to all, reply and include new addressees, forward = ? If, for example, the addressee replies to some of the original = addressees with a message that is also covered by the "Addressee Only" policy then = does the PDP use the recipient e-mail addresses for the reply or the original message to control access ? It would be useful to have the "Addressee = Only" policy documented for use cases other than just reading of the initial message. Baseline Client Functionality >From what you say I understand that you are proposing that all clients = will be capable of enforcing the "Addressee Only Policy". This means that = they have the functionality to: 1. Retrieve multiple attributes about the requester (e-mail address, identity assurance level) from at least one attribute authority 2. Retrieve multiple attributes from the message/resource (applicable policies, allowed e-mail addresses, required minimum identity assurance level) 3. Identify the rule sets to use implement the applicable policies (Addressee Only with potentially specified limitations on recipient = actions) 4. Retrieve the appropriate rule sets, I assume not "hardwired" in the client, although it may be cached for performance 5. Process the rule sets which will be expressed using attributes, parameters, comparison operators and logical operators (requester e-mail address is a member of allowed e-mail addresses AND identity assurance = level >=3D required minimum identity assurance level) 6. Permit/deny the requested action (Any, or reply to all recipients, forward to new address) At this level a baseline client which is capable of enforcing the = "Addressee Only Policy" will also meet all the functional requirements for an "Arbitrary Single Policy". Whether the user is a subscriber to the necessary attribute authorities and policy authorities to be able to exercise this functionality is another matter. Again we need to = understand the intent of PLASMA for "Arbitrary Single Policy" use cases beyond read = the initial message. Is a baseline client expected to be able to generate a reply which may also be subject to the "Addressee Only Policy" or an additional "Arbitrary Single Policy" ? Regards Richard Skedd Strategy Manager - Office of the CIO T:=A0=A0=A0 +44 117 918 8034 (vnet 7658 8034) M:=A0=A0=A0 +44 780 171 8260 (vnet 777118260) =A0 BAE Systems plc Registered Office: 6 Carlton Gardens, London, SW1Y 5AD, UK Registered in England & Wales No: 1470151 -----Original Message----- From: Trevor Freeman [mailto:trevorf@exchange.microsoft.com]=20 Sent: 14 August 2012 19:26 To: Skedd, Richard (UK); plasma@ietf.org Subject: RE: Basic and Advanced Policies ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external = partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for = instructions on reporting suspicious email messages. -------------------------------------------------------- Hi Richard, The intent of basic policy is the former i.e. to replicate existing = S/MIME functionality where the sender designates the list of authorized = recipients. In the Plasma case basic policy has a parameter which is the list of recipients. The policy defines "anybody presenting an authenticated = email attribute where the attribute value matches one of the named recipients = and the level of assurance of the identity matches that required under the policy would pass the policy". We don't need a new policy ID per = recipients list.=20 I agree we need a baseline of common functionality for the client. = Technical all of the policy complexity is hidden from the client so a recipient is unaware how many polices were applied to a message. Policy complexity = would only be manifest by the set of attributes the policy can request. In the advanced case, the set of attributes is unbounded. What do we put into = the economy version of the Plasma client? The base client would likely have = to exist as part of an email service as part of their baseline offering at = very little margin in order to be pervasive. Current proposal is to put = enough in to support the Personal to Addressee scenario. We should be able to = build into the base profile, recognition that you need the full featured = version securely e.g. no "please clink on this link and install my latest = malware" kind of experience. The proliferation of app stores and marketplaces = will help here.=20 Trevor=20 -----Original Message----- From:=20 [RWS]=20 plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of = Skedd, Richard (UK) Sent: Friday, July 27, 2012 2:35 AM To: plasma@ietf.org Subject: [plasma] Basic and Advanced Policies A follow-up on comments by Trevor Freeman, kindly forwarded by Patrick Patterson, and Jean-Paul Buu-Sao on the requirements for Basic v = Advanced Policies and the update of have draft-freeman-plasma-requirements-02 = which now states that: 4.6.1 Basic Policy Basic policy is intended to be universally usable by using a small fixed = set of attributes. For example, basic policy is intended to be equivalent to sending encrypted Email with S/MIME today. It is a simple policy that authenticated recipients of the Email get access to the message. Its intended target is simple scenarios involving consumers and small = businesses who are using public PIP which issue a limited set of attributes. It is expected that all Plasma clients and commercial IdP would be capable of supporting basic policy due to their simplicity and basic attribute set. 4.6.2 Advanced Policy Advanced policy is intended to be used where one or more arbitrary = policies are required on the content . It is intended to target more complex scenarios such as content with regulated information or content subject = to other organization and contractual policies. The input set of attributes = is defined by the policies and can be either primordial or derived = attributes or both.=20 Multiple policies have a logical relationship e.g. they can be AND or = ORed together. It is not expected that all Plasma clients support advances policy. In my view the terminology proposed does not reflect the capabilities described nor do the capabilities described align with typical use = cases. If the intent of the "Basic Policy" is actually to replicate S/MIME functionality then it is an "Object Access Control List Policy". The mechanism of S/MIME combined with the list of addressees effectively = limits access to the addressees but without originator control over further use = of the content by the addressees. This is a valuable approach as it deals = with the "Personal to Addressee" and similar use cases by giving the = originator bespoke control over distribution. However, it does not involve a = "Basic Policy" as a new policy with a unique ACL will need to be generated for every message. If the intent of the "Basic Policy" is to address " simple scenarios involving consumers and small businesses who are using public PIPs which issue a limited set of attributes" then this must require the ability to create rules which include logical operators (AND, OR etc) to process = the attributes. eg "Customer for Product X AND Customer for Product Y", "Customer for Product X OR Retailer of Product X". This is effectively addressing the requirements of an object linked to a "Single Policy" = rather than a "Basic Policy". Dealing with "Single Policies" rather than multiple policies would then = be consistent with the statement that "Advanced Policy is intended to be = used where one or more arbitrary policies are required on the content". = Which raises a further question, is the ability to cope with content which references multiple policies an optional capability? The paper refers = to a e-mail thread in which the addition of information also adds additional policies. Surely this scenario occurs everywhere all the time. Any = request response scenario could involve data that is sensitive to each party eg = "Can you quote to supply X, My price for X is $$$" or "Can you come to a = meeting about X, No because I need to do Y". It thus seems to me that whilst there are different policy usage = scenarios (Bespoke, Single, Multiple) these must all be core PLASMA capabilities supported by all PLASMA clients rather than add-ons for specialist applications by some communities of interest. Regards Richard Skedd Strategy Manager - Office of the CIO T: +44 117 918 8034 (vnet 7658 8034) M: +44 780 171 8260 (vnet 777118260) BAE Systems plc Registered Office: 6 Carlton Gardens, London, SW1Y 5AD, UK Registered in England & Wales No: 1470151 -----Original Message----- From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf = Of Patrick Patterson Sent: 25 July 2012 16:08 To: Jean-Paul Buu-Sao Cc: plasma@ietf.org Subject: Re: [plasma] Comments on Message Access Control Requirements = Draft ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external = partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for = instructions on reporting suspicious email messages. -------------------------------------------------------- The following message has been forwarded from Trevor, as he is still = having difficulties posting to the list: ----- BEGIN FORWARDED MESSAGE ----- Hi Jean-Paul, Just catching up from Holiday. I have just posted a new draft of the requirements doc you may want to = check out. We have has a lot of feedback on our terminology so this new draft = has attempted to improve that area. We have changed PEP to be a Decision Requestor to more clearly indicate = it does not enforce decisions. We did not adopt the Access Requestor name = from the XACML model as we have other types of decisions such as integrity = policy decision requests. PDP has changed to Policy Decision and Enforcement Point to emphasize in = the Plasma model these functions are logically one. That does not preclude implementations from implementing them as separate entities but that implementations detail would not impact Plasma. You should also read the technical drafts from the implantation details. http://datatracker.ietf.org/doc/draft-schaad-plasma-cms/ http://datatracker.ietf.org/doc/draft-schaad-plasma-service/ More inline below Trevor -----Original Message----- From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org]= On Behalf Of Jean-Paul Buu-Sao Sent: Monday, July 23, 2012 1:25 AM To: plasma@ietf.org Subject: [plasma] Comments on Message Access Control Requirements Draft Greetings, Please find my comments on the PLASMA draft 01: http://tools.ietf.org/pdf/draft-freeman-plasma-requirements-01.pdf: 1) Policy Data Binding Section 4.2.1: "The chief strength of binding by names is once bound to the data the association with the policy travels with the data. The chief weakness in binding by name is it requires the reference to be strongly bound to the data [...] This model is choosing to use binding by name because we need = to encrypt the data which means we will [be] impacting the storage format anyway which negates the main weakness of binding my name." TSCP approves of the choice of "binding by name". Another chief strength that you did not quote, and which is key differentiator to TSCP, is to = allow policy change, with no impact on the data. This requirement cannot be = met with binding by value or by description. [TF] Good Point will add this to the draft The draft is silent on how the name would be expressed. Can it be any arbitrary identifier, which precise syntax and semantics could be = defined by a community of interest defined profile? [TF] If you read the plasma service draft you will see we use a URI. We believe that has sufficient flexibility to address the requirements you describe. 2) Closed versus Open environment Section 4.4: "(A) The PEP verifies the certificate in the signed metadata then = determines <> if it want to process the protected information = based on the identity of the PDP (D) The PDP decrypts the metadata, de-references the policy pointers and determines the set of access rules based on the <>. The PDP then determines the set of subject attributes it needs to evaluate the access rules. The PDP can the use PIP is has relationships = with to query attributers about the subject. The list of attributes the PDP = is missing is then returned to the PEP" As stated the workflow implies a "closed environment". TSCP expected to = see a workflow that could as well support an "open environment", whereas not = all referenced policies are necessarily known by the local PDP/PAP ahead of time. [TF] Since the PAP authors the policies and creates the policy = reference, I don't understand a client can have a policy reference that a PAP does = not know about so can you describe how this would occur. There are a logical sequence of PDEPs in Plasma. These can be physically = the same PDEP or they can be separate PDEPs. * The PDEP which generates the role token * The PDEP which generates the message token * The PDEP which generates the read token Only the first PDEP needs prior knowledge of the policies which is = necessary for it to generate the policy collection in the role token. All = subsequent PDEPs can use the URI to discover the policies. As a related topic, Policy Publication Point (PPP), lightly introduced = in the Vocabulary section, is a good addition to [RFC3198] and = [XACML-core]. In view of the support for "open environments", TSCP expected to see more requirements on PPP. 3) Advanced Policies Section 4.5.2: "Advanced policy is intended to be used where one or = more arbitrary policies are required on the content. It is intended to target more complex scenarios such as content with regulated information or = content subject to other organization and contractual policies. The input set of attributes is defined by the policies and can be either primordial or derived attributes or both. Multiple policies have a logical = relationship e.g. they can be <>. <>." [TF] The text was not intended to indicate only simple logical = relationships would be expressed so I will change to say "AND and/or ORed together in = an arbitrary combination". The technical draft uses a logic trees so = already supports what you describe. TSCP mandates a support for "advances policies". [TF] I understand some communities of interest would require use of = Advances Polices. However I don't want to burden every Plasma client = implementation to support such policies. The basic policy set is aimed a simple set of scenarios where the Plasma client may well be bundled in at no charge so = any additional complexity would be a tax. A premium client which supports advanced polices can then be purchased where there is business value in doing so e.g. a mandate from a community of interest such as TSCP. A typical example is to support documents that must be simultaneously protected under an Export Control policy (e.g. ITAR Technical Assistance Agreement) and an Intellectual Property policy (e.g. Proprietary = Information Exchange Agreement). In this case of multiple policies, TSCP requires = that all the applicable policies are to be evaluated, with each one of the specified policy allowing the required access. So this cannot just be a simple OR, as the Plasma draft states. 4) Policy Expression Language The draft is silent on the positioning of PLASMA with Policy Expression Languages. Is there one in particular that PLASMA mandates (if so, which one), or is the specification agnostic (if so, what are the baseline requirements in terms of expressiveness)? [TF] For the requirements I intend to be language neutral. We do intend = to address PDAP-PAP interaction in a subsequent technical paper where the = topic will have to be addressed. Some communities of interest have made significant investments in XACML but it has not been universally = adopted so plasma has a tradeoff between mandating a specific language to improve interoperability and alienating communities to do not use XACML. I don't know the right answer at this time but that answer does not impact the current work. We do need to support language negotiation between PDEP = and PAP so at a minimum so we can support communities of interest and also = be forwards compatible. Some organizations have developed and validated a broad set of policies, expressed in a Policy Expression Language of their choosing (e.g. XACML 2.0), and need to be able to reuse them. Thanks, Jean-Paul Buu-Sao, TSCP ---- END FORWARDED MESSAGE ----- --- Patrick Patterson President and Chief PKI Architect Carillon Information Security Inc. http://www.carillon.ca tel: +1 514 485 0789 mobile: +1 514 994 8699 fax: +1 450 424 9559 _______________________________________________ plasma mailing list plasma@ietf.org https://www.ietf.org/mailman/listinfo/plasma ------=_NextPart_000_00D1_01CD7B10.1D6DA2F0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIugDCCA6Ew ggKJoAMCAQICECk2R6rjiqyGSiNW8sq3Ya8wDQYJKoZIhvcNAQEFBQAwTjELMAkGA1UEBhMCdXMx GDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDENMAsGA1UECxMERkJDQTEWMBQGA1UEAxMNQ29tbW9u IFBvbGljeTAeFw0wNzEwMTUxNTU4MDBaFw0yNzEwMTUxNjA4MDBaME4xCzAJBgNVBAYTAnVzMRgw FgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDTALBgNVBAsTBEZCQ0ExFjAUBgNVBAMTDUNvbW1vbiBQ b2xpY3kwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCXjb0zJ+StW/t4vS9HR27HeOmT nKTeyRz9Lxs5OKxHF8B+dykAOwMfaA/NTaXud7gsYmsx9vpyCX0wKQZ853yjPYQYih2uLJKoH+he T42O6z8a+JwKZ52wZ03wLtAw3sOUsKDPLgo0f1QJ0za9pElXUnPpnf7kSHlGG1uNMuSlSGTzIg2S nQgVv2A8g/dHIiUirSlxt3fvF8mitpReyDCQpBRIXFZXC0FMBdQqTD+uEptZEXVwByJpLSzTMcyS fszNpH6UR6qcCQj2S69S6GpAkcVVvUCxyG1XhpUX5h9zvkcuPotMF7m5JRylUhc2CFnAQr4KK7RW UTwbVcmMkHfrAgMBAAGjezB5MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud DgQWBBQvWJfYqQWYpVYf+9mrde8CPDY0xzASBgkrBgEEAYI3FQEEBQIDAQABMCMGCSsGAQQBgjcV AgQWBBR2t2CW3RRWKax1hdNwY8G8R4YcizANBgkqhkiG9w0BAQUFAAOCAQEAYK7zSBZAcqYIiMm8 RywkS12gkXPtZXiQ8GeQeqW/Cq22KvmZZ9+DxXcfNAk4+X6eQeBIYP7iql2HiOqI/VxFsslq2n2k rbFPvxwNnx6awNUUczgrinhAbjD3YuHNmfxRaWdsEd24EKNo3ialVv02bDeYbPvufDxsa3A/90g3 CY8LQoGtRka4C4MG9Bs4oH9PzQvvg4mHlxyKMGfc/VShA34By4VMsQspw77sfOE/DwlSPC+nmkj+ N+kRBljhNkGKxLa/jt3OSrO8GsDN+hqZ0nGb+s+88sRUo4g1dswbLEZvDLTRw2F2knQR6kuAjRyJ EYvsW/8XyUj85+AGEeKEXjCCBo4wggV2oAMCAQICEEdoCdF50xtCM6sJ63YUtmgwDQYJKoZIhvcN AQEFBQAwZzELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUNlcnRpUGF0aCBMTEMxIjAgBgNVBAsTGUNl cnRpZmljYXRpb24gQXV0aG9yaXRpZXMxHDAaBgNVBAMTE0NlcnRpUGF0aCBCcmlkZ2UgQ0EwHhcN MTIwNTIyMDAwMDAwWhcNMTMwNTI2MjM1OTU5WjB+MQswCQYDVQQGEwJVUzEUMBIGA1UEChMLRXhv c3RhciBMTEMxIjAgBgNVBAsTGUNlcnRpZmljYXRpb24gQXV0aG9yaXRpZXMxNTAzBgNVBAMTLEV4 b3N0YXIgRmVkZXJhdGVkIElkZW50aXR5IFNlcnZpY2UgUm9vdCBDQSAxMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAvpqr+7HoMvGr/7nVeA7AbnZkezNe8SiIzIhmDxgyJZ1aOGz1C+Bu /FYpwKmFr66OKSPquiZyJlHbD0O4gZZgtwuERnSbGei1L5BmKCxuRv1IdhCI7MgfCbsi3W3pvFa6 EOrnUEf4WhR3Mrvgfr9ZgdmY0OP/gE9L+Xnw/RNZ3ZZ6qS0WEs8XijUi6SVWzJJsLDAX51hZ3d+m +RWE09nb0ygGxc4KzRcrmKKqn7Fs6iWoHDe4HOamLhFMamM7dljN3wSaSom/T1Sz+Q+W8AZuI3mo xQUeTNoOYDH9HB/c7bfiumpgPooInQDNyrypO/jopsQWRrKfH1Tn9VHrjbCGIQIDAQABo4IDHTCC AxkwHQYDVR0OBBYEFC6+kaZ3ajc89f0dtt14yabl9CIgMBIGA1UdEwEB/wQIMAYBAf8CAQEwKQYD VR0gBCIwIDAOBgwrBgEEAYG7UwEBAREwDgYMKwYBBAGBu1MBAQESMIH0BgNVHR8Egewwgekwgeag geOggeCGQ2h0dHA6Ly9jZXJ0aXBhdGgtY3JsLnZlcmlzaWduLmNvbS9DZXJ0aVBhdGhMTENDZXJ0 aVBhdGhCcmlkZ2VDQS5jcmyGgZhsZGFwOi8vY2VydGlwYXRoLWNybC1sZGFwLnZlcmlzaWduLmNv bS9DTj1DZXJ0aVBhdGglMjBCcmlkZ2UlMjBDQSxPVT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRp ZXMsTz1DZXJ0aVBhdGglMjBMTEMsQz1VUz9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0O2JpbmFy eTAOBgNVHQ8BAf8EBAMCAcYwCgYDVR02BAMCAQAwDAYDVR0kBAUwA4EBADCCARMGCCsGAQUFBwEB BIIBBTCCAQEwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZXJ0aXBhdGgtYWlhLnZlcmlzaWduLmNvbS9D ZXJ0aVBhdGhCcmlkZ2VSb290Q0EucDdjMIG1BggrBgEFBQcwAoaBqGxkYXA6Ly9jZXJ0aXBhdGgt YWlhLWxkYXAudmVyaXNpZ24uY29tL0NOPUNlcnRpUGF0aCUyMEJyaWRnZSUyMENBLE9VPUNlcnRp ZmljYXRpb24lMjBBdXRob3JpdGllcyxPPUNlcnRpUGF0aCUyMExMQyxDPVVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5LGNyb3NzQ2VydGlmaWNhdGVQYWlyO2JpbmFyeTBgBgNVHSEEWTBXMBsGDCsGAQQB gbtTAQEBEQYLKwYBBAHsfAEBAQEwGwYMKwYBBAGBu1MBAQESBgsrBgEEAex8AQEBAjAbBgwrBgEE AYG7UwEBAREGCysGAQQB7HwBAQECMB8GA1UdIwQYMBaAFDUfQeq/kXbBZ6AGGRuA9AbROZPcMA0G CSqGSIb3DQEBBQUAA4IBAQAolComnnxtfpCXVGP1t/pUKZhE51lf7pH01NXxmkorRw0G+BighopM ymnTszXLbe1F/1xQAIjA+LE/j8NvtKABkXPGj0xye6e+kZDYNiUXSctOgXH5/jEgzMvtospBlYP1 jrfYy4t4PJI9hYNazn8Qe3bh59bpFNzLH5Qo+pzAQE6D+dH+/sOb7QH6ERuJ984W8HaYK77z1Y1J WAZ8tCGiFanUKF9gHZzEtpZVKWnHKE1yVE1APXPnYvPCkgs1AkgznWv82zCFhlrxU8cu2uRRUBvE OeOelIJ27WF1WQxcScDAnwgOEo+mNyyMLA4EAGPTMlNR6NZvS0Jvi6xWSIhuMIIGmDCCBYCgAwIB AgIKYVo34gAAAAAAAjANBgkqhkiG9w0BAQUFADB+MQswCQYDVQQGEwJVUzEUMBIGA1UEChMLRXhv c3RhciBMTEMxIjAgBgNVBAsTGUNlcnRpZmljYXRpb24gQXV0aG9yaXRpZXMxNTAzBgNVBAMTLEV4 b3N0YXIgRmVkZXJhdGVkIElkZW50aXR5IFNlcnZpY2UgUm9vdCBDQSAxMB4XDTEwMDUxMDIxMDc1 M1oXDTE2MDUxMDIxMDc1M1owajETMBEGCgmSJomT8ixkARkWA2NvbTEZMBcGCgmSJomT8ixkARkW CWV2aW5jaWJsZTE4MDYGA1UEAxMvRXhvc3RhciBGZWRlcmF0ZWQgSWRlbnRpdHkgU2VydmljZSBT aWduaW5nIENBIDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC/1hJ0xVzCnh+QSeHe 9l7AFTQ+tmbcjd2nLoKO7aCBmlPfbwsfEsr6pvUKAJBN1mNfZha+ei2IXz21xmcqd6WboUDNmcBZ 3SlubAn6tl5RGA7avBgV5FiZH0wo8UQOvM6jfLWJAsD1+CGKJWHCwf1Fdse8RQts2VQHveGS1RqR qa6JJJXS7mc6LcZPToTv/oQN3pQ0dlS22E8Eax00ugUiCRV37bsZwMRXdxQmRUyKAtRjbZAJzYxC Mk7gUoKyRFuEQMvBKjW/+Zd0O67/QmfLyjSKGvsPhkd1z+x04TRkSiU8xsKsTHU6lmc2gQNbLD0/ DXA94GUQxXSzbuKiwsJ3AgMBAAGjggMqMIIDJjAdBgNVHQ4EFgQUSivAqriQrio/AlNBuaNsePS1 qaUwDgYDVR0PAQH/BAQDAgHGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0jBBgwFoAULr6Rpndq Nzz1/R223XjJpuX0IiAwggEwBgNVHR8EggEnMIIBIzCCAR+gggEboIIBF4ZkaHR0cDovL3d3dy5m aXMuZXZpbmNpYmxlLmNvbS9maXMvcHVibGljL0V4b3N0YXIlMjBGZWRlcmF0ZWQlMjBJZGVudGl0 eSUyMFNlcnZpY2UlMjBSb290JTIwQ0ElMjAxLmNybIaBrmxkYXA6Ly9sZGFwLmZpcy5ldmluY2li bGUuY29tL0NOPUV4b3N0YXIlMjBGZWRlcmF0ZWQlMjBJZGVudGl0eSUyMFNlcnZpY2UlMjBSb290 JTIwQ0ElMjAxLE9VPUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxPPUV4b3N0YXIlMjBMTEMs Qz11cz9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0O2JpbmFyeTCCAVIGCCsGAQUFBwEBBIIBRDCC AUAwcAYIKwYBBQUHMAKGZGh0dHA6Ly93d3cuZmlzLmV2aW5jaWJsZS5jb20vZmlzL3B1YmxpYy9F eG9zdGFyJTIwRmVkZXJhdGVkJTIwSWRlbnRpdHklMjBTZXJ2aWNlJTIwUm9vdCUyMENBJTIwMS5w N2MwgcsGCCsGAQUFBzAChoG+bGRhcDovL2xkYXAuZmlzLmV2aW5jaWJsZS5jb20vQ049RXhvc3Rh ciUyMEZlZGVyYXRlZCUyMElkZW50aXR5JTIwU2VydmljZSUyMFJvb3QlMjBDQSUyMDEsT1U9Q2Vy dGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLE89RXhvc3RhciUyMExMQyxDPVVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5LGNyb3NzQ2VydGlmaWNhdGVQYWlyO2JpbmFyeTA2BgNVHSAELzAtMA0GCysGAQQB 7HwBAQEHMA0GCysGAQQB7HwBAQEBMA0GCysGAQQB7HwBAQECMA0GCSqGSIb3DQEBBQUAA4IBAQC8 3plzCwHwddOvLmgkDw7hle/oGni2ktAv0DMFkuCc1EWtb5KfRDencQ1VP6eO2UhkK31vhYSnwqXR vlCk/ApjxJWzsz2vpT2YM+wYj/suFgHKm0kEfK2a6dtITDMLkIjNwZhl85h4K3gsoWzvwKXEeLFW OcuXv5oAdtl/Vk3yfT7sAJiPH1+7k0RLHJIsTuB5OyAnlElEdmzBYwFKrDgApy8B5i0gXmmC8kxm c7hyeI+ZbrLTDQ5hMejwLpOhr/JeEXABMbcDclVVCBkuNg1MwtCGhOoXG7+hlELTDOeOtnn6gbxb tYMaYHR7rp8t7k623ALN7IXHi4TjGBNdieFCMIIHIDCCBgigAwIBAgICAmIwDQYJKoZIhvcNAQEF BQAwVjELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDENMAsGA1UECxMERlBL STEeMBwGA1UEAxMVU0hBLTEgRmVkZXJhbCBSb290IENBMB4XDTExMDMwNDE2MzU0OFoXDTE0MDEw MTA0NTk1OVowZzELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUNlcnRpUGF0aCBMTEMxIjAgBgNVBAsT GUNlcnRpZmljYXRpb24gQXV0aG9yaXRpZXMxHDAaBgNVBAMTE0NlcnRpUGF0aCBCcmlkZ2UgQ0Ew ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDPiZi47tHyfnuERAKvXS2FWJ/cpayh91jf 7uxZbgA/VxgRx4zRmMM2oPokGdUDHDQEqtnI8qDWPKOeJ3wIx890sRVT7wPNfsZFeJT+QTaD0X0e PqOlw2RrjmfSmWpPvwMSUc+rBybGgIJ5FoO8o5JoxHxuaNTZQ8yYs4RpinqyNow8bIzuYDOR0xGx 4LLnDC7a24KCCPHH3iySyUCzR3a7DBJlN01Q6bW/aQCUE4NZmiqckeh1rZk3ioTQJlrMl2N6atNd SYsajKVGy0WISwkMVpdisCFcvfmg3It8I1IKmy9lrqHzOV10EBKk/naJdaI48LCONG8tNB4oLJQ4 vAmdAgMBAAGjggPlMIID4TAPBgNVHRMBAf8EBTADAQH/MIHsBggrBgEFBQcBAQSB3zCB3DBFBggr BgEFBQcwAoY5aHR0cDovL2h0dHAuZnBraS5nb3Yvc2hhMWZyY2EvY2FDZXJ0c0lzc3VlZFRvc2hh MWZyY2EucDdjMIGSBggrBgEFBQcwAoaBhWxkYXA6Ly9sZGFwLmZwa2kuZ292L2NuPVNIQS0xJTIw RmVkZXJhbCUyMFJvb3QlMjBDQSxvdT1GUEtJLG89VS5TLiUyMEdvdmVybm1lbnQsYz1VUz9jQUNl cnRpZmljYXRlO2JpbmFyeSxjcm9zc0NlcnRpZmljYXRlUGFpcjtiaW5hcnkwgbMGA1UdIQSBqzCB qDAaBgpghkgBZQMCAQMXBgwrBgEEAYG7UwEBAREwGgYKYIZIAWUDAgEDGAYMKwYBBAGBu1MBAQES MBoGCmCGSAFlAwIBAxkGDCsGAQQBgbtTAQEBETAaBgpghkgBZQMCAQMVBgwrBgEEAYG7UwEBARQw GgYKYIZIAWUDAgEDFgYMKwYBBAGBu1MBAQEVMBoGCmCGSAFlAwIBAxgGDCsGAQQBgbtTAQEBEzBx BgNVHR4BAf8EZzBloWMwK6QpMCcxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1l bnQwGaQXMBUxEzARBgoJkiaJk/IsZAEZFgNtaWwwGaQXMBUxEzARBgoJkiaJk/IsZAEZFgNnb3Yw TwYDVR0gBEgwRjAMBgpghkgBZQMCAQMXMAwGCmCGSAFlAwIBAxgwDAYKYIZIAWUDAgEDGTAMBgpg hkgBZQMCAQMVMAwGCmCGSAFlAwIBAxYwVwYIKwYBBQUHAQsESzBJMEcGCCsGAQUFBzAFhjtodHRw Oi8vY2VydGlwYXRoLWFpYS52ZXJpc2lnbi5jb20vQ2VydGlQYXRoQnJpZGdlUm9vdENBLnA3YzAO BgNVHQ8BAf8EBAMCAQYwHwYDVR0jBBgwFoAUhppcYv9zk9Xhin9Kxogun26grhIwgbsGA1UdHwSB szCBsDAwoC6gLIYqaHR0cDovL2h0dHAuZnBraS5nb3Yvc2hhMWZyY2Evc2hhMWZyY2EuY3JsMHyg eqB4hnZsZGFwOi8vbGRhcC5mcGtpLmdvdi9jbiUzZFNIQS0xJTIwRmVkZXJhbCUyMFJvb3QlMjBD QSxvdSUzZEZQS0ksbyUzZFUuUy4lMjBHb3Zlcm5tZW50LGMlM2RVUz9jZXJ0aWZpY2F0ZVJldm9j YXRpb25MaXN0MB0GA1UdDgQWBBQ1H0Hqv5F2wWegBhkbgPQG0TmT3DANBgkqhkiG9w0BAQUFAAOC AQEACNSeOTGdQVxZzLpRTu8WyrDrH4R81Nms3z6ir3dkItpARoWmJqIomES5eNF26zVXJpGcr58I lGrfOmHDNUwsW0lof0pG32i3nLrL8HcUttsn1jv/nVHCbUr0B/w3AgfPNrQFs4M6anFS88cWtCR3 wTq6GrS/Zum1ANU/OEDiCIn1/XstAiR6OfpqK28pquIQFInfRzbGg1RVqPsTZW+1GUg54L08ebD9 wVkCApRMoVh0EsmdkYgL3BwkCMzZo7XtTjZd2Fsgaf/GGUtYY4LuR7TPF2YT8GvXatPYka8zeycL mzvIbl9oVv78mUZT+VpS8NnPgfoyvhXczXe3GxAMvzCCB14wggZGoAMCAQICCjSzdbEAAQAAAHow DQYJKoZIhvcNAQEFBQAwTjELMAkGA1UEBhMCdXMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEN MAsGA1UECxMERkJDQTEWMBQGA1UEAxMNQ29tbW9uIFBvbGljeTAeFw0xMTAyMDcyMTUxMzBaFw0x MzEyMzEyMjAxMzBaMFYxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDTAL BgNVBAsTBEZQS0kxHjAcBgNVBAMTFVNIQS0xIEZlZGVyYWwgUm9vdCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAKcHngU6XH6x/7CZErplcj7DMj6PigVMMvgxFbqAOfNmYHiut+iO /mr1YFNkMy7mM0DJISPfarEzTnFO8fxy5K6RmSrBKZqNdP+xMjkCcgmbZcgHEa+yOLXGjv2wGMHq EZ0pZI8oMDjpSBR2HEeT7JZAwcpZhVEMVz+74cLEejsKGftglotlbuUpPcA5V7cArhGuqQeF43I4 6bpuMwFQy9S/p0HEP5t4/AGYkfPoLIgiaCLPlEoUWHlDlepAmpCEet1nEwCVSTCUsoUpkKdovX72 NmjTx/mUMVP7ItIrHJKu19ovFX4MY6Dd26VMeILjQ91YgxzD/m5vgfILs2VUkE8CAwEAAaOCBDQw ggQwMA8GA1UdEwEB/wQFMAMBAf8wgewGCCsGAQUFBwELBIHfMIHcMIGSBggrBgEFBQcwBYaBhWxk YXA6Ly9sZGFwLmZwa2kuZ292L2NuPVNIQS0xJTIwRmVkZXJhbCUyMFJvb3QlMjBDQSxvdT1GUEtJ LG89VS5TLiUyMEdvdmVybm1lbnQsYz1VUz9jQUNlcnRpZmljYXRlO2JpbmFyeSxjcm9zc0NlcnRp ZmljYXRlUGFpcjtiaW5hcnkwRQYIKwYBBQUHMAWGOWh0dHA6Ly9odHRwLmZwa2kuZ292L3NoYTFm cmNhL2NhQ2VydHNJc3N1ZWRCeXNoYTFmcmNhLnA3YzALBgNVHQ8EBAMCAYYwHQYDVR0OBBYEFIaa XGL/c5PV4Yp/SsaILp9uoK4SMB8GA1UdIwQYMBaAFC9Yl9ipBZilVh/72at17wI8NjTHMIG5BgNV HR8EgbEwga4wgauggaiggaWGNWh0dHA6Ly9mcGtpYS5nc2EuZ292L0NvbW1vblBvbGljeS9Db21t b25Qb2xpY3koMSkuY3JshmxsZGFwOi8vZnBraWEuZ3NhLmdvdi9jbj1Db21tb24lMjBQb2xpY3ko MSksb3U9RkJDQSxvPVUuUy4lMjBHb3Zlcm5tZW50LGM9VVM/Y2VydGlmaWNhdGVSZXZvY2F0aW9u TGlzdDtiaW5hcnkwgdwGCCsGAQUFBwEBBIHPMIHMMEIGCCsGAQUFBzAChjZodHRwOi8vZnBraWEu Z3NhLmdvdi9Db21tb25Qb2xpY3kvQ29tbW9uUG9saWN5Um9vdC5wN2MwgYUGCCsGAQUFBzAChnls ZGFwOi8vZnBraWEuZ3NhLmdvdi9jbj1Db21tb24lMjBQb2xpY3ksb3U9RkJDQSxvPVUuUy4lMjBH b3Zlcm5tZW50LGM9VVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnksY3Jvc3NDZXJ0aWZpY2F0ZVBhaXI7 YmluYXJ5MB0GCSsGAQQBgjcUAgQQHg4AQwByAG8AcwBzAEMAQTCCASUGA1UdIASCARwwggEYMAwG CmCGSAFlAwIBAwYwDAYKYIZIAWUDAgEDBzAMBgpghkgBZQMCAQMIMAwGCmCGSAFlAwIBAw0wDAYK YIZIAWUDAgEDEDAMBgpghkgBZQMCAQMRMAwGCmCGSAFlAwIBAwEwDAYKYIZIAWUDAgEDAjAMBgpg hkgBZQMCAQMOMAwGCmCGSAFlAwIBAw8wDAYKYIZIAWUDAgEDEjAMBgpghkgBZQMCAQMUMAwGCmCG SAFlAwIBAxMwDAYKYIZIAWUDAgEDFTAMBgpghkgBZQMCAQMXMAwGCmCGSAFlAwIBAxYwDAYKYIZI AWUDAgEDGDAMBgpghkgBZQMCAQMZMAwGCmCGSAFlAwIBAxowDAYKYIZIAWUDAgEDGzANBgkqhkiG 9w0BAQUFAAOCAQEAJ5tT/JRijc0JZUndvpMysINUwQU6tAkbDEF3WwuFp4ZtNavrmN/wE3zXjO3R fL7fhafysKSCYmpmSn0Aflxgbza6kRbGYD6gqcNTbLLh30hACXibM+yMlPdqjGdak3bqV5YmqmcW aVD4Bwmuog1/yuFe1qqa7XbixXVAP1DkWcHLof3JO5L5hVuluSe3nLgce/Al3GTYiB6RWlugzGFw 4R14LWj82jviyqTQEXDNBVpJNl6Dfn6AKvHiXWE63jSWe6cBfctdfK1ceZhn/BvGuUM1c20iV3JB GN2zwzemh0pvHcOJTRhwnc3OVVoGKgfGU42Sp6dIoLBLQoQVgHWo6TCCB3cwggZfoAMCAQICBz4A AAAAUoUwDQYJKoZIhvcNAQEFBQAwajETMBEGCgmSJomT8ixkARkWA2NvbTEZMBcGCgmSJomT8ixk ARkWCWV2aW5jaWJsZTE4MDYGA1UEAxMvRXhvc3RhciBGZWRlcmF0ZWQgSWRlbnRpdHkgU2Vydmlj ZSBTaWduaW5nIENBIDEwHhcNMTExMTE2MTYzODQ0WhcNMTQxMTE1MTYzODQ0WjBaMRMwEQYKCZIm iZPyLGQBGRYDQ09NMRowGAYKCZImiZPyLGQBGRYKQkFFU1lTVEVNUzEnMCUGA1UEAwweUmljaGFy ZCBTa2VkZF8wMzY2KEVuY3J5cHRpb24pMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 0mTPKSarG6XBGzYAahGwNwO84HrVmO4jqwWuBZFi74kW/EQ0SJrqZE0JwXnpCp5hzwn7moYbbC4j sLldpxrs8SmiGHsrr2nntXGxypaMslUr4nuWfRYKIzJ8z7ikBblckNQA3xg1GeLgWwMVaL5CAnSf IlgYSYsxrPXHEADkfDgw8Nmt0GhW/NIszXqohdn/QUKFwy88s9w6fTuZDw7iHHVswRHBy1L8HEQ4 5TdomuPCts1WZSgAuMpKN1W7mspncByXV+7HOCmPZkvtQ3rXdiTvKWdXj8WXDJkd9svBxdf/5rCx qbgtFVIZJeU4HEkWNtgZlCEs5zIRDg70xTjwWwIDAQABo4IEMDCCBCwwDgYDVR0PAQH/BAQDAgQw MB0GA1UdDgQWBBTV3t1skQ6rFhqI0LrRWeKtQDT3RzBVBgNVHREETjBMgRxyaWNoYXJkLnNrZWRk QGJhZXN5c3RlbXMuY29toCwGCisGAQQBgjcUAgOgHgwccmljaGFyZC5za2VkZEBiYWVzeXN0ZW1z LmNvbTAfBgNVHSMEGDAWgBRKK8CquJCuKj8CU0G5o2x49LWppTCCAY8GA1UdHwSCAYYwggGCMIIB fqCCAXqgggF2hmdodHRwOi8vd3d3LmZpcy5ldmluY2libGUuY29tL2Zpcy9wdWJsaWMvRXhvc3Rh ciUyMEZlZGVyYXRlZCUyMElkZW50aXR5JTIwU2VydmljZSUyMFNpZ25pbmclMjBDQSUyMDEuY3Js hoIBCWxkYXA6Ly9sZGFwLmZpcy5ldmluY2libGUuY29tL0NOPUV4b3N0YXIlMjBGZWRlcmF0ZWQl MjBJZGVudGl0eSUyMFNlcnZpY2UlMjBTaWduaW5nJTIwQ0ElMjAxLENOPWF5c2NhMDJ2LENOPUNE UCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9u LERDPWZpcyxEQz1ldmluY2libGUsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q7Ymlu YXJ5P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQwggHFBggrBgEFBQcBAQSC AbcwggGzMHMGCCsGAQUFBzAChmdodHRwOi8vd3d3LmZpcy5ldmluY2libGUuY29tL2Zpcy9wdWJs aWMvRXhvc3RhciUyMEZlZGVyYXRlZCUyMElkZW50aXR5JTIwU2VydmljZSUyMFNpZ25pbmclMjBD QSUyMDEucDdjMIIBAAYIKwYBBQUHMAKGgfNsZGFwOi8vbGRhcC5maXMuZXZpbmNpYmxlLmNvbS9D Tj1FeG9zdGFyJTIwRmVkZXJhdGVkJTIwSWRlbnRpdHklMjBTZXJ2aWNlJTIwU2lnbmluZyUyMENB JTIwMSxDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29u ZmlndXJhdGlvbixEQz1maXMsREM9ZXZpbmNpYmxlLERDPWNvbT9jQUNlcnRpZmljYXRlO2JpbmFy eT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwOAYIKwYBBQUHMAGGLGh0 dHA6Ly9vY3NwLmZpcy5ldmluY2libGUuY29tL29jc3AvcmVzcG9uZGVyMCcGA1UdIAQgMB4wDQYL KwYBBAHsfAEBAQEwDQYLKwYBBAHsfAEBAQcwDQYJKoZIhvcNAQEFBQADggEBALsK94122kQbU9lF 3/nfiS/UiAJqI1LKfilb9VR9fxa1qcc9HjvDYRBPkGGMd5r09YDbRa1eJ9M/UDDwDssF6nGL/+rg qvxYoNPH/857l7d4xSbdh6MCEs1OmJ+lvvPQAQNjtIysE4l6UAtAJLY0CnMkh86yAA6667TTjTXc 9moXMtZOjCy3fFT1WSYmFdn7A9zuJaEvqd4AnkpAFDVlG4y4WMhvGjU+Vqie11ByGOTyqtWiUcjE /pV90V9x7QMtQOhwUBX0CClnwY6pmddUkCKmZtCGTZ4H1Qed4QtJTLJVaBm2C1QTt80pbrSdF9id WZiOzySqxbYgCSNiocTvt4gwggeoMIIGkKADAgECAgc+AAAAAFKEMA0GCSqGSIb3DQEBBQUAMGox EzARBgoJkiaJk/IsZAEZFgNjb20xGTAXBgoJkiaJk/IsZAEZFglldmluY2libGUxODA2BgNVBAMT L0V4b3N0YXIgRmVkZXJhdGVkIElkZW50aXR5IFNlcnZpY2UgU2lnbmluZyBDQSAxMB4XDTExMTEx NjE2Mzg0M1oXDTE0MTExNTE2Mzg0M1owWTETMBEGCgmSJomT8ixkARkWA0NPTTEaMBgGCgmSJomT 8ixkARkWCkJBRVNZU1RFTVMxJjAkBgNVBAMMHVJpY2hhcmQgU2tlZGRfMDM2NihTaWduYXR1cmUp MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4kSVXALvXaJmzVysMiU9koWZinw/rkH/ bQuDcolkmUeKCLgXL8IL+riHLyrs2X/PCrA5Ud5AzPupUnnC3Xibou1O+rCyu55EIi005wquIsNL w+eRzlnO9wvatrPtjmsCDJX1/2rLCxFCDIx5gCZYvJWSZEtndKlnFculGu9Sy9ogx7uIocCHvswE j5/D9/G9de+icF0dZ1ERdTfRw5P/dbOEBYupr1jZhPichW4nNh2U+a5ZP3QRXpyohAQk8gVA3nG1 zqcs6DOABUkIxo7Yk/Fp2bqR8OyI0l8+2JUliEU1dX76ksGxxm5frUCg/Mdi9f5XOQDApR/IXbaj C8OcVwIDAQABo4IEYjCCBF4wDgYDVR0PAQH/BAQDAgbAMB0GA1UdDgQWBBQeTYBy2qNz1rn45pdR ubqEoQuIcjBVBgNVHREETjBMgRxyaWNoYXJkLnNrZWRkQGJhZXN5c3RlbXMuY29toCwGCisGAQQB gjcUAgOgHgwccmljaGFyZC5za2VkZEBiYWVzeXN0ZW1zLmNvbTAfBgNVHSMEGDAWgBRKK8CquJCu Kj8CU0G5o2x49LWppTCCAY8GA1UdHwSCAYYwggGCMIIBfqCCAXqgggF2hmdodHRwOi8vd3d3LmZp cy5ldmluY2libGUuY29tL2Zpcy9wdWJsaWMvRXhvc3RhciUyMEZlZGVyYXRlZCUyMElkZW50aXR5 JTIwU2VydmljZSUyMFNpZ25pbmclMjBDQSUyMDEuY3JshoIBCWxkYXA6Ly9sZGFwLmZpcy5ldmlu Y2libGUuY29tL0NOPUV4b3N0YXIlMjBGZWRlcmF0ZWQlMjBJZGVudGl0eSUyMFNlcnZpY2UlMjBT aWduaW5nJTIwQ0ElMjAxLENOPWF5c2NhMDJ2LENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2 aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWZpcyxEQz1ldmluY2libGUsREM9 Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JM RGlzdHJpYnV0aW9uUG9pbnQwggHFBggrBgEFBQcBAQSCAbcwggGzMHMGCCsGAQUFBzAChmdodHRw Oi8vd3d3LmZpcy5ldmluY2libGUuY29tL2Zpcy9wdWJsaWMvRXhvc3RhciUyMEZlZGVyYXRlZCUy MElkZW50aXR5JTIwU2VydmljZSUyMFNpZ25pbmclMjBDQSUyMDEucDdjMIIBAAYIKwYBBQUHMAKG gfNsZGFwOi8vbGRhcC5maXMuZXZpbmNpYmxlLmNvbS9DTj1FeG9zdGFyJTIwRmVkZXJhdGVkJTIw SWRlbnRpdHklMjBTZXJ2aWNlJTIwU2lnbmluZyUyMENBJTIwMSxDTj1BSUEsQ049UHVibGljJTIw S2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1maXMsREM9ZXZp bmNpYmxlLERDPWNvbT9jQUNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdENsYXNzPWNlcnRp ZmljYXRpb25BdXRob3JpdHkwOAYIKwYBBQUHMAGGLGh0dHA6Ly9vY3NwLmZpcy5ldmluY2libGUu Y29tL29jc3AvcmVzcG9uZGVyMBMGA1UdJQQMMAoGCCsGAQUFBwMEMCcGA1UdIAQgMB4wDQYLKwYB BAHsfAEBAQEwDQYLKwYBBAHsfAEBAQcwGwYJKwYBBAGCNxUKBA4wDDAKBggrBgEFBQcDBDANBgkq hkiG9w0BAQUFAAOCAQEAdLGohI12Dogt33ZG/F/+5gLw1dbrdStfhwgw/dAlcxDnr1F28QVgqZLa Jo6kaib0sSZow/AVMJmZcecshWThzq0TrpdhE8ztLOZf26MSqWrZToEwO6CKOROPxKfCZzAK40Hk Qsut4BSk+ODl82tLHd9LOCVPZ7RN+q9NmZtW/ECjdcF3s4UO2Qn+ndjG5g1PT67S2KnKxmdUya9l B3WZBMeQVHk0bI7/MY+mxSJir1r8RDEU9EQ7TZt2SQ/GnTzaA98zmF40sNxrnLF1s0XLM0BkVWTi km4VLEOflFMbpLEbyNdD2yIm2EGFidMNjj3McE1J8u7W6xVy8lXam0l/dzGCA2owggNmAgEBMHUw ajETMBEGCgmSJomT8ixkARkWA2NvbTEZMBcGCgmSJomT8ixkARkWCWV2aW5jaWJsZTE4MDYGA1UE AxMvRXhvc3RhciBGZWRlcmF0ZWQgSWRlbnRpdHkgU2VydmljZSBTaWduaW5nIENBIDECBz4AAAAA UoQwCQYFKw4DAhoFAKCCAcowGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTIwODE1MTcwMjIwWjAjBgkqhkiG9w0BCQQxFgQUVs5beqVqKt56T93P42Gzr+/KfG8wWwYJ KoZIhvcNAQkPMU4wTDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowgYQGCSsGAQQBgjcQBDF3MHUwajETMBEG CgmSJomT8ixkARkWA2NvbTEZMBcGCgmSJomT8ixkARkWCWV2aW5jaWJsZTE4MDYGA1UEAxMvRXhv c3RhciBGZWRlcmF0ZWQgSWRlbnRpdHkgU2VydmljZSBTaWduaW5nIENBIDECBz4AAAAAUoUwgYYG CyqGSIb3DQEJEAILMXegdTBqMRMwEQYKCZImiZPyLGQBGRYDY29tMRkwFwYKCZImiZPyLGQBGRYJ ZXZpbmNpYmxlMTgwNgYDVQQDEy9FeG9zdGFyIEZlZGVyYXRlZCBJZGVudGl0eSBTZXJ2aWNlIFNp Z25pbmcgQ0EgMQIHPgAAAABShTANBgkqhkiG9w0BAQEFAASCAQCIrz0uy98tZmyD81Koh1uCqs1w EGLm/jlXL8/7QPLVov7rsRWKK/Rv7l6KR3L9MG/V3IaUTEIYRurT/3OlYUaPVliSQCk8zjRJn/w1 Rt8AWzY/uSLuMAUbMLA82Xx++gv3bVoJNyPaVuA7hQy9yZ6WVHcR3xeHmwuNdrth15885Y5D53My LMuarxUnKTgSuKeLzHntcf27hSu1iPDlWzLNieCoF1BS9t2rlCpkHoTGNPudoS0dw7t8m9Vhh0B/ T49RRQ/6IwDBLycf7DHNWIod1CDhT9PoAbskeSIiDjJcClEhNCzyCctfopa3dj55MQzwpfSifZWv rTS9LlYddU38AAAAAAAA ------=_NextPart_000_00D1_01CD7B10.1D6DA2F0-- From trevorf@exchange.microsoft.com Thu Aug 23 15:50:14 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 A8E5921F8581 for ; Thu, 23 Aug 2012 15:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.791 X-Spam-Level: X-Spam-Status: No, score=-102.791 tagged_above=-999 required=5 tests=[AWL=-0.192, BAYES_00=-2.599, 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 NReJpkMkFzqe for ; Thu, 23 Aug 2012 15:50:13 -0700 (PDT) Received: from na01b.map.o365filtering.com (by1c-gls.o365filtering.com [64.4.22.105]) by ietfa.amsl.com (Postfix) with ESMTP id 099DD21F8510 for ; Thu, 23 Aug 2012 15:50:12 -0700 (PDT) Received: from BLUSR01CA101.namsdf01.sdf.exchangelabs.com (10.255.124.146) by BLUSR01MB601.namsdf01.sdf.exchangelabs.com (10.255.124.166) with Microsoft SMTP Server (TLS) id 15.0.508.4; Thu, 23 Aug 2012 22:50:10 +0000 Received: from BY1FFOFD004.ffo.gbl (64.4.22.105) by BLUSR01CA101.outlook.com (10.255.124.146) with Microsoft SMTP Server (TLS) id 15.0.508.4 via Frontend Transport; Thu, 23 Aug 2012 22:50:10 +0000 Received: from hybrid.exchange.microsoft.com (131.107.1.27) by BY1FFOFD004.mail.o365filtering.com (10.1.16.61) with Microsoft SMTP Server (TLS) id 15.0.516.0 via Frontend Transport; Thu, 23 Aug 2012 22:50:10 +0000 Received: from df-h14-01.exchange.corp.microsoft.com (157.54.78.139) by DF-G14-02.exchange.corp.microsoft.com (157.54.87.56) with Microsoft SMTP Server (TLS) id 14.3.71.0; Thu, 23 Aug 2012 15:38:04 -0700 Received: from PIO-MLT-06.exchange.corp.microsoft.com (157.54.94.24) by DF-H14-01.exchange.corp.microsoft.com (157.54.78.139) with Microsoft SMTP Server (TLS) id 14.3.71.2; Thu, 23 Aug 2012 15:38:04 -0700 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.0083.000; Thu, 23 Aug 2012 15:38:04 -0700 From: Trevor Freeman To: "plasma@ietf.org" Thread-Topic: New Version Notification for draft-freeman-plasma-requirements-03.txt Thread-Index: AQHNgX/Wdp09laFQIUqlBGgiBjd4fZdn/L/g Date: Thu, 23 Aug 2012 22:38:03 +0000 Message-ID: References: <20120823223639.741.90319.idtracker@ietfa.amsl.com> In-Reply-To: <20120823223639.741.90319.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.102] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.1.27; IPV:NLI; EFV:FOP; SFV:NSPM; SFS:(377454001)(13464001)(377424002)(42186003)(33656001)(46102001)(16406001)(31966007); DIR:INB; LANG:en; X-Forefront-PRVS: 0582641F53 X-OriginatorOrg: DuplicateDomain-6c178e33-aecb-4786-8220-9afceeddbaf3.exchange.microsoft.com Subject: [plasma] FW: New Version Notification for draft-freeman-plasma-requirements-03.txt 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, 23 Aug 2012 22:50:14 -0000 SSBoYXZlIGp1c3QgcHVibGlzaGVkIGEgbmV3IHJlcXVpcmVtZW50cyBkcmFmdC4NCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFp bHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBUaHVyc2RheSwgQXVndXN0IDIz LCAyMDEyIDM6MzcgUE0NClRvOiBUcmV2b3IgRnJlZW1hbg0KQ2M6IHBwYXR0ZXJzb25AY2FyaWxs b24uY2E7IGlldGZAYXVndXN0Y2VsbGFycy5jb20NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtZnJlZW1hbi1wbGFzbWEtcmVxdWlyZW1lbnRzLTAzLnR4dA0KDQoN CkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1mcmVlbWFuLXBsYXNtYS1yZXF1aXJlbWVudHMt MDMudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFRyZXZvciBGcmVlbWFu IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1m cmVlbWFuLXBsYXNtYS1yZXF1aXJlbWVudHMNClJldmlzaW9uOgkgMDMNClRpdGxlOgkJIFJlcXVp cmVtZW50cyBmb3IgTWVzc2FnZSBBY2Nlc3MgQ29udHJvbA0KQ3JlYXRpb24gZGF0ZToJIDIwMTIt MDgtMjMNCldHIElEOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiA1 OQ0KVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC1mcmVlbWFuLXBsYXNtYS1yZXF1aXJlbWVudHMtMDMudHh0DQpTdGF0dXM6ICAgICAgICAg IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZnJlZW1hbi1wbGFzbWEtcmVx dWlyZW1lbnRzDQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWZyZWVtYW4tcGxhc21hLXJlcXVpcmVtZW50cy0wMw0KRGlmZjogICAgICAgICAgICBodHRw Oi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1mcmVlbWFuLXBsYXNtYS1yZXF1aXJl bWVudHMtMDMNCg0KQWJzdHJhY3Q6DQogICBUaGVyZSBhcmUgbWFueSBzaXR1YXRpb25zIHdoZXJl IG9yZ2FuaXphdGlvbnMgd2FudCB0byBwcm90ZWN0DQogICBpbmZvcm1hdGlvbiB3aXRoIHJvYnVz dCBhY2Nlc3MgY29udHJvbCwgZWl0aGVyIGZvciBpbXBsZW1lbnRhdGlvbiBvZg0KICAgaW50ZWxs ZWN0dWFsIHByb3BlcnR5IHJpZ2h0IHByb3RlY3Rpb25zLCBlbmZvcmNlbWVudCBvZiBjb250cmFj dHVhbA0KICAgY29uZmlkZW50aWFsaXR5IGFncmVlbWVudHMgb3IgYmVjYXVzZSBvZiBsZWdhbCBy ZWd1bGF0aW9ucy4gIFRoZQ0KICAgRW5oYW5jZWQgU2VjdXJpdHkgU2VydmljZXMgKEVTUykgZm9y IFMvTUlNRSBkZWZpbmVzIGFuIGFjY2VzcyBjb250cm9sDQogICBtZWNoYW5pc20gd2hpY2ggaXMg ZW5mb3JjZWQgYnkgdGhlIHJlY2lwaWVudCdzIGNsaWVudCBhZnRlcg0KICAgZGVjcnlwdGlvbiBv ZiB0aGUgbWVzc2FnZS4gVGhlIEVTUyBtZWNoYW5pc20gdGhlcmVmb3JlIGlzIGRlcGVuZGVudA0K ICAgb24gdGhlIGNvcnJlY3QgYWNjZXNzIHBvbGljeSBjb25maWd1cmF0aW9uIG9mIGV2ZXJ5IHJl Y2lwaWVudCdzDQogICBjbGllbnQuIFRoaXMgbWVjaGFuaXNtIGFsc28gcHJvdmlkZXMgZnVsbCBh Y2Nlc3MgdG8gdGhlIGRhdGEgdG8gYWxsDQogICByZWNpcGllbnRzIHByaW9yIHRvIHRoZSBhY2Nl c3MgY29udHJvbCBjaGVjaywgdGhpcyBpcyBjb25zaWRlcmVkIHRvDQogICBiZSBpbmFkZXF1YXRl IGR1ZSB0byB0aGUgZGlmZmljdWx0eSBpbiBkZW1vbnN0cmF0aW5nIHBvbGljeQ0KICAgY29tcGxp YW5jZS4NCg0KICAgVGhpcyBkb2N1bWVudCBsYXlzIG91dCB0aGUgZGVmaWNpZW5jaWVzIG9mIHRo ZSBjdXJyZW50IEVTUyBzZWN1cml0eQ0KICAgbGFiZWwsIGFuZCBwcmVzZW50cyByZXF1aXJlbWVu dHMgZm9yIGEgbmV3IG1vZGVsIGZvciBkb2luZy9wcm92aWRpbmcNCiAgIGFjY2VzcyBjb250cm9s IHRvIG1lc3NhZ2VzIHdoZXJlIHRoZSBhY2Nlc3MgY2hlY2sgaXMgcGVyZm9ybWVkIHByaW9yDQog ICB0byBtZXNzYWdlIGNvbnRlbnQgZGVjcnlwdGlvbi4gVGhpcyBuZXcgbW9kZWwgYWxzbyBkb2Vz IG5vdCByZXF1aXJlDQogICBwb2xpY3kgY29uZmlndXJhdGlvbiBvbiB0aGUgY2xpZW50IHRvIHNp bXBsaWZ5IGRlcGxveW1lbnQgYW5kDQogICBjb21wbGlhbmNlIHZlcmlmaWNhdGlvbi4NCg0KICAg VGhlIHByb3Bvc2VkIG1vZGVsIGFkZGl0aW9uYWxseSBwcm92aWRlcyBhIG1ldGhvZCB3aGVyZSBu b24tWC41MDkNCiAgIGNlcnRpZmljYXRlIGNyZWRlbnRpYWxzIGNhbiBiZSB1c2VkIGZvciBlbmNy eXB0aW9uL2RlY3J5cHRpb24gb2YNCiAgIFMvTUlNRSBtZXNzYWdlcy4NCg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0K From ietf@augustcellars.com Fri Aug 24 01:22:36 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 5001721F86DB for ; Fri, 24 Aug 2012 01:22:36 -0700 (PDT) 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 2b3TfL9YcHU6 for ; Fri, 24 Aug 2012 01:22:35 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2BF21F86D7 for ; Fri, 24 Aug 2012 01:22:34 -0700 (PDT) Received: from Tobias (keygal.lnk.telstra.net [120.151.176.33]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id D16EB2C9BE for ; Fri, 24 Aug 2012 01:22:31 -0700 (PDT) From: "Jim Schaad" To: References: <20120824081857.17940.14315.idtracker@ietfa.amsl.com> In-Reply-To: <20120824081857.17940.14315.idtracker@ietfa.amsl.com> Date: Fri, 24 Aug 2012 18:21:08 +1000 Message-ID: <04a901cd81d1$6c423a40$44c6aec0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG7RD/5EKldEW5v0mVetXyHG7+4UJeNGiMA Content-Language: en-us Subject: [plasma] FW: New Version Notification for draft-schaad-plasma-service-03.txt 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, 24 Aug 2012 08:22:36 -0000 This is a partial update dealing with the most recent changes. I am not = getting as much done as I would like. A fuller update should be out by = mid next month. Jim > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Friday, August 24, 2012 6:19 PM > To: ietf@augustcellars.com > Subject: New Version Notification for = draft-schaad-plasma-service-03.txt >=20 >=20 > A new version of I-D, draft-schaad-plasma-service-03.txt > has been successfully submitted by Jim Schaad and posted to the IETF > repository. >=20 > Filename: draft-schaad-plasma-service > Revision: 03 > Title: Plasma Service Trust Processing > Creation date: 2012-08-24 > WG ID: Individual Submission > Number of pages: 70 > URL: = http://www.ietf.org/internet-drafts/draft-schaad-plasma- > service-03.txt > Status: = http://datatracker.ietf.org/doc/draft-schaad-plasma-service > Htmlized: = http://tools.ietf.org/html/draft-schaad-plasma-service-03 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-schaad-plasma-service-03 >=20 > Abstract: > Write Me >=20 >=20 >=20 >=20 > The IETF Secretariat From trevorf@exchange.microsoft.com Fri Aug 24 09:24: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 3D1A021F8681 for ; Fri, 24 Aug 2012 09:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.453 X-Spam-Level: X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=-0.455, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, 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 7adF1vTtCDPa for ; Fri, 24 Aug 2012 09:24:05 -0700 (PDT) Received: from na01b.map.o365filtering.com (by1c-gls.o365filtering.com [64.4.22.105]) by ietfa.amsl.com (Postfix) with ESMTP id 7BCBB21F85C3 for ; Fri, 24 Aug 2012 09:24:04 -0700 (PDT) Received: from BLUSR01CA103.namsdf01.sdf.exchangelabs.com (10.255.124.148) by BLUSR01MB601.namsdf01.sdf.exchangelabs.com (10.255.124.166) with Microsoft SMTP Server (TLS) id 15.0.508.4; Fri, 24 Aug 2012 16:24:01 +0000 Received: from BY1FFOFD002.ffo.gbl (64.4.22.105) by BLUSR01CA103.outlook.com (10.255.124.148) with Microsoft SMTP Server (TLS) id 15.0.516.2 via Frontend Transport; Fri, 24 Aug 2012 16:24:01 +0000 Received: from hybrid.exchange.microsoft.com (131.107.1.17) by BY1FFOFD002.mail.o365filtering.com (10.1.16.51) with Microsoft SMTP Server (TLS) id 15.0.516.0 via Frontend Transport; Fri, 24 Aug 2012 16:24:00 +0000 Received: from DFM-TK5MBX15-01.exchange.corp.microsoft.com (157.54.110.8) by DF-G14-01.exchange.corp.microsoft.com (157.54.87.87) with Microsoft SMTP Server (TLS) id 14.3.71.0; Fri, 24 Aug 2012 09:23:39 -0700 Received: from PIO-MLT-06.exchange.corp.microsoft.com (157.54.94.24) by DFM-TK5MBX15-01.exchange.corp.microsoft.com (157.54.110.8) with Microsoft SMTP Server (TLS) id 15.0.485.6; Fri, 24 Aug 2012 09:23:35 -0700 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.0083.000; Fri, 24 Aug 2012 09:23:35 -0700 From: Trevor Freeman To: "Skedd, Richard (UK)" , "plasma@ietf.org" Thread-Topic: Basic and Advanced Policies Thread-Index: Ac2CFLQl6vIej1CvRzasuZiNycBmHw== Date: Fri, 24 Aug 2012 16:23:34 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.104] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0012_01CD81DA.142FC120" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.1.17; IPV:NLI; EFV:FOP; SFV:NSPM; SFS:(407274001)(377454001)(164054002)(13464001)(42186003)(512954001)(33656001)(46102001)(5343655001)(5343635001)(16406001)(31966007); DIR:INB; LANG:en; X-Forefront-PRVS: 0583A86C08 X-OriginatorOrg: DuplicateDomain-6c178e33-aecb-4786-8220-9afceeddbaf3.exchange.microsoft.com Subject: Re: [plasma] Basic and Advanced Policies 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, 24 Aug 2012 16:24:15 -0000 ------=_NextPart_000_0012_01CD81DA.142FC120 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0013_01CD81DA.142FC120" ------=_NextPart_001_0013_01CD81DA.142FC120 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Richard, The whole question of interoperability with policy parameters is a bit of a Pandora box issue. To work, both the policy expression language and the client need to support the parameter in question. It's an accurate observation that some Domain Specific Languages (DSLs) like XACML have limitations in the area of policy parameters. General Purpose Languages (GPLs) like C# don't have that limitation. Given the only policies today which will mandate a parameter are the basic policies, it would be trivial to author the basic policy in C#. Where a DSL supports parameters, then the policy authored by they DSL can likewise support parameters. Hopefully DSLs that don't support parameters would respond to the need so can be used by Plasma in the future. However support by the language is not the only issue. It would be hard to get client support without bounding the issues of the allowed set of possible policy parameters. In many ways this is the harder problem. We could try to dynamically discover the set of parameters a client supports but this would open up a complex matrix of where polices did, or did not work for any organization to manage. A simpler approach may be to simply define by plasma client version the set of parameters the client needs to support. You still have a matrix of what policies works where but it's a more bounded and manageable matrix. However for this approach to work we need rev the standard and to come to consensus around a set of parameters to incorporate into a client. Jury is out on what the right thing to do is here. Replay and forwarding do rains some extra considerations. With basic policy, I think to be consistent with S/MIME todays there is any boundary on recipients other than maintaining the policy itself. If you send requiring level 2 authentication or better for recipients then any forwarded or reply message should have the same policy. For policies without a recipient list the problem is more complex The high order bit seems not what operations are possible but what latitude does the recipient have to change the message policy. If you have a subject who otherwise would be allowed to see some content, who was omitted from the original message, it seems counter intuitive to suggest the message cannot be forwarded to them or they be added to a reply. Likewise if the information I add to my reply or forward requires me to apply my policy to my new data, then I should by default also be allowed to append a policy. Equably it would seem a privileged action to expand the set of possible readers, but you may want to allow it in some situations. Trevor -----Original Message----- From: Skedd, Richard (UK) [mailto:Richard.Skedd@baesystems.com] Sent: Wednesday, August 15, 2012 10:02 AM To: Trevor Freeman; plasma@ietf.org Subject: RE: Basic and Advanced Policies Thanks Trevor, please see some further thoughts in response to your two comments below: Addressee Only Policy OK, understood, the PDP could use the information in the message to process this policy, which will work where the PDP is capable of using a parameterized policy (e.g. asserted e-mail address matches one of the message recipients e-mail addresses) rather than an explicit policy (e.g. asserted e-mail address is one of list of values). My understanding is that parameters are not well supported by today's policy expression languages or my policy enforcement applications. If this is correct then it would be useful to flag these requirements. IMHO it would be good to use "Addressee Only Policy" or similar as the name for this capability rather than the less precise "Basic Policy". Replying to and forwarding messages could introduce new addressees and new sensitivities. There must be some definition of an addressee's scope for action, possibly with options that are selectable by the sender. Can an addressee reply, reply to all, reply and include new addressees, forward ? If, for example, the addressee replies to some of the original addressees with a message that is also covered by the "Addressee Only" policy then does the PDP use the recipient e-mail addresses for the reply or the original message to control access ? It would be useful to have the "Addressee Only" policy documented for use cases other than just reading of the initial message. Baseline Client Functionality >From what you say I understand that you are proposing that all clients will be capable of enforcing the "Addressee Only Policy". This means that they have the functionality to: 1. Retrieve multiple attributes about the requester (e-mail address, identity assurance level) from at least one attribute authority 2. Retrieve multiple attributes from the message/resource (applicable policies, allowed e-mail addresses, required minimum identity assurance level) 3. Identify the rule sets to use implement the applicable policies (Addressee Only with potentially specified limitations on recipient actions) 4. Retrieve the appropriate rule sets, I assume not "hardwired" in the client, although it may be cached for performance 5. Process the rule sets which will be expressed using attributes, parameters, comparison operators and logical operators (requester e-mail address is a member of allowed e-mail addresses AND identity assurance level >= required minimum identity assurance level) 6. Permit/deny the requested action (Any, or reply to all recipients, forward to new address) At this level a baseline client which is capable of enforcing the "Addressee Only Policy" will also meet all the functional requirements for an "Arbitrary Single Policy". Whether the user is a subscriber to the necessary attribute authorities and policy authorities to be able to exercise this functionality is another matter. Again we need to understand the intent of PLASMA for "Arbitrary Single Policy" use cases beyond read the initial message. Is a baseline client expected to be able to generate a reply which may also be subject to the "Addressee Only Policy" or an additional "Arbitrary Single Policy" ? Regards Richard Skedd Strategy Manager - Office of the CIO T: +44 117 918 8034 (vnet 7658 8034) M: +44 780 171 8260 (vnet 777118260) BAE Systems plc Registered Office: 6 Carlton Gardens, London, SW1Y 5AD, UK Registered in England & Wales No: 1470151 -----Original Message----- From: Trevor Freeman [mailto:trevorf@exchange.microsoft.com] Sent: 14 August 2012 19:26 To: Skedd, Richard (UK); plasma@ietf.org Subject: RE: Basic and Advanced Policies ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Hi Richard, The intent of basic policy is the former i.e. to replicate existing S/MIME functionality where the sender designates the list of authorized recipients. In the Plasma case basic policy has a parameter which is the list of recipients. The policy defines "anybody presenting an authenticated email attribute where the attribute value matches one of the named recipients and the level of assurance of the identity matches that required under the policy would pass the policy". We don't need a new policy ID per recipients list. I agree we need a baseline of common functionality for the client. Technical all of the policy complexity is hidden from the client so a recipient is unaware how many polices were applied to a message. Policy complexity would only be manifest by the set of attributes the policy can request. In the advanced case, the set of attributes is unbounded. What do we put into the economy version of the Plasma client? The base client would likely have to exist as part of an email service as part of their baseline offering at very little margin in order to be pervasive. Current proposal is to put enough in to support the Personal to Addressee scenario. We should be able to build into the base profile, recognition that you need the full featured version securely e.g. no "please clink on this link and install my latest malware" kind of experience. The proliferation of app stores and marketplaces will help here. Trevor -----Original Message----- From: [RWS] plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of Skedd, Richard (UK) Sent: Friday, July 27, 2012 2:35 AM To: plasma@ietf.org Subject: [plasma] Basic and Advanced Policies A follow-up on comments by Trevor Freeman, kindly forwarded by Patrick Patterson, and Jean-Paul Buu-Sao on the requirements for Basic v Advanced Policies and the update of have draft-freeman-plasma-requirements-02 which now states that: 4.6.1 Basic Policy Basic policy is intended to be universally usable by using a small fixed set of attributes. For example, basic policy is intended to be equivalent to sending encrypted Email with S/MIME today. It is a simple policy that authenticated recipients of the Email get access to the message. Its intended target is simple scenarios involving consumers and small businesses who are using public PIP which issue a limited set of attributes. It is expected that all Plasma clients and commercial IdP would be capable of supporting basic policy due to their simplicity and basic attribute set. 4.6.2 Advanced Policy Advanced policy is intended to be used where one or more arbitrary policies are required on the content . It is intended to target more complex scenarios such as content with regulated information or content subject to other organization and contractual policies. The input set of attributes is defined by the policies and can be either primordial or derived attributes or both. Multiple policies have a logical relationship e.g. they can be AND or ORed together. It is not expected that all Plasma clients support advances policy. In my view the terminology proposed does not reflect the capabilities described nor do the capabilities described align with typical use cases. If the intent of the "Basic Policy" is actually to replicate S/MIME functionality then it is an "Object Access Control List Policy". The mechanism of S/MIME combined with the list of addressees effectively limits access to the addressees but without originator control over further use of the content by the addressees. This is a valuable approach as it deals with the "Personal to Addressee" and similar use cases by giving the originator bespoke control over distribution. However, it does not involve a "Basic Policy" as a new policy with a unique ACL will need to be generated for every message. If the intent of the "Basic Policy" is to address " simple scenarios involving consumers and small businesses who are using public PIPs which issue a limited set of attributes" then this must require the ability to create rules which include logical operators (AND, OR etc) to process the attributes. eg "Customer for Product X AND Customer for Product Y", "Customer for Product X OR Retailer of Product X". This is effectively addressing the requirements of an object linked to a "Single Policy" rather than a "Basic Policy". Dealing with "Single Policies" rather than multiple policies would then be consistent with the statement that "Advanced Policy is intended to be used where one or more arbitrary policies are required on the content". Which raises a further question, is the ability to cope with content which references multiple policies an optional capability? The paper refers to a e-mail thread in which the addition of information also adds additional policies. Surely this scenario occurs everywhere all the time. Any request response scenario could involve data that is sensitive to each party eg "Can you quote to supply X, My price for X is $$$" or "Can you come to a meeting about X, No because I need to do Y". It thus seems to me that whilst there are different policy usage scenarios (Bespoke, Single, Multiple) these must all be core PLASMA capabilities supported by all PLASMA clients rather than add-ons for specialist applications by some communities of interest. Regards Richard Skedd Strategy Manager - Office of the CIO T: +44 117 918 8034 (vnet 7658 8034) M: +44 780 171 8260 (vnet 777118260) BAE Systems plc Registered Office: 6 Carlton Gardens, London, SW1Y 5AD, UK Registered in England & Wales No: 1470151 -----Original Message----- From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of Patrick Patterson Sent: 25 July 2012 16:08 To: Jean-Paul Buu-Sao Cc: plasma@ietf.org Subject: Re: [plasma] Comments on Message Access Control Requirements Draft ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- The following message has been forwarded from Trevor, as he is still having difficulties posting to the list: ----- BEGIN FORWARDED MESSAGE ----- Hi Jean-Paul, Just catching up from Holiday. I have just posted a new draft of the requirements doc you may want to check out. We have has a lot of feedback on our terminology so this new draft has attempted to improve that area. We have changed PEP to be a Decision Requestor to more clearly indicate it does not enforce decisions. We did not adopt the Access Requestor name from the XACML model as we have other types of decisions such as integrity policy decision requests. PDP has changed to Policy Decision and Enforcement Point to emphasize in the Plasma model these functions are logically one. That does not preclude implementations from implementing them as separate entities but that implementations detail would not impact Plasma. You should also read the technical drafts from the implantation details. http://datatracker.ietf.org/doc/draft-schaad-plasma-cms/ http://datatracker.ietf.org/doc/draft-schaad-plasma-service/ More inline below Trevor -----Original Message----- From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of Jean-Paul Buu-Sao Sent: Monday, July 23, 2012 1:25 AM To: plasma@ietf.org Subject: [plasma] Comments on Message Access Control Requirements Draft Greetings, Please find my comments on the PLASMA draft 01: http://tools.ietf.org/pdf/draft-freeman-plasma-requirements-01.pdf: 1) Policy Data Binding Section 4.2.1: "The chief strength of binding by names is once bound to the data the association with the policy travels with the data. The chief weakness in binding by name is it requires the reference to be strongly bound to the data [...] This model is choosing to use binding by name because we need to encrypt the data which means we will [be] impacting the storage format anyway which negates the main weakness of binding my name." TSCP approves of the choice of "binding by name". Another chief strength that you did not quote, and which is key differentiator to TSCP, is to allow policy change, with no impact on the data. This requirement cannot be met with binding by value or by description. [TF] Good Point will add this to the draft The draft is silent on how the name would be expressed. Can it be any arbitrary identifier, which precise syntax and semantics could be defined by a community of interest defined profile? [TF] If you read the plasma service draft you will see we use a URI. We believe that has sufficient flexibility to address the requirements you describe. 2) Closed versus Open environment Section 4.4: "(A) The PEP verifies the certificate in the signed metadata then determines <> if it want to process the protected information based on the identity of the PDP (D) The PDP decrypts the metadata, de-references the policy pointers and determines the set of access rules based on the <>. The PDP then determines the set of subject attributes it needs to evaluate the access rules. The PDP can the use PIP is has relationships with to query attributers about the subject. The list of attributes the PDP is missing is then returned to the PEP" As stated the workflow implies a "closed environment". TSCP expected to see a workflow that could as well support an "open environment", whereas not all referenced policies are necessarily known by the local PDP/PAP ahead of time. [TF] Since the PAP authors the policies and creates the policy reference, I don't understand a client can have a policy reference that a PAP does not know about so can you describe how this would occur. There are a logical sequence of PDEPs in Plasma. These can be physically the same PDEP or they can be separate PDEPs. * The PDEP which generates the role token * The PDEP which generates the message token * The PDEP which generates the read token Only the first PDEP needs prior knowledge of the policies which is necessary for it to generate the policy collection in the role token. All subsequent PDEPs can use the URI to discover the policies. As a related topic, Policy Publication Point (PPP), lightly introduced in the Vocabulary section, is a good addition to [RFC3198] and [XACML-core]. In view of the support for "open environments", TSCP expected to see more requirements on PPP. 3) Advanced Policies Section 4.5.2: "Advanced policy is intended to be used where one or more arbitrary policies are required on the content. It is intended to target more complex scenarios such as content with regulated information or content subject to other organization and contractual policies. The input set of attributes is defined by the policies and can be either primordial or derived attributes or both. Multiple policies have a logical relationship e.g. they can be <>. <>." [TF] The text was not intended to indicate only simple logical relationships would be expressed so I will change to say "AND and/or ORed together in an arbitrary combination". The technical draft uses a logic trees so already supports what you describe. TSCP mandates a support for "advances policies". [TF] I understand some communities of interest would require use of Advances Polices. However I don't want to burden every Plasma client implementation to support such policies. The basic policy set is aimed a simple set of scenarios where the Plasma client may well be bundled in at no charge so any additional complexity would be a tax. A premium client which supports advanced polices can then be purchased where there is business value in doing so e.g. a mandate from a community of interest such as TSCP. A typical example is to support documents that must be simultaneously protected under an Export Control policy (e.g. ITAR Technical Assistance Agreement) and an Intellectual Property policy (e.g. Proprietary Information Exchange Agreement). In this case of multiple policies, TSCP requires that all the applicable policies are to be evaluated, with each one of the specified policy allowing the required access. So this cannot just be a simple OR, as the Plasma draft states. 4) Policy Expression Language The draft is silent on the positioning of PLASMA with Policy Expression Languages. Is there one in particular that PLASMA mandates (if so, which one), or is the specification agnostic (if so, what are the baseline requirements in terms of expressiveness)? [TF] For the requirements I intend to be language neutral. We do intend to address PDAP-PAP interaction in a subsequent technical paper where the topic will have to be addressed. Some communities of interest have made significant investments in XACML but it has not been universally adopted so plasma has a tradeoff between mandating a specific language to improve interoperability and alienating communities to do not use XACML. I don't know the right answer at this time but that answer does not impact the current work. We do need to support language negotiation between PDEP and PAP so at a minimum so we can support communities of interest and also be forwards compatible. Some organizations have developed and validated a broad set of policies, expressed in a Policy Expression Language of their choosing (e.g. XACML 2.0), and need to be able to reuse them. Thanks, Jean-Paul Buu-Sao, TSCP ---- END FORWARDED MESSAGE ----- --- Patrick Patterson President and Chief PKI Architect Carillon Information Security Inc. http://www.carillon.ca tel: +1 514 485 0789 mobile: +1 514 994 8699 fax: +1 450 424 9559 _______________________________________________ plasma mailing list plasma@ietf.org https://www.ietf.org/mailman/listinfo/plasma ------=_NextPart_001_0013_01CD81DA.142FC120 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Richard,

 

The whole question of interoperability with policy = parameters is a bit of a

Pandora = box issue. To work, both the policy expression language and = the

client need to support the = parameter in question.

 

It's = an accurate observation that some Domain Specific Languages (DSLs) = like

XACML have limitations in the = area of policy parameters. General Purpose

Languages (GPLs) like C# don’t have that = limitation. Given the only policies

today which will mandate a parameter are the basic = policies, it would be

trivial to = author the basic policy in C#. Where a DSL supports = parameters,

then the policy = authored by they DSL can likewise support parameters.

Hopefully DSLs that don’t support parameters = would respond to the need so

can = be used by Plasma in the future. However support by the language is = not

the only issue.  =

 

It would be hard to get client support without = bounding the issues of the

allowed = set of possible policy parameters. In many ways this is the = harder

problem. We could try to = dynamically discover the set of parameters a client

supports but this would open up a complex matrix of = where polices did, or

did not work = for any organization to manage. A simpler approach may be = to

simply define by plasma client = version the set of parameters the client

needs to support.  You still have a matrix of = what policies works where but

it’s a more bounded and manageable matrix. = However for this approach to work

we need rev the standard and to come to consensus = around a set of parameters

to = incorporate into a client. Jury is out on what the right thing to do = is

here.

 

Replay = and forwarding do rains some extra considerations. With basic policy, I = think to be consistent with S/MIME todays there is any boundary on = recipients other than maintaining the policy itself.  If you send = requiring level 2 authentication or better for recipients then any = forwarded or reply message should have the same policy. =

 

For policies without a recipient list the problem = is more complex

 

The = high order bit seems not what operations are possible but what latitude = does the recipient have to change the message policy.  If you have = a subject who otherwise would be allowed to see some content, who was = omitted from the original message, it seems counter intuitive to suggest = the message cannot be forwarded to them or they be added to a reply. = Likewise if the information I add to my reply or forward requires me to = apply my policy to my new data, then I should by default also be allowed = to append a policy. Equably it would seem a privileged action to expand = the set of possible readers, but you may want to allow it in some = situations.

 

Trevor

 

-----Original Message-----

From: Skedd, Richard (UK) = [mailto:Richard.Skedd@baesystems.com]

Sent: Wednesday, August 15, 2012 10:02 = AM

To: Trevor Freeman; = plasma@ietf.org

Subject: RE: Basic = and Advanced Policies

 

Thanks = Trevor, please see some further thoughts in response to your = two

comments = below:

 

Addressee Only Policy

 

OK, = understood, the PDP could use the information in the message to = process

this policy, which will = work where the PDP is capable of using a

parameterized policy (e.g. asserted e-mail address = matches one of the message

recipients e-mail addresses) rather than an = explicit policy (e.g. asserted

e-mail address is one of list of values).  My = understanding is that

parameters = are not well supported by today's policy expression languages = or

my policy enforcement = applications.  If this is correct then it would be

useful to flag these requirements.

 

IMHO = it would be good to use "Addressee Only Policy" or similar as = the name

for this capability = rather than the less precise "Basic Policy".

 

Replying to and forwarding messages could introduce = new addressees and new

sensitivities.  There must be some definition = of an addressee's scope for

action, possibly with options that are selectable = by the sender.  Can an

addressee reply, reply to all, reply and include = new addressees, forward ?

If, for = example, the addressee replies to some of the original = addressees

with a message that is = also covered by the "Addressee Only" policy then = does

the PDP use the recipient = e-mail addresses for the reply or the original

message to control access ?  It would be = useful to have the "Addressee Only"

policy documented for use cases other than just = reading of the initial

message.

 

Baseline Client Functionality

 

From = what you say I understand that you are proposing that all clients = will

be capable of enforcing the = "Addressee Only Policy".  This means that = they

have the functionality = to:

 

1.  Retrieve multiple attributes about the = requester (e-mail address,

identity assurance level) from at least one = attribute authority

2.  = Retrieve multiple attributes from the message/resource = (applicable

policies, allowed = e-mail addresses, required minimum identity assurance

level)

3.  Identify the rule sets to use implement = the applicable policies

(Addressee = Only with potentially specified limitations on recipient = actions)

4.  Retrieve the = appropriate rule sets, I assume not "hardwired" in = the

client, although it may be = cached for performance

5.  = Process the rule sets which will be expressed using = attributes,

parameters, comparison = operators and logical operators (requester e-mail

address is a member of allowed e-mail addresses AND = identity assurance level

>=3D = required minimum identity assurance level)

6.  Permit/deny the requested action (Any, or = reply to all recipients,

forward = to new address)

 

At = this level a baseline client which is capable of enforcing the = "Addressee

Only Policy" = will also meet all the functional requirements for an

"Arbitrary Single Policy".  Whether = the user is a subscriber to the

necessary attribute authorities and policy = authorities to be able to

exercise = this functionality is another matter.  Again we need to = understand

the intent of PLASMA = for "Arbitrary Single Policy" use cases beyond read = the

initial message.  Is a = baseline client expected to be able to generate a

reply which may also be subject to the = "Addressee Only Policy" or an

additional "Arbitrary Single Policy" = ?

 

Regards

 

Richard Skedd

Strategy Manager - Office of the = CIO

T:    +44 117 = 918 8034 (vnet 7658 8034)

M:    +44 780 171 8260 (vnet = 777118260)

 

BAE Systems plc

Registered Office: 6 Carlton Gardens, London, SW1Y = 5AD, UK

Registered in England = & Wales No: 1470151

 

 

-----Original Message-----

From: Trevor Freeman = [mailto:trevorf@exchange.microsoft.com]

Sent: 14 August 2012 19:26

To: Skedd, Richard (UK); = plasma@ietf.org

Subject: RE: Basic = and Advanced Policies

 

----------------------! WARNING ! = ---------------------- This message

originates from outside our organisation, either = from an external partner or

from = the internet.

Keep this in mind if = you answer this message.

Follow = the 'Report Suspicious Emails' link on IT matters for instructions = on

reporting suspicious email = messages.

----------------------------------------------------= ----

 

Hi Richard,

 

The = intent of basic policy is the former i.e. to replicate existing = S/MIME

functionality where the = sender designates the list of authorized recipients.

In the Plasma case basic policy has a parameter = which is the list of

recipients. = The policy defines "anybody presenting an authenticated = email

attribute where the = attribute value matches one of the named recipients and

the level of assurance of the identity matches that = required under the

policy would = pass the policy". We don't need a new policy ID per = recipients

list.

 

I = agree we need a baseline of common functionality for the client. = Technical

all of the policy = complexity is hidden from the client so a recipient is

unaware how many polices were applied to a message. = Policy complexity would

only be = manifest by the set of attributes the policy can request. In = the

advanced case, the set of = attributes is unbounded. What do we put into the

economy version of the Plasma client? The base = client would likely have to

exist = as part of an email service as part of their baseline offering at = very

little margin in order to be = pervasive.  Current proposal is to put enough

in to support the Personal to Addressee scenario. = We should be able to build

into = the base profile, recognition that you need the full featured = version

securely e.g. no = "please clink on this link and install my latest = malware"

kind of experience. = The proliferation of app stores and marketplaces will

help here.

 

Trevor =

 

-----Original Message-----

From:

[RWS] =

 

plasma-bounces@ietf.org = [mailto:plasma-bounces@ietf.org] On Behalf Of Skedd,

Richard (UK)

Sent: Friday, July 27, 2012 2:35 = AM

To: = plasma@ietf.org

Subject: [plasma] = Basic and Advanced Policies

 

A = follow-up on comments by Trevor Freeman, kindly forwarded by = Patrick

Patterson, and Jean-Paul = Buu-Sao on the requirements for Basic v Advanced

Policies and the update of have = draft-freeman-plasma-requirements-02 which

now states that:

 

4.6.1 = Basic Policy

 

Basic = policy is intended to be universally usable by using a small fixed = set

of attributes. For example, = basic policy is intended to be equivalent to

sending encrypted Email with S/MIME today.  It = is a simple policy that

authenticated recipients of the Email get access to = the message.  Its

intended = target is simple scenarios involving consumers and small = businesses

who are using public = PIP which issue a limited set of attributes. It is

expected that all Plasma clients and commercial IdP = would be capable of

supporting = basic policy due to their simplicity and basic attribute = set.

 

4.6.2 Advanced Policy

 

Advanced policy is intended to be used where one or = more arbitrary policies

are = required on the content . It is intended to target more = complex

scenarios such as content = with regulated information or content subject to

other organization and contractual policies. The = input set of attributes is

defined = by the policies and can be either primordial or derived = attributes

or both. =

Multiple policies have a logical = relationship e.g. they can be AND or ORed

together. It is not expected that all Plasma = clients support advances

policy.

 

In my = view the terminology proposed does not reflect the = capabilities

described nor do the = capabilities described align with typical use cases.

 

If the = intent of the "Basic Policy" is actually to replicate = S/MIME

functionality then it is an = "Object Access Control List Policy".  = The

mechanism of S/MIME combined = with the list of addressees effectively limits

access to the addressees but without originator = control over further use of

the = content by the addressees.  This is a valuable approach as it deals = with

the "Personal to = Addressee" and similar use cases by giving the = originator

bespoke control over = distribution.  However, it does not involve a = "Basic

Policy" as a new = policy with a unique ACL will need to be generated for

every message.

 

If the = intent of the "Basic Policy" is to address " simple = scenarios

involving consumers and = small businesses who are using public PIPs which

issue a limited set of attributes" then this = must require the ability to

create = rules which include logical operators (AND, OR etc) to process = the

attributes.  eg = "Customer for Product X AND Customer for Product = Y",

"Customer for = Product X OR Retailer of Product X".  This is = effectively

addressing the = requirements of an object linked to a "Single Policy" = rather

than a "Basic = Policy".

 

Dealing with "Single Policies" rather = than multiple policies would then be

consistent with the statement that "Advanced = Policy is intended to be used

where one or more arbitrary policies are required = on the content".  Which

raises a further question, is the ability to cope = with content which

references = multiple policies an optional capability?  The paper refers to = a

e-mail thread in which the = addition of information also adds additional

policies.  Surely this scenario occurs = everywhere all the time.  Any request

response scenario could involve data that is = sensitive to each party eg "Can

you quote to supply X, My price for X is $$$" = or "Can you come to a meeting

about X, No because I need to do = Y".

 

It thus seems to me that whilst there are different = policy usage scenarios

(Bespoke, = Single, Multiple) these must all be core PLASMA = capabilities

supported by all = PLASMA clients rather than add-ons for specialist

applications by some communities of = interest.

 

Regards

 

Richard Skedd

Strategy Manager - Office of the = CIO

T:    +44 117 = 918 8034 (vnet 7658 8034)

M:    +44 780 171 8260 (vnet = 777118260)

 

BAE Systems plc

Registered Office: 6 Carlton Gardens, London, SW1Y = 5AD, UK Registered in

England = & Wales No: 1470151

 

 

-----Original Message-----

From: plasma-bounces@ietf.org = [mailto:plasma-bounces@ietf.org] On Behalf Of

Patrick Patterson

Sent: 25 July 2012 16:08

To: Jean-Paul Buu-Sao

Cc: plasma@ietf.org

Subject: Re: [plasma] Comments on Message Access = Control Requirements Draft

 

----------------------! WARNING ! = ---------------------- This message

originates from outside our organisation, either = from an external partner or

from = the internet.

Keep this in mind if = you answer this message.

Follow = the 'Report Suspicious Emails' link on IT matters for instructions = on

reporting suspicious email = messages.

----------------------------------------------------= ----

 

The following message has been forwarded from = Trevor, as he is still having

difficulties posting to the list:

 

----- = BEGIN FORWARDED MESSAGE -----

 

Hi = Jean-Paul,

 

Just catching up from Holiday.

 

I have = just posted a new draft of the requirements doc you may want to = check

out. We have has a lot of = feedback on our terminology so this new draft has

attempted to improve that area.

 

We = have changed PEP to be a Decision Requestor to more clearly indicate = it

does not enforce decisions. We = did not adopt the Access Requestor name from

the XACML model as we have other types of decisions = such as integrity policy

decision = requests.

 

PDP has changed to Policy Decision and Enforcement = Point to emphasize in the

Plasma = model these functions are logically one. That does not = preclude

implementations from = implementing them as separate entities but that

implementations detail would not impact = Plasma.

 

You should also read the technical drafts from the = implantation details.

 

http://datatracker.ietf.org/doc/draft-schaad-plasma-= cms/

http://datatracker.ietf.org/doc/draft-schaad-plasma-= service/

 

More inline below

 

Trevor

 

-----Original Message-----

From: = plasma-bounces@ietf.org<mailto:plasma-bounces@ietf.org><= /p>

[mailto:plasma-bounces@ietf.org]<mailto:[mailto:p= lasma-bounces@ietf.org]> On

Behalf Of Jean-Paul Buu-Sao

Sent: Monday, July 23, 2012 1:25 = AM

To: = plasma@ietf.org<mailto:plasma@ietf.org>

Subject: [plasma] Comments on Message Access = Control Requirements Draft

 

 

 

Greetings,

 

 

 

Please = find my comments on the PLASMA draft 01:

http://tools.ietf.org/pdf/draft-freeman-plasma-requi= rements-01.pdf:

 

 

 

1) = Policy Data Binding

 

 

 

Section 4.2.1:

 

"The chief strength of binding by names is = once bound to the data the

association with the policy travels with the data. = The chief weakness in

binding by = name is it requires the reference to be strongly bound to = the

data [...] This model is = choosing to use binding by name because we need to

encrypt the data which means we will [be] impacting = the storage format

anyway which = negates the main weakness of binding my name."

 

TSCP = approves of the choice of "binding by name". Another chief = strength

that you did not quote, = and which is key differentiator to TSCP, is to allow

policy change, with no impact on the data. This = requirement cannot be met

with = binding by value or by description.

 

[TF] = Good Point will add this to the draft

 

The = draft is silent on how the name would be expressed. Can it be = any

arbitrary identifier, which = precise syntax and semantics could be defined by

a community of interest defined = profile?

 

[TF] If you read the plasma service draft you will = see we use a URI. We

believe that = has sufficient flexibility to address the requirements = you

describe.

 

 

 

2) = Closed versus Open environment

 

Section 4.4:

 

"(A) The PEP verifies the certificate in the = signed metadata then determines

<<via local policy>> if it want to = process the protected information based

on the identity of the PDP

 

(D) = The PDP decrypts the metadata, de-references the policy pointers = and

determines the set of access = rules based on the <<policy published by the

PAP>>. The PDP then determines the set of = subject attributes it needs to

evaluate the access rules. The PDP can the use PIP = is has relationships with

to query = attributers about the subject. The list of attributes the PDP = is

missing is then returned to the = PEP"

 

As stated the workflow implies a "closed = environment". TSCP expected to see

a workflow that could as well support an "open = environment", whereas not all

referenced policies are necessarily known by the = local PDP/PAP ahead of

time.

 

[TF] = Since the PAP authors the policies and creates the policy reference, = I

don't understand a client can = have a policy reference that a PAP does not

know about so can you describe how this would = occur.

 

There are a logical sequence of PDEPs in Plasma. = These can be physically the

same = PDEP or they can be separate PDEPs.

 

*        The = PDEP which generates the role token

 

*        The = PDEP which generates the message token

 

*        The = PDEP which generates the read token

 

Only = the first PDEP needs prior knowledge of the policies which is = necessary

for it to generate the = policy collection in the role token. All subsequent

PDEPs can use the URI to discover the = policies.

 

As a related topic, Policy Publication Point (PPP), = lightly introduced in

the = Vocabulary section, is a good addition to [RFC3198] and [XACML-core]. = In

view of the support for = "open environments", TSCP expected to see = more

requirements  on = PPP.

 

 

 

3) = Advanced Policies

 

Section 4.5.2:  "Advanced policy is = intended to be used where one or more

arbitrary policies are required on the content. It = is intended to target

more complex = scenarios such as content with regulated information or = content

subject to other = organization and contractual policies. The input set of

attributes is defined by the policies and can be = either primordial or

derived = attributes or both. Multiple policies have a logical = relationship

e.g. they can be = <<AND or ORed together>>. <<It is not expected that = all

Plasma clients support = advances policy>>."

 

[TF] = The text was not intended to indicate only simple logical = relationships

would be expressed = so I will change to say "AND and/or ORed together in = an

arbitrary combination". = The technical draft uses a logic trees so already

supports what you describe.

 

 

 

TSCP = mandates a support for "advances policies".

 

[TF] I = understand some communities of interest would require use of = Advances

Polices. However I don't = want to burden every Plasma client implementation

to support such policies. The basic policy set is = aimed a simple set of

scenarios = where the Plasma client may well be bundled in at no charge so = any

additional complexity would be = a tax. A premium client which supports

advanced polices can then be purchased where there = is business value in

doing so e.g. = a mandate from a community of interest such as TSCP.

 

A = typical example is to support documents that must be = simultaneously

protected under an = Export Control policy (e.g. ITAR Technical Assistance

Agreement) and an Intellectual Property policy = (e.g. Proprietary Information

Exchange Agreement). In this case of multiple = policies, TSCP requires that

all = the applicable policies are to be evaluated, with each one of = the

specified policy allowing the = required access.

 

So = this cannot just be a simple OR, as the Plasma draft = states.

 

 

 

 

 

4) = Policy Expression Language

 

The = draft is silent on the positioning of PLASMA with Policy = Expression

Languages. Is there one = in particular that PLASMA mandates (if so, which

one), or is the specification agnostic (if so, what = are the baseline

requirements in = terms of expressiveness)?

 

 

 

 

[TF] = For the requirements I intend to be language neutral. We do intend = to

address PDAP-PAP interaction in = a subsequent technical paper where the topic

will have to be addressed. Some communities of = interest have made

significant = investments in  XACML but it has not been universally adopted = so

plasma has a tradeoff between = mandating a specific language to improve

interoperability and alienating communities to do = not use XACML. I don't

know the = right answer at this time but that answer does not impact = the

current work.  We do need = to support language negotiation between PDEP and

PAP so at a minimum so we can support communities = of interest and also be

forwards = compatible.

 

 

 

Some = organizations have developed and validated a broad set of = policies,

expressed in a Policy = Expression Language of their choosing (e.g. XACML

2.0), and need to be able to reuse = them.

 

 

 

Thanks,

 

Jean-Paul Buu-Sao, TSCP

 

---- = END FORWARDED MESSAGE -----

 

---

Patrick = Patterson

President and Chief PKI = Architect

Carillon Information = Security Inc.

http://www.carillon.ca

 

tel: = +1 514 485 0789

mobile: +1 514 994 = 8699

fax: +1 450 424 = 9559

 

 

 

 

 

_______________________________________________=

plasma mailing list

plasma@ietf.org

https://www.ietf.org/mailman/listinfo/plasma

 

 

------=_NextPart_001_0013_01CD81DA.142FC120-- ------=_NextPart_000_0012_01CD81DA.142FC120 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIY8zCCAlow ggHDAgIBpTANBgkqhkiG9w0BAQQFADB1MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPR1RFIENvcnBv cmF0aW9uMScwJQYDVQQLEx5HVEUgQ3liZXJUcnVzdCBTb2x1dGlvbnMsIEluYy4xIzAhBgNVBAMT GkdURSBDeWJlclRydXN0IEdsb2JhbCBSb290MB4XDTk4MDgxMzAwMjkwMFoXDTE4MDgxMzIzNTkw MFowdTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0dURSBDb3Jwb3JhdGlvbjEnMCUGA1UECxMeR1RF IEN5YmVyVHJ1c3QgU29sdXRpb25zLCBJbmMuMSMwIQYDVQQDExpHVEUgQ3liZXJUcnVzdCBHbG9i YWwgUm9vdDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAlQ+gtvBQnOh6x4jN3RcOLrCU0Bs9 DvaUwIqUxwbIkJfIuGQaen5sPFPhNyhzYH+yl1MHn1P5bViU0q+NbYhngObtspXPcjHKpRxyulwC 52RC5/mpLNY6DayNQqokATnmnD8BhVcNWIdF+NOFqpNpJoVwSIA/EhXHebQfBS87YpkCAwEAATAN BgkqhkiG9w0BAQQFAAOBgQBt6xsJ6V7ZUdtnImGkKjxId+OgfKbec6IUA4U9+6sOMMWDFjOBEwie ezRO30DIdNe5fdz0dlV9m2NUGOnw6vNcsdmLQh65wJVOuvrV4nz1aGG/juwFl19bsNejhTTEJKcN D5WT78uU2J4fnVyFbceqrk8fIrXNla26p8z5qwt6fzCCBRIwggR7oAMCAQICBAcnYgIwDQYJKoZI hvcNAQEFBQAwdTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0dURSBDb3Jwb3JhdGlvbjEnMCUGA1UE CxMeR1RFIEN5YmVyVHJ1c3QgU29sdXRpb25zLCBJbmMuMSMwIQYDVQQDExpHVEUgQ3liZXJUcnVz dCBHbG9iYWwgUm9vdDAeFw0xMDA0MTQxODEyMjZaFw0xODA0MTQxODEyMTRaMCcxJTAjBgNVBAMT HE1pY3Jvc29mdCBJbnRlcm5ldCBBdXRob3JpdHkwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC99M0npUrYkBnbsgp7YKROjw6Yo5x8UHbrs0qMnxiw55rFK4KGCSisERIyJvUZ6vC4Z2jF Bv30Ga7ZE6DQgScIpnmcBPVIMi42H6trJuyhQ7SdgLBJA+qCSV8FE8Wgg1/hKvQEGUt+yNqIvLVd A7x4VqHpf8Vq77b/HQFZtx9TWl/G+JFtxX1Dkxh0Re0VurJ8yDo0FB6qY/fl1EvIIyuHaZUTmQkU 73oBIE63xkhBrsmHASnZwoc4f7ZCpPCyzi39tExX8KjWy076X139ufsJ3BaFZOVxnNXxM5c4Zy6b vBc2BX4QNn9+65haWxytpecJEH35Si+zjzcV1m+5Wzfct59/jmZ/I1ztEn+MB/D+Gfm4NEN7suqF +4ypqt/9kQ0s9fuvl4nxBoqvSfY8LiP2RBYlkRHiI8PKhVVJKsghr30RJoawKEW6h+42E4HVS0ca jtsJ8dGXKVAUMpkJ4/LA51OPa/T6E1w8je5UmQ8nR048EvOPEhdG8IlqRbO1PAx3RQQvvb61npg8 BTu7QTmEILx5BNZCzT6J6ed6N0kQtMyfJFwjpkhu++PU7iEpk+T9gBobOmzB9+vZ1E2+8RH2oo5C JKFPabXSaBSJ2Z+Q2B+eG+ZtZCUptjRDpFv1Det0Bn6f8WPcRad8Oppca3PYw1gEjohvE9Dm0N/N xAoOBwIDAQABo4IBdzCCAXMwEgYDVR0TAQH/BAgwBgEB/wIBATBbBgNVHSAEVDBSMEgGCSsGAQQB sT4BADA7MDkGCCsGAQUFBwIBFi1odHRwOi8vY3liZXJ0cnVzdC5vbW5pcm9vdC5jb20vcmVwb3Np dG9yeS5jZm0wBgYEVR0gADAOBgNVHQ8BAf8EBAMCAYYwgYkGA1UdIwSBgTB/oXmkdzB1MQswCQYD VQQGEwJVUzEYMBYGA1UEChMPR1RFIENvcnBvcmF0aW9uMScwJQYDVQQLEx5HVEUgQ3liZXJUcnVz dCBTb2x1dGlvbnMsIEluYy4xIzAhBgNVBAMTGkdURSBDeWJlclRydXN0IEdsb2JhbCBSb290ggIB pTBFBgNVHR8EPjA8MDqgOKA2hjRodHRwOi8vd3d3LnB1YmxpYy10cnVzdC5jb20vY2dpLWJpbi9D UkwvMjAxOC9jZHAuY3JsMB0GA1UdDgQWBBQzIfDL/qKgRJLe9jsz2F8BS5d4XTANBgkqhkiG9w0B AQUFAAOBgQArSPOU+0TFk2rWTf60E04SJhfKslqrCblWpG9/V55ksvXk0zXvY2XL5SwVnO/O+CrF kmQrST48Nmy9GJtkZ5c/7WjQFsETPPJRoFfeJM41q2mQTisMOvm08YD6bQB5pjqWmU46blTQo1lu ix2VSbuV2HW44RIzrFwnu8tVcdX67TCCBZUwggR9oAMCAQICChK+XXoAAQAABaIwDQYJKoZIhvcN AQEFBQAwfDETMBEGCgmSJomT8ixkARkWA2NvbTEZMBcGCgmSJomT8ixkARkWCW1pY3Jvc29mdDEU MBIGCgmSJomT8ixkARkWBGNvcnAxFTATBgoJkiaJk/IsZAEZFgVudGRldjEdMBsGA1UEAxMUTVNJ VCBFbmNyeXB0aW9uIENBIDEwHhcNMTIwNzI0MjI0MzM2WhcNMTQwNDE1MjE0NDUyWjAZMRcwFQYD VQQDEw5UcmV2b3IgRnJlZW1hbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO4PyeEY XCI01CHZwt8dz4oLo/Uds4vEV80t8IXEdfy8i4srT4lde6GBYVQU5fv1Iso8PWxv37YS1O/QESYr 1gnWvKFNiXGnD49n19PIAJiSKlcMBE26PiSiagDpRzND3XkGJfO2NSfk/WjlX45iIuCA4gwe13mr nCWv72x4Mrb4fyBq+EkgrQBZG16l4xNiN+/zuBYe31vp2nTZHhlYdM2AVP1i+LgfXoM/iWJsXknt Rxec98WWphIAlTCri49Ssk0zlu81UZ11AUgL9hzC+Wg4JSdV482XifyKq7MGneg/G8AKKBBAL8LC 8gFR/EDpllv0O2SdeLealAqWOP2K6bsCAwEAAaOCAnowggJ2MB0GA1UdDgQWBBRDrNNAgbGzoErp JtgkVvtAdmnwxjAfBgNVHSMEGDAWgBTDYibfK4EByKZSkpvVULgsx5/ZITCB4gYDVR0fBIHaMIHX MIHUoIHRoIHOhjRodHRwOi8vY29ycHBraS9jcmwvTVNJVCUyMEVuY3J5cHRpb24lMjBDQSUyMDEo MSkuY3JshktodHRwOi8vbXNjcmwubWljcm9zb2Z0LmNvbS9wa2kvbXNjb3JwL2NybC9NU0lUJTIw RW5jcnlwdGlvbiUyMENBJTIwMSgxKS5jcmyGSWh0dHA6Ly9jcmwubWljcm9zb2Z0LmNvbS9wa2kv bXNjb3JwL2NybC9NU0lUJTIwRW5jcnlwdGlvbiUyMENBJTIwMSgxKS5jcmwwgaUGCCsGAQUFBwEB BIGYMIGVMEAGCCsGAQUFBzAChjRodHRwOi8vY29ycHBraS9haWEvTVNJVCUyMEVuY3J5cHRpb24l MjBDQSUyMDEoMSkuY3J0MFEGCCsGAQUFBzAChkVodHRwOi8vd3d3Lm1pY3Jvc29mdC5jb20vcGtp L21zY29ycC9NU0lUJTIwRW5jcnlwdGlvbiUyMENBJTIwMSgxKS5jcnQwCwYDVR0PBAQDAgeAMD0G CSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIa5iBSG8o4hh52VHIX3gmTXpm+BeoGV0RWB+7AoAgFk AgEOMBMGA1UdJQQMMAoGCCsGAQUFBwMEMBsGCSsGAQQBgjcVCgQOMAwwCgYIKwYBBQUHAwQwKQYD VR0RBCIwIIEedHJldm9yZkBleGNoYW5nZS5taWNyb3NvZnQuY29tMA0GCSqGSIb3DQEBBQUAA4IB AQCqhXv/xRRSJQFg4vzODGeybh2lnnRnzTTkiPYQIJ9fq+lz+mcrZ0IHu3ZG3J0JRRe1JpMnLAaH zTdIUsTPuB7QxfmVY8SnQlAm78wS6hyzBXuyJ73rDAX8tuXAXEsttQw0sL5U1E1EXRlkXXz/I7eM 8skthY/jq5+zlPGBSo+JehwZdy9+dePGzbI1gkuDMoBxkWLMxSQVMLMojx2sCVReqdvLH2BppXIo yjQjHODhnOIgd4GATmEDvjgOO7kzWiA2eTPUuvXJTigGWacAyAFZorHBd/ja8UWV1q0OKTuztr9B PEiq/6HZELeAynmIUp8lcCsMZ8tYHPwtL1p3duIYMIIF2zCCBMOgAwIBAgIKEr5OnAABAAAFoTAN BgkqhkiG9w0BAQUFADB8MRMwEQYKCZImiZPyLGQBGRYDY29tMRkwFwYKCZImiZPyLGQBGRYJbWlj cm9zb2Z0MRQwEgYKCZImiZPyLGQBGRYEY29ycDEVMBMGCgmSJomT8ixkARkWBW50ZGV2MR0wGwYD VQQDExRNU0lUIEVuY3J5cHRpb24gQ0EgMTAeFw0xMjA3MjQyMjQzMjhaFw0xNDA0MTUyMTQ0NTJa MBkxFzAVBgNVBAMTDlRyZXZvciBGcmVlbWFuMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEApv8oMoz9oD9Mh+stEb2R60JZaT4N/GrfIdNpMYQDHxA+OR2rh3C4DOxa/d9lSQ/a1qfOI1eM /fhcn5b/5F4dH2J66B7cVCwXc3Npbqq2MJl/6FV/MTeYIsGzi9oW/7MF4xbsLGhH+WsCDwbN5rz2 0LE8zVw2mOFMQPn2FwRbaaevXm6v/SOuoB5+0e/3+j8dm+kE1omahZbm001dWXzZrfMGhz6LxeVR B/dkPGedxuWNT+9Pjal2Pi0Cd+t2kVax/2Vxe6WoueLtg3o1Fy1YvvBGe3u6auLa7H3XoqkK+nBn tA1/J/9egQ4lKTl0zBx7rzW+bSqt0+xNnjfM5hZtzwIDAQABo4ICwDCCArwwHQYDVR0OBBYEFIYT avF2MbX5tWxatr7b389CazglMB8GA1UdIwQYMBaAFMNiJt8rgQHIplKSm9VQuCzHn9khMIHiBgNV HR8EgdowgdcwgdSggdGggc6GNGh0dHA6Ly9jb3JwcGtpL2NybC9NU0lUJTIwRW5jcnlwdGlvbiUy MENBJTIwMSgxKS5jcmyGS2h0dHA6Ly9tc2NybC5taWNyb3NvZnQuY29tL3BraS9tc2NvcnAvY3Js L01TSVQlMjBFbmNyeXB0aW9uJTIwQ0ElMjAxKDEpLmNybIZJaHR0cDovL2NybC5taWNyb3NvZnQu Y29tL3BraS9tc2NvcnAvY3JsL01TSVQlMjBFbmNyeXB0aW9uJTIwQ0ElMjAxKDEpLmNybDCBpQYI KwYBBQUHAQEEgZgwgZUwQAYIKwYBBQUHMAKGNGh0dHA6Ly9jb3JwcGtpL2FpYS9NU0lUJTIwRW5j cnlwdGlvbiUyMENBJTIwMSgxKS5jcnQwUQYIKwYBBQUHMAKGRWh0dHA6Ly93d3cubWljcm9zb2Z0 LmNvbS9wa2kvbXNjb3JwL01TSVQlMjBFbmNyeXB0aW9uJTIwQ0ElMjAxKDEpLmNydDALBgNVHQ8E BAMCBSAwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIhrmIFIbyjiGHnZUchfeCZNemb4F6hMrM AYGphFoCAWQCAQ8wEwYDVR0lBAwwCgYIKwYBBQUHAwQwGwYJKwYBBAGCNxUKBA4wDDAKBggrBgEF BQcDBDApBgNVHREEIjAggR50cmV2b3JmQGV4Y2hhbmdlLm1pY3Jvc29mdC5jb20wRAYJKoZIhvcN AQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCAMAcGBSsOAwIHMAoGCCqGSIb3 DQMHMA0GCSqGSIb3DQEBBQUAA4IBAQCQDZduOSYszA6jdwWJ2wREy9krW+XRGv3Ssh9+JQTGcnvs 1h+z1fiqognT24RweHCxbZWpRX88Lk6uyWDL/22L7F+UfjT/6D+i8GcrrLYrKWajxlyloUEKRWQt peVZuNQ+yzxQQ+a5cffz7njAT+Opl0OcwMFEG4XybdrpgRlasX17Nz3DcIaqs8ajLZYaEaqa3Egp W1z2Dt288RSILcHgh2mAmtD8/p6utnAZncSS71hOX1TZ0l+Jssh+JS0zCn8WQI0QP08oXT9HyYPq mmZK7fiatU6/qbOBnoFIHZIJUQzH4rqK0/nSodo1SRfq3tisigNPuL4MXK/XnVzgHo35MIIGAzCC A+ugAwIBAgIKYU1cMwAFAAAAKzANBgkqhkiG9w0BAQUFADAnMSUwIwYDVQQDExxNaWNyb3NvZnQg SW50ZXJuZXQgQXV0aG9yaXR5MB4XDTEwMDQxNTIxMzQ1MloXDTE0MDQxNTIxNDQ1MlowfDETMBEG CgmSJomT8ixkARkWA2NvbTEZMBcGCgmSJomT8ixkARkWCW1pY3Jvc29mdDEUMBIGCgmSJomT8ixk ARkWBGNvcnAxFTATBgoJkiaJk/IsZAEZFgVudGRldjEdMBsGA1UEAxMUTVNJVCBFbmNyeXB0aW9u IENBIDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDH8T1WatAwkKNGVviulnV/VdP1 qWIuoOhXC03D9B74MJ9+UnhWudFLC+oa8VTXiApOmOeLz+6NaUEunSiNSpiiWPkIL1TGoQmL0cqs X8kcaJPPnmuUHSzllQ2b/7BBMwsIhF9Fp86PBUaPYeEv5hCCem7VGhk/Ktp3X8gyKvFHlZe56/jV zH2nJi8SS6vxHQ+4064cj026uvhyzW4STPc2t6iJ4FlzizrkraM+HnWtRWVY9Y0aJCN1qDonkZ5n rUXdVKdZ6hWC4qPzyXU1GUMW3k1j3K0P+zuz9L24CjUwueoJsZGWJ/ukJMeP9J74GIsyi0U5G1sU 7MS1tWympa8NAgMBAAGjggHaMIIB1jASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBTDYibf K4EByKZSkpvVULgsx5/ZITALBgNVHQ8EBAMCAYYwEgYJKwYBBAGCNxUBBAUCAwEAATAjBgkrBgEE AYI3FQIEFgQUj8hIX+kBpe2CZxH0b3lqDktDMH0wGQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEw HwYDVR0jBBgwFoAUMyHwy/6ioESS3vY7M9hfAUuXeF0wgaMGA1UdHwSBmzCBmDCBlaCBkqCBj4Y2 aHR0cDovL21zY3JsLm1pY3Jvc29mdC5jb20vcGtpL21zY29ycC9jcmwvbXN3d3coNSkuY3JshjRo dHRwOi8vY3JsLm1pY3Jvc29mdC5jb20vcGtpL21zY29ycC9jcmwvbXN3d3coNSkuY3Jshh9odHRw Oi8vY29ycHBraS9jcmwvbXN3d3coNSkuY3JsMHkGCCsGAQUFBwEBBG0wazA8BggrBgEFBQcwAoYw aHR0cDovL3d3dy5taWNyb3NvZnQuY29tL3BraS9tc2NvcnAvbXN3d3coNSkuY3J0MCsGCCsGAQUF BzAChh9odHRwOi8vY29ycHBraS9haWEvbXN3d3coNSkuY3J0MA0GCSqGSIb3DQEBBQUAA4ICAQCI lydcfUMA82UII/BXQH0NOZli0ebIFj2P4ZHXTTAysCODdS5w0QhT3R54nS5AKa9cQU4ly20UlgWj Jo04mhPt6DHz8USuVrL4eMRXItpk/oUG25py1HnnK0dY7RLkYDn+UKr1UA0FAKkTCFQM20/C2HVq 91xZMn2e2IRfBalozRDgxOa64yf3yghmeJnVyi80h0zNmBOOoTgedf4tgbi3WzrfFgKoJuL4Tllf pBr4OBgO7AOHVDaqK6PWGGJ6KEruTJB1pCvP6LhYirGRvZ6FzF/GZi3oCA700jstOAmJ0jdN8Rnw VUKFz9UGy8QCOq5qh9pdxB/W/YXhF6KkmV1mX5UyzQoIMjtz9wps1M1RLaxccfBBh50ACQ+0tLMr SXHwhhu8K2wxXTQfxTigwvXhNrlcafPrTdqM/MXPmD9RaSaLJBlcsTDjUtQ4AUWg3mJP6G4xu8rg RjaGjDE6b9XnYL/i5YzI36uj0dV3hc5rW2GEurYF6Qw/M2EjP47ENHhN7UxYWww9Bp5ktrOMdEU3 jLcbWP5JichQr3CcXd+J6sIkPhQYpuvuZ3Q3Z8O9/TsZTA7jsH3YAvjQwTtTYMCXB9dLQ/BD9ALl iDpWT5kQsBn2pR9gbQPMN7vsLEv1DUvJZyveIj2SxxYOLZ9S3qol5Qt3n7fTtoavlVTyNBRyfjGC A/8wggP7AgEBMIGKMHwxEzARBgoJkiaJk/IsZAEZFgNjb20xGTAXBgoJkiaJk/IsZAEZFgltaWNy b3NvZnQxFDASBgoJkiaJk/IsZAEZFgRjb3JwMRUwEwYKCZImiZPyLGQBGRYFbnRkZXYxHTAbBgNV BAMTFE1TSVQgRW5jcnlwdGlvbiBDQSAxAgoSvl16AAEAAAWiMAkGBSsOAwIaBQCgggJJMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDgyNDE2MjMxMFowIwYJKoZI hvcNAQkEMRYEFNIxKZNhZ33i8O3JBIv7z+mWfwZLMIGbBgkrBgEEAYI3EAQxgY0wgYowfDETMBEG CgmSJomT8ixkARkWA2NvbTEZMBcGCgmSJomT8ixkARkWCW1pY3Jvc29mdDEUMBIGCgmSJomT8ixk ARkWBGNvcnAxFTATBgoJkiaJk/IsZAEZFgVudGRldjEdMBsGA1UEAxMUTVNJVCBFbmNyeXB0aW9u IENBIDECChK+TpwAAQAABaEwgZ0GCyqGSIb3DQEJEAILMYGNoIGKMHwxEzARBgoJkiaJk/IsZAEZ FgNjb20xGTAXBgoJkiaJk/IsZAEZFgltaWNyb3NvZnQxFDASBgoJkiaJk/IsZAEZFgRjb3JwMRUw EwYKCZImiZPyLGQBGRYFbnRkZXYxHTAbBgNVBAMTFE1TSVQgRW5jcnlwdGlvbiBDQSAxAgoSvk6c AAEAAAWhMIGrBgkqhkiG9w0BCQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgFAMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJ YIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAFF1EVDoxn9DSrLrULcoqtd3ubmXoiWVmwpm8/Ty QARXDfT9UVyTZAKxGf1lhzXvX8cPjHxjP2B7GwO2o6V2RG642tqVkDnjU6O9qJDxwibsvUiT9KRX IoNTwT4MAQbUSpEusR1JiewuFl2pfGiRtbZ63GL7ClG/fLD/j6mfLM50BpOalW/ZtpcQ21i81lDM ow4viBTExv+0Enb8H0+d/AqToK5NxVaxOCuueisS6y6BXG9SdeSb9fNIHlUtOQQcnXbE2WocJoKQ UjLvgjlLTzDwEHVioaCE+aEuLpqN+SvxKPbaW7xVq7x37yWKO11na4pJloyVzg5sFjXQ+W9kQqoA AAAAAAA= ------=_NextPart_000_0012_01CD81DA.142FC120-- From ietf@augustcellars.com Tue Aug 28 20:40:14 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 E70C111E8097 for ; Tue, 28 Aug 2012 20:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=-0.847, BAYES_20=-0.74, 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 QcUuavw5UkHW for ; Tue, 28 Aug 2012 20:40:14 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 70E8821F841A for ; Tue, 28 Aug 2012 20:40:14 -0700 (PDT) Received: from Tobias (50-39-234-129.bvtn.or.frontiernet.net [50.39.234.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id CDAC72CA17 for ; Tue, 28 Aug 2012 20:40:13 -0700 (PDT) From: "Jim Schaad" To: Date: Tue, 28 Aug 2012 20:38:50 -0700 Message-ID: <05f601cd8597$d068afd0$713a0f70$@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: Ac2FLbUA1yGfuss0T4Ghfxr+B2Fy1Q== Content-Language: en-us Subject: [plasma] Use of the KEK Recipient Info field 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: Wed, 29 Aug 2012 03:40:15 -0000 At the last IETF meeting Trevor and I decided that we really needed to send the CEK rather than the KEK between the client and the server to support pre-authorization cases. This has one effect that I would like some input on. We currently use the KEK Recipient Info structure and define an Other Attribute to hold the Plasma data. We then have a KEK and a KEK Wrap algorithm to protect the CEK. Moving forward I see three ways of doing the wrapping. 1. Promote the current Other Attribute to a Key Wrap algorithm. We no longer have an Other Attribute but instead identify Plasma by the key wrap algorithm OID and the wrapped key value is the Plasma lockbox data structure. 2. We define and use a dummy Key Wrap algorithm and empty key value field. This keeps the current Other Attribute field, but since we don't' use the key wrap algorithm and key value fields they become dummy values. 3. The Plasma server will randomly generate a KEK value and wrap the CEK with the KEK and provide the data in the KEK recipient Info structure. The server then receives the CEK and returns either the CEK or the KEK as we decide is appropriate. I don't have a strong feeling for any of the above solutions and therefore request input and reasoning behind a selection process. Jim