Subject: Re: [plasma] Basic and Advanced Policies

From: Trevor Freeman <[email-masked]>
Date: Tue, 14 Aug 2012 18:25:30 +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 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: [email-masked] [mailto:[email-masked]] On Behalf Of Skedd, Richard (UK)
Sent: Friday, July 27, 2012 2:35 AM
To: [email-masked]
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: [email-masked] [mailto:[email-masked]] On Behalf Of Patrick Patterson
Sent: 25 July 2012 16:08
To: Jean-Paul Buu-Sao
Cc: [email-masked]
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: [email-masked]<mailto:[email-masked]>
[mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Jean-Paul Buu-Sao
Sent: Monday, July 23, 2012 1:25 AM
To: [email-masked]<mailto:[email-masked]>
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 <<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
[email-masked]
https://www.ietf.org/mailman/listinfo/plasma

---

From: "Skedd, Richard (UK)" <[email-masked]>
Date: Wed, 15 Aug 2012 17:02:21 +0000

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
>= 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
 
BAE Systems plc
Registered Office: 6 Carlton Gardens, London, SW1Y 5AD, UK
Registered in England & Wales No: 1470151

-----Original Message-----
From: Trevor Freeman [mailto:[email-masked]] 
Sent: 14 August 2012 19:26
To: Skedd, Richard (UK); [email-masked]
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] 

[email-masked] [mailto:[email-masked]] On Behalf Of Skedd,
Richard (UK)
Sent: Friday, July 27, 2012 2:35 AM
To: [email-masked]
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

BAE Systems plc
Registered Office: 6 Carlton Gardens, London, SW1Y 5AD, UK Registered in
England & Wales No: 1470151

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Patrick Patterson
Sent: 25 July 2012 16:08
To: Jean-Paul Buu-Sao
Cc: [email-masked]
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,

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.

More inline below

Trevor

-----Original Message-----
From: [email-masked]<mailto:[email-masked]>
[mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On
Behalf Of Jean-Paul Buu-Sao
Sent: Monday, July 23, 2012 1:25 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [plasma] Comments on Message Access Control Requirements Draft

Greetings,

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.

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.

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.

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.

[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.

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

tel: +1 514 485 0789
mobile: +1 514 994 8699
fax: +1 450 424 9559