Trevor Freeman | 30 Apr 01:06 2014
Picon

[plasma] FW: Plasma draft review

I have received this feedback from Peter on the requirements draft.

 

If someone else was thinking of also providing feedback, now would be a good time while I am processing Peters feedback.

 

Thanks

Trevor

 

From: Peter Yee [mailto:peter <at> akayla.com]
Sent: Monday, April 28, 2014 12:19 AM
To: Trevor Freeman
Subject: RE: Plasma draft review

 

Trevor,

                Done.  Review attached.  Please let me know if you have any questions.  Better than last time, but do consider my questions and positions found in the comments.

 

                                                                -Peter

 

From: Trevor Freeman [mailto:trevorf <at> exchange.microsoft.com]
Sent: Thursday, April 17, 2014 9:24 AM
To: Peter Yee (peter <at> akayla.com)
Subject: Plasma draft review

 

Hi Peter,

 

Any idea when you will have finished reviewing the 09 plasma draft?

 

Thanks

Trevor

Attachment (draft-freeman-plasma-requirements-09.docx): application/vnd.openxmlformats-officedocument.wordprocessingml.document, 141 KiB
<div>
<div class="WordSection1">
<p class="MsoNormal"><span>I have received this feedback from Peter on the requirements draft.<p></p></span></p>
<p class="MsoNormal"><span><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span>If someone else was thinking of also providing feedback, now would be a good time while I am processing Peters feedback.<p></p></span></p>
<p class="MsoNormal"><span><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span>Thanks<p></p></span></p>
<p class="MsoNormal"><span>Trevor<p></p></span></p>
<p class="MsoNormal"><span><p>&nbsp;</p></span></p>
<div>
<div>
<p class="MsoNormal">From: Peter Yee [mailto:peter <at> akayla.com] <br>Sent: Monday, April 28, 2014 12:19 AM<br>To: Trevor Freeman<br>Subject: RE: Plasma draft review<p></p></p>
</div>
</div>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal"><span>Trevor,<p></p></span></p>
<p class="MsoNormal"><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Done.&nbsp; Review attached.&nbsp; Please let me know if you have any questions.&nbsp; Better than last time, but do consider my questions and positions found in the comments.<p></p></span></p>
<p class="MsoNormal"><span><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -Peter<p></p></span></p>
<p class="MsoNormal"><span><p>&nbsp;</p></span></p>
<div>
<div>
<p class="MsoNormal"><span>From:</span><span> Trevor Freeman [<a href="mailto:trevorf <at> exchange.microsoft.com">mailto:trevorf <at> exchange.microsoft.com</a>]
<br>Sent: Thursday, April 17, 2014 9:24 AM<br>To: Peter Yee (<a href="mailto:peter <at> akayla.com">peter <at> akayla.com</a>)<br>Subject: Plasma draft review<p></p></span></p>
</div>
</div>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">Hi Peter,<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">Any idea when you will have finished reviewing the 09 plasma draft?<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">Thanks<p></p></p>
<p class="MsoNormal">Trevor<p></p></p>
</div>
</div>
Trevor Freeman | 13 Feb 22:16 2014
Picon

[plasma] FW: New Version Notification for draft-freeman-plasma-requirements-09.txt

FYI, new requirements draft published

-----Original Message-----
From: internet-drafts <at> ietf.org [mailto:internet-drafts <at> ietf.org] 
Sent: Thursday, February 13, 2014 1:14 PM
To: Patrick Patterson; Trevor Freeman; Jim Schaad; Jim Schaad; Patrick Patterson; Trevor Freeman
Subject: New Version Notification for draft-freeman-plasma-requirements-09.txt

A new version of I-D, draft-freeman-plasma-requirements-09.txt
has been successfully submitted by Trevor Freeman and posted to the IETF repository.

Name:		draft-freeman-plasma-requirements
Revision:	09
Title:		Requirements for Message Access Control
Document date:	2014-02-13
Group:		Individual Submission
Pages:		47
URL:            http://www.ietf.org/internet-drafts/draft-freeman-plasma-requirements-09.txt
Status:         https://datatracker.ietf.org/doc/draft-freeman-plasma-requirements/
Htmlized:       http://tools.ietf.org/html/draft-freeman-plasma-requirements-09
Diff:           http://www.ietf.org/rfcdiff?url2=draft-freeman-plasma-requirements-09

