Re: [plasma] Clarification of how client applications handle the LockBox in client in <plasma:GetCMSToken> elements

"Jim Schaad" <> Tue, 25 September 2012 20:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B6D1021F87CA for <>; Tue, 25 Sep 2012 13:35:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qYN63Ayh4rVG for <>; Tue, 25 Sep 2012 13:35:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1BE8D21F86A0 for <>; Tue, 25 Sep 2012 13:35:26 -0700 (PDT)
Received: from Tobias ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 524B62CA25; Tue, 25 Sep 2012 13:35:26 -0700 (PDT)
From: Jim Schaad <>
To: 'Ed Simon' <>,
References: <DCD8C7A5A8B3E844AA2E2CBE327CDC9201329321@E10MB3.tituscorp.local>
In-Reply-To: <DCD8C7A5A8B3E844AA2E2CBE327CDC9201329321@E10MB3.tituscorp.local>
Date: Tue, 25 Sep 2012 13:33:54 -0700
Message-ID: <010b01cd9b5d$19d92f20$4d8b8d60$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHbD/DyIY7qmbcdstkCO3B4OhQ3jpeAmgKg
Content-Language: en-us
Subject: Re: [plasma] Clarification of how client applications handle the LockBox in client in <plasma:GetCMSToken> elements
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, 25 Sep 2012 20:35:27 -0000

I apologize for the delay, I have been doing more traveling than I expected.

Would the following text make things clearer?

When sending a Plasma enabled message, there are three different classes of
recipients that need to be considered.  The information sent for these three
classes differs.  The three classes are:

1.  No Policy Protection - These recipients are those for which no Plasma
policy protection is to be applied.  Often times the sender of the message
will fall into this class of recipient.  For recipients in this class the
Plasma server is not involved, the sender creates a lock box as if the
Plasma server was not present and places the lock box in to the recipient
info structure as normal.

2.  Policy protected for a specific recipient - This case exists to allow a
message to be policy protected, but also not allow the policy server to any
access to the message.  For recipients of this class access can be denied to
existing recipients by the Plasma server, but new recipients cannot be added
to the list.  For recipients in this class, the sender agent builds a normal
recipient info structure for the recipient, but instead of placing it in the
message direct, it is given to the Plasma server along with the policy to be
satisfied before the lock box is released to the recipient.  The Plasma
server includes  this recipient inside of the Plasma lock box which is
returned to the sender for inclusion in the recipient info structure.  

3.  Policy Protected generic recipient - These recipients are those for
which the inclusion in the group of individuals able to decrypt the message
is based solely on the policy.  For these recipients, the sender supplies
the Plasma server with the policy to be applied for inclusion as a recipient
and the content encryption key.  The server then returns this information in
it's Plasma encrypted lock box for inclusion in the  recipient info
structure.  This recipient class must be used if a server is going to do
pre-approval of recipients as described in section XXX of [Requirements].

> -----Original Message-----
> From: [] On
> Behalf Of Ed Simon
> Sent: Thursday, September 13, 2012 6:12 PM
> To:
> Subject: [plasma] Clarification of how client applications handle the
> in client in <plasma:GetCMSToken> elements
> I would like to see the clarification of how client applications handle
> LockBox. In section 8.1.1 of Plasma Service Trust Processing, which
> the XML request created by the client which is sent to the server prior to
> creating the email's CMS form, it states that the LockBox is a "base64
> encoded Recipient Info structure", but in section 3, Encoding Recipient
> of Plasma Service CMS Processing (the only place I see a sufficiently
> description of encoding PLASMA RecipientInfo structures), it says "A
> recipient info structure as defined in this document MUST be created by a
> Plasma server and MUST NOT be created by client software". I can see the
> latter making sense in RecipientInfo structures returned by the server to
> client, but not in the client request for the CMS token. The question
> then what is supposed to go into the LockBox in the sending client's CMS
> token XML request.
> If it is the PLASMA-LockBox ASN.1 structure described in section 3.2 of
> Plasma Service CMS Processing, then more clarity is needed as to exactly
> what the client should send to the PLASMA server in a CMS token request
> (e.g. is it everything but the RecipientInfo blob in the PLASMA-LockBox
> structure?, if labels and recipient names are already specified in XML in
> CMS token request, does/should the client really need to create label and
> NamedRecipient structures in the PLASMA-LockBox? (I suspect not)).
> Ed
> _______________________________________________
> plasma mailing list