Abstract:
  S/MIME has a proven track record in delving confidentiality, integrity
  and data origination authentication for email. However, there are many
  situations where organizations want robust access control applied to
  information in messages. The Enhanced Security Services (ESS) RFC5035
  for S/MIME defines an access control mechanism for email, but the
  access check happens after the data is decrypted by the recipient
  which devalues the protection afforded by the cryptography and
  provides very week guarantees of policy compliance. Another major
  issues for S/MIME is its dependency on a single type of identity
  credential, an X.509 certificate. Many users on the Internet today do
  not have X.509 certificates and therefore cannot use S/MIME.
  Furthermore, the requirement to discover the X.509 certificate for
  every recipient of an encrypted message by the sender has proven to be
  an unreliable process for a number of reasons.

  This document presents requirements for an alternative model to ESS to
  address the identified issues with access control to deliver more
  robust compliance with S/MIME protected messages. This document
  describes an access control model which uses cryptographic keys to
  enforce access control policy decisions where the policy check is
  performed prior to the decryption of the message contents. The model
  also abstracts the specifics of the authentication technology thereby
  removing the dependency on X.509 certificate making it possible for
  other forms of credential to be used for S/MIME enabling much broader
  adoption. This model can be instantiated in many areas using existing
  standards, or with only minor updates to existing standards. This
  model in not intended to be a one off just for email and can also be
  applied to other data types. The model also removes the dependency on
  the need to discover encryption certificates at send time.

  The name Plasma was assigned to this effort as part of the IETF
  process. It is derived from PoLicy enhAnced Secure eMAil.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and
diff are available at tools.ietf.org.

The IETF Secretariat

Button, Dave | 22 Nov 22:15 2013

[plasma] (no subject)

 

 

This message and/or attachments may include information subject to GDC4S S.P. 1.8.6 and GD Corporate Policy 07-105 and is intended to be accessed only by authorized recipients.  Use, storage and transmission are governed by General Dynamics and its policies.  Contractual restrictions apply to third parties.  Recipients should refer to the policies or contract to determine proper handling.  Unauthorized review, use, disclosure or distribution is prohibited.  If you are not an intended recipient, please contact the sender and destroy all copies of the original message.

 

<div>
<div class="WordSection1">
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal"><span>This message and/or attachments may include information subject to GDC4S S.P. 1.8.6 and GD Corporate Policy 07-105 and is intended to be accessed only by authorized
 recipients.&nbsp; Use, storage and transmission are governed by General Dynamics and its policies.&nbsp; Contractual restrictions apply to third parties.&nbsp; Recipients should refer to the policies or contract to determine proper handling.&nbsp; Unauthorized review, use, disclosure
 or distribution is prohibited.&nbsp; If you are not an intended recipient, please contact the sender and destroy all copies of the original message.
<p></p></span></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
</div>
</div>

Re: [plasma] plasma Digest, Vol 25, Issue 1 attachments

I am unable to read the today's topic or the Digest Footer attachments. 

Diana Proud-Madruga, CISSP, GSEC
Security Analyst
Dynamic Research Corporation|High Performance Technology Group
(619) 467-5568 (Office)
dproud-madruga <at> drc.com 
diana.proud-madruga <at> va.gov

-----Original Message-----
From: plasma [mailto:plasma-bounces <at> ietf.org] On Behalf Of plasma-request <at> ietf.org
Sent: Friday, November 22, 2013 12:00 PM
To: plasma <at> ietf.org
Subject: plasma Digest, Vol 25, Issue 1

Send plasma mailing list submissions to
	plasma <at> ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/plasma
or, via email, send a message with subject or body 'help' to
	plasma-request <at> ietf.org

You can reach the person managing the list at
	plasma-owner <at> ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of plasma digest..."
Carl Wallace | 21 Nov 23:21 2013

[plasma] draft-freeman-plasma-requirements-08

After IETF 88 I read this document for this first time.  Below are some
comments. 

General

- The document is too long.  The use cases seem unnecessary to support the
primary (?) motivation - i.e., ESS security labels don't work as desired.

- Should state early in the document whether or not use of S/MIME (i.e.,
CMS) is a requirement or if the aim is to do something different (first
bullet in 5.2 asserts backwards compatibility but is pretty far into the
document and section 5.2 is a bit fuzzy).

- For a document that asserts an email focus up front, there is too much
focus on SAML/XACML concepts.  An email focus for the document might be to
reference a new recipient info type that points to a key server (and maybe
a signed attribute for instructions to key server too).  While the
document sets the table with ESS labels as the objection, it seems like
the real objection is premature release of CEKs relative to access control
decisions (which doesn't necessarily have anything to do with labels).
With a different orientation, most of the work would then be in the
definition of the key server interface (including formats, like a
RecipientInfo lockbox) and key server operations, where the SAML/XACML
material would probably fit more naturally.

Comments
- The vocabulary section seems misplaced on a first read through.  It
would benefit from some text in the introductory section that alludes to
the proposed architecture, or at least describes some of the SAML/XACML
concepts that appear in the vocabulary section.
- In section 2.1, bullet 7 applies more to S/MIME than ESS security
labels.	
- The last paragraph in section 2.2 would benefit from some connection to
S/MIME, i.e., describe how a S/MIME sender benefits from delegating
authentication of a recipient to a SAML attribute provider who uses
username/password for authentication.
- Why is section 2.3 necessary?
- I would break section 2 into two parts: one part would provide
background on things like SAML.  The other would catalog problems with
current mechanisms.  Sections 2.1 and 2.5 would fall in the latter part.
It's not altogether clear why the other sections are necessary in a
document generating requirements for improved email access control
mechanisms.  
- Requirements should be organized around functions, perhaps: sender
generation/release of email and keys, intermediary receipt/storage/release
of email and keys, recipient acquisition of email and key, attribute
generation/aggregation/storage/release, access control policy
definition/storage/evaluation/versioning/expiry.
- The last paragraph in section 3.2.1 is not clear.  Why would Bob's use
of the same username/password attest to his identity in an email he sends
in response to a message from the bank?  Is this suggesting he
authenticates to some key server interface to obtain a new signature key
and that attests to his identity?
- Section 3.3 seems like a bit of a stretch as a requirement given Dave
could simply copy and paste mail into a new thread.
- Section 3.4.1 refers to a curious concept: "finding all instances of the
data".  How would any access control mechanism account apply policies to
data already released?  This section notes that Frank labels an email with
Project X and Company Foo's IP labels.  How would a recipient know which
label applied to which portions of the email?  This section concludes with
the idea that Grace can no longer access Program X mail.  It should
probably more simply state that she can no longer retrieve CEKs for
Program X mail from the server.  She may well have access to Program X
mail through a local copy.  Generally this section is confusing and seems
likely to render email threads very difficult to manage as multiple labels
are applied that all parties may not be able to access.  How would labels
be removed if one were to forward a message or reply to a message while
including only the part associated with one of the labels?
- In 3.4.2, where is Grace's signature generated, i.e., by Grace or by the
server?  Item (f) is difficult to parse.  Some explanation as to how one
can be required by policy to confirm compliance with policy without
knowing the specifics of the policy would be helpful.  This section
asserts a requirement to support exchange of forms that does not seem to
appear elsewhere in the document.  These sections appear to address
web-based access to a workflow more than secure email.
- Section 3.5 describes (more or less) how anyone with same attributes as
Grace can access email sent to Grace.  Is there a requirement for Frank to
be able to send email to Grace such that only Grace can access it?  What
prevents Brian from obtaining the key even if Grace is not away and did
not forward the message?
- Section 3.6 (like several other sections) asserts a requirement for
recipient's to be able to confirm the email is from a specific sender.  If
server-applied signatures are used, how does this work?  If user-applied
signatures are used doesn't this violate one of the primary aims of the
work, i.e., to support users who do not possess an S/MIME credential?
- How do you permit the mail server from leaking attributes to a sender
via failure notices?  For example, Alice sends various test messages to
Bob under different policies to determine which attributes are associated
with him.  
- In section 3.8, should inbound inspection also search for leakage to
unauthorized parties?
- Is there a requirement to enable a sender to be able to express a
specific version of a policy be used at enforcement time (vs some later
version)?
- Is there a requirement for communications partners to be able to
contribute attributes to others?  For example, Alice may associate some
attribute with Frank to allow him to participate in some exchange.
- Section 5.2 seems to reference the "basic policy" concept in conflicting
ways, i.e., as backwards compatible with current S/MIME practices and to
accomodate users with no certificate.

Some additional security considerations:
- Use of an authentication mechanism that can be reset via control of an
email account is problematic in support of an email access control tool.
- Granting access to different portions of an email message is similarly
weak as ESS labels given there is no cryptographic separation between
different groups of users accessing a single message.
- Is there any need to provide an indication that a key has already been
released to Bob or someone purporting to be Bob in the past?  For example,
in section 3.2.1.
- Need to discuss migration from one algorithm to another in the event an
algorithm is deemed no longer suitable.  What's the lifetime of
documents/keys held by a plasma server?

Some additional privacy considerations
- Moving the decryption capability to servers enables "pervasive
monitoring" in ways that end-to-end encryption does not.  Some discussion
of the trade off is warranted (including perhaps how it is not a
significant change due to escrow of encryption keys in current practice).
- Downloading keys allows for automated read receipt generation.  Is this
desirable?

Miscellaneous
- Given the references to SAML, XACML, etc., should KEYPROV be cited as a
key format spec to use?

Nits
- In section 2, change "without certificates" to "without valid
certificates".
- In section 2.1, bullet 6, s/enforce/enforced.
- In section 2.2, s/replying party/relying party. (multiple occurrences)
- In section 2.2, s/a mean/a means.
- In section 2.2, s/by to a subjects/to a subject's. (the sentence
containing this change is pretty difficult to parse in general)
- In section 2.2.1, s/subject's themselves/subjects themselves.
- In section 3.1, should this reference Alice's ISP or her email service
provider?
- In section 3.2.1, s/recipients identity/recipient's identity
- In section 3.4.1, s/confidentiality  its own/confidentiality of its own
- In section 3.4.2, s/Franks/Frank's
- In section 3.6 bullet (4), delete " : , then encrypts the message."

Trevor Freeman | 21 Oct 22:17 2013
Picon

[plasma] FW: New Version Notification for draft-freeman-plasma-requirements-08.txt

FYI, I have just posed draft 8 which contains the fixed from the last set of comments from the document
shepherd. 

Please review and send comments to me as I want to get this document to the IESG for publication. 

Thanks 

-----Original Message-----
From: internet-drafts <at> ietf.org [mailto:internet-drafts <at> ietf.org] 
Sent: Monday, October 21, 2013 1:13 PM
To: Patrick Patterson; Jim Schaad; Trevor Freeman
Subject: New Version Notification for draft-freeman-plasma-requirements-08.txt

A new version of I-D, draft-freeman-plasma-requirements-08.txt
has been successfully submitted by Trevor Freeman and posted to the IETF repository.

Filename:	 draft-freeman-plasma-requirements
Revision:	 08
Title:		 Requirements for Message Access Control
Creation date:	 2013-10-21
Group:		 Individual Submission
Number of pages: 62
URL:             http://www.ietf.org/internet-drafts/draft-freeman-plasma-requirements-08.txt
Status:          http://datatracker.ietf.org/doc/draft-freeman-plasma-requirements
Htmlized:        http://tools.ietf.org/html/draft-freeman-plasma-requirements-08
Diff:            http://www.ietf.org/rfcdiff?url2=draft-freeman-plasma-requirements-08

Abstract:
   There are many situations where organizations want to protect
   information with robust access control, either for implementation of
   intellectual property right protections, enforcement of contractual
   confidentiality agreements or because of legal regulations.  The
   Enhanced Security Services (ESS) for S/MIME defines an access control
   mechanism for email which is enforced by the recipient's client after
   decryption of the message. The ESS mechanism therefore is dependent
   on the correct access policy configuration of every recipient's
   client. This mechanism also provides full access to the data to all
   recipients prior to the access control check, which is considered to
   be inadequate for robust access control due to the difficulty in
   demonstrating policy compliance.

   This document lays out the deficiencies of the current ESS security
   label, and presents requirements for a new model for providing access
   control to messages where the access check is performed prior to
   message content decryption. This new model also does not require
   policy configuration on the client thereby simplifying deployment and
   compliance verification.

   The proposed model additionally provides a method where non-X.509
   certificate credentials can be used for encryption/decryption of
   S/MIME messages.

   The name Plasma was assigned to this effort as part of the IETF
   process. It is derived from PoLicy enhAnced Secure eMAil.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and
diff are available at tools.ietf.org.

The IETF Secretariat

Trevor Freeman | 20 Aug 23:18 2013
Picon

[plasma] FW: New Version Notification for draft-freeman-plasma-requirements-07.txt

FYI, a new requirements draft was just posted. This has the updates requested by the document shepherd. 

Final stretch now. 

Trevor

-----Original Message-----
From: internet-drafts <at> ietf.org [mailto:internet-drafts <at> ietf.org] 
Sent: Tuesday, August 20, 2013 2:05 PM
To: Patrick Patterson; Jim Schaad; Trevor Freeman
Subject: New Version Notification for draft-freeman-plasma-requirements-07.txt

A new version of I-D, draft-freeman-plasma-requirements-07.txt
has been successfully submitted by Trevor Freeman and posted to the IETF repository.

Filename:	 draft-freeman-plasma-requirements
Revision:	 07
Title:		 Requirements for Message Access Control
Creation date:	 2013-08-20
Group:		 Individual Submission
Number of pages: 60
URL:             http://www.ietf.org/internet-drafts/draft-freeman-plasma-requirements-07.txt
Status:          http://datatracker.ietf.org/doc/draft-freeman-plasma-requirements
Htmlized:        http://tools.ietf.org/html/draft-freeman-plasma-requirements-07
Diff:            http://www.ietf.org/rfcdiff?url2=draft-freeman-plasma-requirements-07

Abstract:
   There are many situations where organizations want to protect
   information with robust access control, either for implementation of
   intellectual property right protections, enforcement of contractual
   confidentiality agreements or because of legal regulations.  The
   Enhanced Security Services (ESS) for S/MIME defines an access control
   mechanism for email which is enforced by the recipient's client after
   decryption of the message. The ESS mechanism therefore is dependent
   on the correct access policy configuration of every recipient's
   client. This mechanism also provides full access to the data to all
   recipients prior to the access control check, which is considered to
   be inadequate for robust access control due to the difficulty in
   demonstrating policy compliance.

   This document lays out the deficiencies of the current ESS security
   label, and presents requirements for a new model for providing access
   control to messages where the access check is performed prior to
   message content decryption. This new model also does not require
   policy configuration on the client thereby simplifying deployment and
   compliance verification.

   The proposed model additionally provides a method where non-X.509
   certificate credentials can be used for encryption/decryption of
   S/MIME messages.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and
diff are available at tools.ietf.org.

The IETF Secretariat

Trevor Freeman | 12 Jun 23:29 2013
Picon

[plasma] FW: New Version Notification for draft-freeman-plasma-requirements-06.txt

More language and document nits fixed. 

Please review and send comments  as I want to declare this document finished ASAP. 

-----Original Message-----
From: internet-drafts <at> ietf.org [mailto:internet-drafts <at> ietf.org] 
Sent: Wednesday, June 12, 2013 2:27 PM
To: Patrick Patterson; Jim Schaad; Trevor Freeman
Subject: New Version Notification for draft-freeman-plasma-requirements-06.txt

A new version of I-D, draft-freeman-plasma-requirements-06.txt
has been successfully submitted by Trevor Freeman and posted to the IETF repository.

Filename:	 draft-freeman-plasma-requirements
Revision:	 06
Title:		 Requirements for Message Access Control
Creation date:	 2013-06-12
Group:		 Individual Submission
Number of pages: 57
URL:             http://www.ietf.org/internet-drafts/draft-freeman-plasma-requirements-06.txt
Status:          http://datatracker.ietf.org/doc/draft-freeman-plasma-requirements
Htmlized:        http://tools.ietf.org/html/draft-freeman-plasma-requirements-06
Diff:            http://www.ietf.org/rfcdiff?url2=draft-freeman-plasma-requirements-06

Abstract:
   There are many situations where organizations want to protect
   information with robust access control, either for implementation of
   intellectual property right protections, enforcement of contractual
   confidentiality agreements or because of legal regulations.  The
   Enhanced Security Services (ESS) for S/MIME defines an access control
   mechanism for email which is enforced by the recipient's client after
   decryption of the message. The ESS mechanism therefore is dependent
   on the correct access policy configuration of every recipient's
   client. This mechanism also provides full access to the data to all
   recipients prior to the access control check, this is considered to
   be inadequate due to the difficulty in demonstrating policy
   compliance.

   This document lays out the deficiencies of the current ESS security
   label, and presents requirements for a new model for providing access
   control to messages where the access check is performed prior to
   message content decryption. This new model also does not require
   policy configuration on the client to simplify deployment and
   compliance verification.

   The proposed model additionally provides a method where non-X.509
   certificate credentials can be used for encryption/decryption of
   S/MIME messages.

The IETF Secretariat

Trevor Freeman | 31 May 23:08 2013
Picon

[plasma] Wrapping up work on the Requirements draft

Hi Folks,

I am wrapping up work on the requirements draft. We need to move this along. Please let me have comments by 6/7.

 

Thanks

Trevor

<div>
<div class="WordSection1">
<p class="MsoNormal">Hi Folks,<p></p></p>
<p class="MsoNormal">I am wrapping up work on the requirements draft. We need to move this along. Please let me have comments by 6/7.<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">Thanks<p></p></p>
<p class="MsoNormal">Trevor<p></p></p>
</div>
</div>
Alan Borland | 15 Apr 11:20 2013

[plasma] <Recipient> in the GetCmsToken

<!-- <at> font-face {font-family:Calibri} p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif"} a:link, span.MsoHyperlink {color:blue; text-decoration:underline} a:visited, span.MsoHyperlinkFollowed {color:purple; text-decoration:underline} span.EmailStyle17 {font-family:"Calibri","sans-serif"; color:windowtext} .MsoChpDefault {font-family:"Calibri","sans-serif"} <at> page WordSection1 {margin:72.0pt 72.0pt 72.0pt 72.0pt} -->

[Boldon James classification: UNMARKED EXTERNAL]


Now we have our plasma client in demonstration form I performed some testing using an X.400 environment (STANAG 4406 to be precise).  The P772 encoded Plasma message was sent / received but I was denied access trying to read the message.  I tracked this down to the recipient I supplied in the GetCmsToken, rather than an SMTP address I have an X.400 O/R address, as below.

 

<Recipient>

    <Subject>s=ab51;o=borland5;p=boldonjames;a= ;c=gb</Subject>

</Recipient>

 

I think we need another attribute to specify the type of 'Subject' we have supplied, something similar to below?

 

<Recipient>

    <Subject type="x400">s=ab51;o=borland5;p=boldonjames;a= ;c=gb</Subject>

</Recipient>

 

Alan.

 

Alan Borland


Boldon James Limited, a QinetiQ company

Mobile:        +44 (0)7810 556709
Direct:         +44 (0)1270 507841
Switch:        +44 (0)1270 507800
Email:          alan.borland <at> boldonjames.com
Email (R):    abborland <at> qinetiq.r.mil.uk
Web:           www.boldonjames.com

 

 

 

 

 

<div>

&lt;!--
 <at> font-face
	{font-family:Calibri}
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif"}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline}
span.EmailStyle17
	{font-family:"Calibri","sans-serif";
	color:windowtext}
.MsoChpDefault
	{font-family:"Calibri","sans-serif"}
 <at> page WordSection1
	{margin:72.0pt 72.0pt 72.0pt 72.0pt}
--&gt;
<div>
<p>
<span>[Boldon James classification:
<span>
<span>UNMARKED</span></span></span><span><span><span>
</span><span>EXTERNAL</span></span></span><span><span></span></span><span>]</span></p>
<br>
</div>
<div>
<div class="WordSection1">
<p class="MsoNormal">Now we have our plasma client in demonstration form I performed some testing using an X.400 environment (STANAG 4406 to be precise).&nbsp; The P772 encoded Plasma message was sent / received but I was denied access trying to read the message.&nbsp;
 I tracked this down to the recipient I supplied in the GetCmsToken, rather than an SMTP address I have an X.400 O/R address, as below.</p>
<p class="MsoNormal">&nbsp;</p>
<p class="MsoNormal">&lt;Recipient&gt;</p>
<p class="MsoNormal">&nbsp;&nbsp;&nbsp; &lt;Subject&gt;s=ab51;o=borland5;p=boldonjames;a= ;c=gb&lt;/Subject&gt;</p>
<p class="MsoNormal">&lt;/Recipient&gt;</p>
<p class="MsoNormal">&nbsp;</p>
<p class="MsoNormal">I think we need another attribute to specify the type of 'Subject' we have supplied, something similar to below?
</p>
<p class="MsoNormal">&nbsp;</p>
<p class="MsoNormal">&lt;Recipient&gt;</p>
<p class="MsoNormal">&nbsp;&nbsp;&nbsp; &lt;Subject type="x400"&gt;s=ab51;o=borland5;p=boldonjames;a= ;c=gb&lt;/Subject&gt;</p>
<p class="MsoNormal">&lt;/Recipient&gt;</p>
<p class="MsoNormal">&nbsp;</p>
<p class="MsoNormal">Alan.</p>
<p class="MsoNormal">&nbsp;</p>
<p class="MsoNormal"><span>Alan Borland</span></p>
<p class="MsoNormal"><span><br></span><span lang="EN-US">Boldon James Limited,
</span><span lang="EN-US">a QinetiQ company</span><span lang="EN-US">
</span></p>
<p class="MsoNormal"><span>Mobile:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +44 (0)7810 556709<br>
Direct:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +44 (0)1270 507841<br>
Switch: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +44 (0)1270 507800<br>
Email:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href="mailto:alan.borland <at> boldonjames.com" target="_blank"><span>alan.borland <at> boldonjames.com</span></a><br>
Email (R):&nbsp;&nbsp;&nbsp;&nbsp;<a href="mailto:abborland <at> qinetiq.r.mil.uk" target="_blank"><span>abborland <at> qinetiq.r.mil.uk</span></a><br>
Web:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href="" target="_blank" title="http://www.boldonjames.com/"><span>www.boldonjames.com</span></a></span></p>
<p class="MsoNormal"><span>&nbsp;</span></p>
<p class="MsoNormal"><span lang="EN-US">&nbsp;</span></p>
<p class="MsoNormal"><span>&nbsp;</span></p>
<p class="MsoNormal"><span>&nbsp;</span></p>
<p class="MsoNormal">&nbsp;</p>
</div>
</div>
</div>
Jim Schaad | 19 Mar 00:17 2013

[plasma] FW: New Version Notification for draft-schaad-plasma-cms-04.txt

Update draft with a new way to handle encoding recipient infos.

Please look at and make sure that it makes sense.  Recommendations on other approaches should be discussed
if you feel they are better than the one offered here.  I am not emotionally attached to this encoding and we
discussed a couple of alternatives before choosing this one.

Jim

> -----Original Message-----
> From: internet-drafts <at> ietf.org [mailto:internet-drafts <at> ietf.org]
> Sent: Monday, March 18, 2013 4:07 PM
> To: ietf <at> augustcellars.com
> Subject: New Version Notification for draft-schaad-plasma-cms-04.txt
> 
> 
> A new version of I-D, draft-schaad-plasma-cms-04.txt
> has been successfully submitted by Jim Schaad and posted to the
> IETF repository.
> 
> Filename:	 draft-schaad-plasma-cms
> Revision:	 04
> Title:		 Plasma Service Cryptographic Message Syntax (CMS)
> Processing
> Creation date:	 2013-03-18
> Group:		 Individual Submission
> Number of pages: 31
> URL:             http://www.ietf.org/internet-drafts/draft-schaad-plasma-cms-
> 04.txt
> Status:          http://datatracker.ietf.org/doc/draft-schaad-plasma-cms
> Htmlized:        http://tools.ietf.org/html/draft-schaad-plasma-cms-04
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-schaad-plasma-cms-04
> 
> Abstract:
>    Secure MIME (S/MIME) defined a method of placing security labels on a
>    Cryptographic Message Syntax (CMS) object.  These labels are placed
>    as part of the data signed and validated by the parties.  This means
>    that the message content is visible to the recipient prior to the
>    label enforcement.  A new model for enforcement of policy using a
>    third party is described in RFC TBD
>    [I.D-draft-freeman-plasma-requirements].  This is the Policy
>    Augmented S/MIME (PLASMA) system.  This document provides the details
>    needed to implement the new Plasma model in the CMS infrastructure.
> 
>    An additional benefit of using the Plasma module is that the server,
>    based on policy, manages who has access to the message and how the
>    keys are protected.
> 
>    The document details how the client encryption and decryption
>    processes are performed, defines how to construct the CMS recipient
>    info structure, a new content to hold the data required for the
>    Plasma server to store the keys and policy information.  The document
>    does not cover the protocol between the client and the Plasma policy
>    enforcement server.  One example of the client/server protocol can be
>    found in RFC TBD [plasma-token].
> 
> 
> 
> 
> The IETF Secretariat


Gmane