< draft-schaad-plasma-cms-01.txt		draft-schaad-plasma-cms-02.txt >
	Network Working Group J. Schaad		Network Working Group J. Schaad
	Internet-Draft Soaring Hawk Consulting		Internet-Draft Soaring Hawk Consulting
	Intended status: Standards Track June 6, 2012		Intended status: Standards Track September 4, 2012
	Expires: December 8, 2012		Expires: March 8, 2013
	Plasma Service CMS Processing		Plasma Service Cryptographic Message Syntax (CMS) Processing
	draft-schaad-plasma-cms-01		draft-schaad-plasma-cms-02
	Abstract		Abstract
	Secure Mime (S/MIME) defined a method of placing security labels on a		Secure MIME (S/MIME) defined a method of placing security labels on a
	Cryptographic Message Syntax (CMS) object. These labels are placed		Cryptographic Message Syntax (CMS) object. These labels are placed
	as part of the data signed and validated by the parties. This means		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		that the message content is visible to the recipient prior to the
	label enforcement. In [EPS-WS-TRUST] a new model has been presented		label enforcement. A new model for enforcement of policy using a
	where a third party is used as the enforcement point of the label.		third party is described in RFC TBD
	This document provides the details needed to implement the new Plasma		[I.D-draft-freeman-plasma-requirements]. This is the Policy
	model in the CMS infrastructure.		Augmented S/MIME (PLASMA) system. This document provides the details
			needed to implement the new Plasma model in the CMS infrastructure.
	Additional benefits of using the Plasma module include moving		An additional benefit of using the Plasma module is that the
	responsibility of building lock boxes to the server and determining,		server,based on policy, manages who has access to the message and how
	based on policy, who should be a message recipient.		the keys are protected.
	The document describes and details how the encryption process is		The document details how the client encryption and decryption
	performed, defines a new lock box attribute to hold the information		processes are performed, defines how to construct the CMS recipient
	needed to valid the label and to obtain the keys needed to decrypt		info structure, a new content to hold the data required for the
	the message. The document does not cover the protocol between the		Plasma server to store the keys and policy information. The document
	client and the Plasma policy enforcement server.		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].
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
			This Internet-Draft will expire on March 8, 2013.
	This Internet-Draft will expire on December 8, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Vocabulary . . . . . . . . . . . . . . . . . . . . . . . . 4		1.1. Vocabulary . . . . . . . . . . . . . . . . . . . . . . . . 5
	1.2. Requirements Terminology . . . . . . . . . . . . . . . . . 4		1.2. Requirements Terminology . . . . . . . . . . . . . . . . . 5
	2. Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.2. Sender . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.3. Recipient . . . . . . . . . . . . . . . . . . . . . . . . 6
	3. Recipient Info Encoding . . . . . . . . . . . . . . . . . . . 7		3. Recipient Info Encoding . . . . . . . . . . . . . . . . . . . 7
	3.1. EPS Other Key Attribute . . . . . . . . . . . . . . . . . 9		3.1. PLASMA Other Key Attribute . . . . . . . . . . . . . . . . 9
	3.2. EPS Content Type . . . . . . . . . . . . . . . . . . . . . 10		3.2. PLASMA Content Type . . . . . . . . . . . . . . . . . . . 11
	3.2.1. Label Extensibility . . . . . . . . . . . . . . . . . 14		3.3. PLASMA URL Authenticated Attribute . . . . . . . . . . . . 15
	3.3. EPS URL Authenticated Attribute . . . . . . . . . . . . . 17		3.4. PLASMA Encrypted Content Hash Attribute . . . . . . . . . 16
	3.4. EPS Encrypted Content Hash Attribute . . . . . . . . . . . 18		4. Sender Processing Rules . . . . . . . . . . . . . . . . . . . 18
	4. Sender Processing Rules . . . . . . . . . . . . . . . . . . . 20		4.1. Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	4.1. Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . 20		5. Recipient Processing Rules . . . . . . . . . . . . . . . . . . 20
	5. Recipient Processing Rules . . . . . . . . . . . . . . . . . . 22		5.1. Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
	5.1. Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . 22		5.2. Reply Processing . . . . . . . . . . . . . . . . . . . . 21
	5.2. Reply and Forward Processing . . . . . . . . . . . . . . . 23		6. S/MIME Capability . . . . . . . . . . . . . . . . . . . . . . 22
	6. S/MIME Capability . . . . . . . . . . . . . . . . . . . . . . 24		7. Mandatory Algorithms . . . . . . . . . . . . . . . . . . . . . 23
	7. Manditory Algorithms . . . . . . . . . . . . . . . . . . . . . 25		7.1. Plasma Servers . . . . . . . . . . . . . . . . . . . . . . 23
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 26		7.2. Plasma Clients . . . . . . . . . . . . . . . . . . . . . . 23
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27		8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 28		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
	10.2. Informative References . . . . . . . . . . . . . . . . . . 28		10.1. Normative References . . . . . . . . . . . . . . . . . . . 26
			10.2. Informative References . . . . . . . . . . . . . . . . . . 27
	Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . .		Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . .
	Appendix A. 2009 ASN.1 Module . . . . . . . . . . . . . . . . . . 31		Appendix A. 2009 ASN.1 Module . . . . . . . . . . . . . . . . . . 29
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 35		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 33
	1. Introduction		1. Introduction
	In the traditional S/MIME (Secure MIME) e-mail system, the sender of		In the traditional S/MIME (Secure MIME) e-mail system, the sender of
	a message is responsible for determining the list of recipients for a		a message is responsible for determining the list of recipients for a
	message, obtaining a valid public or group key for each recipient,		message, obtaining a valid public or group key for each recipient,
	applying a security label to a message, and sending the message. The		applying a security label to a message, and sending the message. The
	recipient of a message is responsible for the enforcement of any		recipient of a message is responsible for the enforcement of any
	security labels on a message. While this system works in theory, in		security labels on the message. While this system works in theory,
	practice it has some difficulties that have lead to problems in		in practice it has some difficulties that have led to problems in
	getting S/MIME mail widely deployed. This document is part of an		getting S/MIME mail widely deployed. This document is part of an
	effort to provide an alternative method of allocating the		effort to provide an alternative method of allocating the
	responsibilities above to different entities in an attempt to make		responsibilities above to different entities in an attempt to make
	the process work better.		the process work better.
	In an Email Policy Service (PLASMA) deployment of S/MIME, the sender		In a Policy Augmented S/MIME (PLASMA) deployment of S/MIME, the
	of the message is still responsible for determining the list of		sender of the message is still responsible for determining the list
	recipients for the message and determining the security label to be		of recipients for the message and determining the security label to
	applied to the message, however the responsibility of obtaining valid		be applied to the message; however the Plasma server is now
	keys for each recipient can be off-loaded to the Plasma server		responsible for obtaining valid keys for recipients and checking the
	component. The recipient is no longer responsible for enforcement of		policy access for the recipients. The recipient is no longer
	the policy as this is off-loaded to the Plasma server component.		responsible for enforcement of the policy as this is off-loaded to
	Doing this allows for the following changes in behavior of the		the Plasma server component. Doing this allows for the following
	system:		changes in behavior of the system:
	o The sender is no longer responsible for finding and validating the		o The sender is no longer responsible for finding and validating the
	set of public keys used for the message. This simplifies the		set of public keys used for the message. This simplifies the
	complexity of the sender and lowers the resources required by the		complexity of the sender and lowers the resources required by the
	sender. This is especially true when a large number of recipients		sender. This is especially true when a large number of recipients
	is involved.		are involved.
	o The set of recipients that can decrypt the message can be change		o The set of recipients that can decrypt the message can be change
	dynamically after the message is sent, without resorting to a		dynamically after the message is sent, without resorting to a
	group keying strategy.		group keying strategy.
	o The enforcement of the policy is done centrally, this means that		o The enforcement of the policy is done centrally, this means that
	updates to the policy are instantaneous and the enforcement policy		updates to the policy are instantaneous and the enforcement policy
	can be centrally audited.		can be centrally audited.
	o The label enforcement is done before the message is decrypted,		o The label enforcement is done before the message is decrypted;
	this means there are no concerns about the message contents being		this means there are no concerns about the message contents being
	leaked by poor client implementations.		leaked by poor client implementations.
	o Many of the same components used in a web-based deployment of		o Many of the same components used in a web-based deployment of
	policy enforcement in a confederation can be used for e-mail based		policy enforcement in a confederation can be used for e-mail based
	deployment of information. This includes using credentials other		deployment of information. This includes using credentials other
	than X.509 certificates.		than X.509 certificates.
			While this document describes the processes in terms of dealing with
			email system, a Plasma server can be used with any number of clients
			that need to protected content. Thus the same system could be used
			for protection of documents without having to specify in advance the
			individuals who should be able to open the document; it would just be
			allowed by the server based on the policy applied to the document.
	This document is laid out as follows:		This document is laid out as follows:
	o In Section 2 a more complete description of the components		o In Section 2 a more complete description of the components
	involved in the model are discussed.		involved in the model are discussed.
	o In Section 3 is description the new ASN.1 structures that are used		o In Section 3 is description the new ASN.1 structures that are used
	to carry the additional information, and the way that these		to carry the additional information, and the way that these
	structures are used in a recipient info structure.		structures are used in a recipient info structure.
	o In Section 4 is a description of the modifications from the sender		o In Section 4 is a description of the modifications from the sender
	skipping to change at page 4, line 31 ¶		skipping to change at page 5, line 38 ¶
	Authenticated Encryption with Additional Data (AEAD): Are a set of		Authenticated Encryption with Additional Data (AEAD): Are a set of
	encryption algorithms where an authentication method stronger than		encryption algorithms where an authentication method stronger than
	the PKCS #1 packing method is used for authentication and,		the PKCS #1 packing method is used for authentication and,
	optionally, a set of unencrypted attribute values are included in		optionally, a set of unencrypted attribute values are included in
	the authentication step.		the authentication step.
	Content Encryption Key (CEK): The symmetric key used to encryption		Content Encryption Key (CEK): The symmetric key used to encryption
	the content of a message.		the content of a message.
	Key Encryption Key (KEK): The encryption of a CEK by another key.		Key Encryption Key (KEK): A key, usually a symmetric key, which is
	This may be done by either a symmetric key or an asymmetric key.		used to encrypt another key, usually a content encryption key.
	1.2. Requirements Terminology		1.2. Requirements Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		When capitalized, the key words "MUST", "MUST NOT", "REQUIRED",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
	document are to be interpreted as described in [RFC2119].		and "OPTIONAL" in this document are to be interpreted as described in
			[RFC2119].
	2. Model		2. Model
	To be supplied from the problem statement document.		Details on the model and the requirements for the Plasma system can
			be found in [I.D-draft-freeman-plasma-requirements].
	2.1. Overview
	To be supplied from the problem statement document.
	(1)(2)(6)
	(3)(5) +----------+ (7)
	+------------|Sending |-------------+
	| |Agent | |
	(4) | +----------+ |
	+----------+ +---------+
	|Email | |Mail |
	|Policy | |Transfer |
	|Service | |Agent |
	+----------+ +---------+
	(4) | +----------+ |
	| |Receiving | |
	+------------|Agent |-------------+
	(3)(5) +----------+ (1)
	(2)(6)
	Figure 1: Message Access Control Actors
	List the boxes above and give some info about them.
	2.2. Sender
	The general steps that need to be taken by the sender of an EPS
	message are listed below. The steps refer to the numbers in the
	upper halve of Figure 1. Talk about the expansion in section x.x
	1. This list needs to be re-done - it does not include early-binding
	issues.
	2. The Sending Agent composes the message, determines the set of
	recipients and a policy label to be applied to the message.
	3. The Sending Agent randomly creates a KEK.
	4. The Sending Agent transmits the KEK, the list of recipients and
	the policy label to the Email Policy Service. One possible
	protocol for this is [EPS-WS-TRUST].
	5. The Email Policy Service validates that the set of recipients,
	the sender and policy label are consistent.
	6. The Email Policy Service returns an EPS-KEK attribute to the
	Sending Agent.
	7. The Sending Agent creates a normal S/MIME encrypted data message,
	one of the recipient info structures being a KEK recipient using
	the KEK created in step 2 and the EPS-KEK attribute from step 5.
	8. The Sending Agent send the message to the Mail Transfer Agent
	using SMTP or a similar protocol.
	2.3. Recipient
	The general steps that need to be taken by a Receiving Agent for an
	EPS messaging system. The steps refer to the bottom half of
	Figure 1. An expansion of this is covered in Section 5. [anchor6]
	1. The Receiving Agent obtains the message from a Mail Transfer
	Agent using IMAP, POP or similar protocol.
	2. The Receiving Agent recognizes that a KEK recipient info with an
	EPS-KEK attribute exists and validates the attribute.
	3. The Receiving Agent sends the KEK identifier and the EPS-KEK
	attribute along with other information to the Email Policy
	Service.
	4. The Email Policy Service evaluates the policy label and the
	recipient information.
	5. The Email Policy Service returns the KEK to the Receiving Agent.
	6. The Receiving Agent decrypts the message and displays it to the
	user.
	3. Recipient Info Encoding		3. Recipient Info Encoding
	This documents defines a new Other Key Attribute to be used in the		In order for the Plasma system to function in CMS, a method needs to
	KEK Recipient Info structure. There are two distinct ways that the		be chosen and described for how the CEK is to be protected and
	problem of defining a new recipient info structure for Plasma could		carried with the message, such that the recipient will be able to
	be approached. The first would be to define a new recipient info		identified that this is a Plasma enabled message, know which Plasma
	structure to be placed in the Other Recipient Info structure. The		server to contact and be able to get back the CEK needed to decrypt
	second option is to create a new key attribute to be placed in the		the message. Not all recipients of a message that has been encrypted
	KEK Recipient Info structure.		using a Plasma server will need to contact the server in order to
			decrypt the message. There is nothing in what we are doing that
			prevents a message sender from building recipient info structures in
			a normal manner, except possibly the policy applied to the encrypted
			content. Additionally the Plasma server could return the standard
			recipient info structures to be added to the message for recipients
			if it can pre-authorize them to have access the message and knows the
			appropriate keying material.
			There are two distinct methods that were considered for identifying a
			recipient info structure as being a Plasma enabled object. The first
			would be to define a new recipient info structure to be placed in the
			Other Recipient Info structure. The second option is to create a new
			key attribute to be placed in the KEK Recipient Info structure.
	The use of a new recipient info structure would have been the easiest		The use of a new recipient info structure would have been the easiest
	to document and implement, if most major CMS implementations had kept		to document and implement, if most major CMS implementations had kept
	up with the latest versions. However it is known that several		up with the latest versions. However it is known that several
	implementations stopped with RFC 2630 [RFC2630] and it was not until		implementations stopped with RFC 2630 [RFC2630] and it was not until
	RFC 3369 [RFC3369] that the other recipient info choice was		RFC 3369 [RFC3369] that the other recipient info choice was
	introduced along with the language stating that implementations need		introduced along with the language stating that implementations need
	to gracefully handle unimplemented alternatives in the choice. This		to gracefully handle unimplemented alternatives in the recipient info
	means that if a new recipient info structure was defined and adopted,		choice. This means that if a new recipient info structure was
	the mail message would fail decoding for many recipients, even for		defined and adopted, the mail message would fail decoding for many
	those recipients that had a key transfer or key agreement recipient		recipients, even for those recipients that had a key transfer or key
	info structure. For this reason it was decided that the second		agreement recipient info structure.
	option would be chosen.
	The use of the KEKRecipeintInfo type may seem to be a stretch at		Given the current state of implementations, it was determined that
			the second method would be used it will work with more
			implementations. After implementation it might be found that using
			the first method is the better way to go, in that case the decision
			will be re-visited.
			The use of the KEKRecipientInfo type may seem to be a stretch at
	first, it was defined for those situations where a symmetric key had		first, it was defined for those situations where a symmetric key had
	already been distributed and either a specific key or a specific		already been distributed and either a specific key or a specific
	transformation on the key was to be applied in order to decrypt the		transformation on the key was to be applied in order to decrypt the
	KEK value. However, in the most generic situation, Plasma will		KEK value. Additionally, it is easy for client implementations to
	distribute a symmetric key back to the client so the difference		make the determination of a Plasma recipient info by looking at the
	between the original usage and how Plasma uses it is when the		OID for the other key attribute structure.
	symmetric key is distributed to the recipient. Additionally, it is
	easy for client implementations to make the determination of a Plasma
	recipient info by looking at the OID for the other key attribute
	structure.
	The attribute is created only by a Plasma server and not by the		A recipient info structure as defined in this document MUST be
	client software. A protocol such as the one in RFC TBD1		created by a Plasma server and MUST NOT be created by client
	[EPS-WS-TRUST] is used for clients to obtain the attribute from a		software. A protocol such as the one in RFC TBD1 [plasma-token] is
	Plasma server.		used to transport the recipient info structure between the client and
			the server.
	For the convenience of the reader we include the KEKRecipientInfo		For the convenience of the reader we include the KEKRecipientInfo
	structure pieces here (copied from [CMS-ASN]:		structure pieces here (copied from [CMS-ASN]):
	KEKRecipientInfo ::= SEQUENCE {		KEKRecipientInfo ::= SEQUENCE {
	version CMSVersion, -- always set to 4		version CMSVersion, -- always set to 4
	kekid KEKIdentifier,		kekid KEKIdentifier,
	keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,		keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
	encryptedKey EncryptedKey }		encryptedKey EncryptedKey }
	KEKIdentifier ::= SEQUENCE {		KEKIdentifier ::= SEQUENCE {
	keyIdentifier OCTET STRING,		keyIdentifier OCTET STRING,
	date GeneralizedTime OPTIONAL,		date GeneralizedTime OPTIONAL,
	skipping to change at page 8, line 29 ¶		skipping to change at page 8, line 38 ¶
	keyAttr KEY-ATTRIBUTE.		keyAttr KEY-ATTRIBUTE.
	&Type({SupportedKeyAttributes}{@keyAttrId})}		&Type({SupportedKeyAttributes}{@keyAttrId})}
	When you look at the KEKRecipientInfo structure you fill out the		When you look at the KEKRecipientInfo structure you fill out the
	fields as follows:		fields as follows:
	version is set to the value of 4.		version is set to the value of 4.
	kekid is a sequence where the fields are:		kekid is a sequence where the fields are:
	keyIdentifier is a randomly generated value. The value is		keyIdentifier is a binary value that has no meaning when
	created without any internal semantics and should be unique		associated with a plasma recipient structure. [anchor4]
	within the message. It is suggested that the value be between
	20 and 30 octets in length. The key identifier allows for a
	correlation to exist between keys returned from the Plasma
	server and specific KEKRecipientInfo structures.
	date is not used and is omitted.		date is not used and is omitted.
	other is a sequence where the fields are:		other is a sequence where the fields are:
	keyAttrId contains the value id-keyatt-eps-token.		keyAttrId contains the value id-keyatt-plasma-token.
	keyAttr contains a the value of the attribute. The details of		keyAttr contains a the value of the attribute. The details of
	this structure are covered in Section 3.1.		this structure are covered in Section 3.1. [anchor5]
	keyEncryptionAlgorithm contains the identifier and the type		keyEncryptionAlgorithm contains the identifier and the type
	information for the key encryption algorithm. The mandatory to		information for the key encryption algorithm. The mandatory to
	implement algorithms are specified in section Section 7. This		implement algorithms are specified in Section 7. This algorithm
	algorithm must be understandable by the sender of the message and		must be understandable by the sender of the message and by the
	by the recipient of the message, but it is not a requirement that		recipient of the message, but it is not a requirement that the
	the Plasma Server can process the algorithm.		Plasma Server can process the algorithm.
	encryptedKey contains the CEK encrypted by the KEK.		encryptedKey is a zero length value.
	3.1. EPS Other Key Attribute		3.1. PLASMA Other Key Attribute
	The EPS Other Key Attribute functions as the lock box for the KEK		The PLASMA Other Key Attribute functions as the lock box for the KEK
	used in encrypting the CEK. In addition to the KEK, the lock box		used in encrypting the CEK. In addition to the KEK, the lock box
	also contains the information that is needed by the Email Policy		also contains the information that is needed by the Plasma Server to
	Server to know the policy(s) applied to the encrypted data and		know the policy(s) applied to the encrypted data and possible
	possible parameters for the policy and for the client to validate		parameters for the policy and for the client to validate that the
	that the lock box applies to the encrypted content.		lock box applies to the encrypted content.
	The relevant section from the ASN.1 module which contains the content		The relevant section from the ASN.1 module which contains the content
	is:		is:
	--		--
	-- New Other Key Attribute value for Plasma		-- New Other Key Attribute value for Plasma
	-- This structure holds the encrypted KEK value for the server		-- This structure holds the encrypted KEK value for the server
	-- and other signed attributes used by the client for checking		-- and other signed attributes used by the client for checking
	-- the structure applies in this case		-- the structure applies in this case
	--		--
	keyatt-eps-kek KEY-ATTRIBUTE ::= {		keyatt-plasma-kek KEY-ATTRIBUTE ::= {
	SignedData IDENTIFIED BY id-keyatt-eps-token		SignedData IDENTIFIED BY id-keyatt-plasma-token
	}		}
	id-keyatt-eps-token OBJECT IDENTIFIER ::= {iso(1) member-body(2)		id-keyatt-plasma-token OBJECT IDENTIFIER ::= {iso(1) member-body(2)
	us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBD2 }		us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBD2 }
	We define a new KEY-ATTRIBUTE called keyatt-eps-kek. This attribute		We define a new KEY-ATTRIBUTE called keyatt-plasma-kek. This
	is identified by the id-keyatt-eps-token. The data structure that is		attribute is identified by the id-keyatt-plasma-token. The data
	associated with this key attribute is the CMS SignedData structure.		structure that is associated with this key attribute is the CMS
	The CMS SignedData structure is used directly without a CMS		SignedData structure. The CMS SignedData structure is used directly
	ContentInfo structure wrapping it.		without a CMS ContentInfo structure wrapping it.
	The SignedData structure fields are filled as follows (some less		The SignedData structure fields are filled as follows (some less
	significant fields are omitted):		significant fields are omitted):
	encapContentInfo is a structure containing the fields:		encapContentInfo is a structure containing the fields:
	eContentType is id-envelopedData or id-ct-authEnvelopedData.		eContentType is id-ct-authEnvelopedData.
	eContent is CMS EnvelopedData or AuthEnvelopedData structure with		eContent is CMS AuthEnvelopedData structure with the following
	the following fields:		fields:
	recipientInfos contains the lock box(s) for the Plasma		recipientInfos contains the lock box(s) for the Plasma
	servers(s) to get access to the encrypted data. There MUST		servers(s) to get access to the encrypted data. There MUST
	NOT be recipient info structures added for any entity not		NOT be recipient info structures added for any entity not
	trusted to correctly perform the policy decision processing.		trusted to correctly perform the policy decision processing.
	See below for some additional discussion on what lock boxes		See below for some additional discussion on what lock boxes
	need to be created.		need to be created.
	encryptedContentInfo/authEncryptedContentInfo is a structure		encryptedContentInfo/authEncryptedContentInfo is a structure
	containing the following elements:		containing the following elements:
	contentType is id-ct-eps-LockBox.		contentType is id-ct-plasma-LockBox.
	contentEncryptionAlgorithm contains the identifier and		contentEncryptionAlgorithm contains the identifier and
	parameters for the content encryption algorithm. This		parameters for the content encryption algorithm. This
	algorithm only needs to be understood by the Plasma		algorithm only needs to be understood by the Plasma
	service.		service.
	encryptedContent contains the encrypted EPS LockBox		encryptedContent contains the encrypted PLASMA LockBox
	content. Details on this type are in the next section.		content. Details on this type are in the next section.
	certificates SHOULD contain the set of certificates (up to but not		certificates SHOULD contain the set of certificates (up to but not
	including the trust anchor) needed to validate the set of signer		including the trust anchor) needed to validate the set of signer
	info structures.		info structures.
	signerInfos will contain one or more signer info structures. In		signerInfos will contain one or more signer info structures. In
	each signature the signed attributes:		each signature the signed attributes:
	* MUST contain the signing time, the message digest, the content		* MUST contain the signing time, the message digest, the content
	type and the EPS url attributes.		type, the PLASMA hash attribute and the PLASMA url attributes.
			* SHOULD contain the multiple signature attribute [RFC5752] if
			more than one signature exists.
	* MAY contain the ESS security label attribute.		* MAY contain the ESS security label attribute.
	* other attributes can also be included.		* other attributes can also be included.
	When creating the recipient info structures for the EnvelopedData		When creating the recipient info structures for the EnvelopedData
	structure, there will normally only need to be a single entry in the		structure, there will normally only need to be a single entry in the
	sequence as the only entity that needs to decrypt the EPS Lockbox is		sequence as the only entity that needs to decrypt the PLASMA Lockbox
	the Email Policy Service. In the event that the service is		is the Plasma Service. In the event that the service is distributed
	distributed over multiple servers then multiple lock boxes may need		over multiple servers then multiple lock boxes may need to be
	to be created. One of the implications of the fact that the		created. One of the implications of the fact that the originator of
	originator of the message is the only recipient is that, although the		the message is the only recipient is that, although the signing key
	signing key needs to be contained in a certificate, there is no		needs to be contained in a certificate, there is no corresponding
	corresponding requirement that the encryption key needs to be in a		requirement that the encryption key needs to be in a certificate.
	certificate. Instead of using a certificate, a subject key		Instead of using a certificate, a subject key identifier that is
	identifier that is meaningful only to the Email Policy Service can be		meaningful only to the Plasma Service can be used.
	used.
	3.2. EPS Content Type		There are a number of circumstances that a Plasma server would apply
			multiple signatures to a single lockbox. These circumstances include
			during key rollover while a certificate is approaching expiration,
			esp. if there is going to be a change in the trust anchor being used.
			Another circumstance would be if a new signature algorithm is being
			rolled out, having the old and the new algorithm on the message
			during the rollout period increases the chances that the signature
			can be validated. In these circumstances, the multiple signature
			attribute defined in RFC 5752 [RFC5752] allows for a client to
			determine that a signature has been removed which might be attempted
			as part of an attack to use a more insecure algorithm.
	The inner content type for an EPS Other Key Attribute is an EPS		3.2. PLASMA Content Type
			The inner content type for a PLASMA Other Key Attribute is a PLASMA
	Lockbox. This content is contained in an encrypted CMS object which		Lockbox. This content is contained in an encrypted CMS object which
	is encrypted by and for the Plasma server itself, as such the		is encrypted by and for the Plasma server itself, as such the
	contents and structure is known just to the Plasma server.		contents and structure is known just to the Plasma server.
			The content type is designed so that the Plasma server does not need
			to keep any state dealing with a message on the server itself. This
			allows for minimal information to be kept on the server, it only
			needs the state of it's current transactions, and the message can be
			processed by any of a number of servers without needing to replicate
			state between them.
	The relevant section from the ASN.1 module which defines this content		The relevant section from the ASN.1 module which defines this content
	is:		is:
	--		--
	-- EPS Content Type		-- PLASMA Content Type
	--		--
	ct-eps-LockBox CONTENT-TYPE ::= {		ct-plasma-LockBox CONTENT-TYPE ::= {
	TYPE EPS-LockBox		TYPE PLASMA-LockBox
	IDENTIFIED BY id-ct-eps-LockBox		IDENTIFIED BY id-ct-plasma-LockBox
	}		}
	id-ct-eps-LockBox OBJECT IDENTIFIER ::= {iso(1) member-body(2)		id-ct-plasma-LockBox OBJECT IDENTIFIER ::= {iso(1) member-body(2)
	us(840) rsadsi(113549) pkcs(1) pkcs7(7) TBD1}		us(840) rsadsi(113549) pkcs(1) pkcs7(7) TBD1}
	EPS-LockBox ::= SEQUENCE {		PLASMA-LockBox ::= SEQUENCE {
	label OneLabel,		label UTF8String,
	keyList KeyList,		keyList KeyList,
	attrList AttributeList OPTIONAL		attrList AttributeList OPTIONAL
	}		}
	KeyList ::= SEQUENCE {		KeyList ::= SEQUENCE {
	namedRecipients [0] SEQUENCE SIZE (1..MAX) OF		namedRecipients [0] SEQUENCE SIZE (1..MAX) OF
	NamedRecipient OPTIONAL,		NamedRecipient OPTIONAL,
	defaultRecipients [1] SEQUENCE SIZE (1..MAX) OF		defaultRecipients [1] SEQUENCE SIZE (1..MAX) OF
	OneKek OPTIONAL		OneCek OPTIONAL,
			...
	}		}
	(WITH COMPONENTS {		(WITH COMPONENTS {
	...,		...,
	namedRecipients PRESENT		namedRecipients PRESENT
	} |		} |
	WITH COMPONENTS {		WITH COMPONENTS {
	...,		...,
	defaultRecipients PRESENT		defaultRecipients PRESENT
	})		})
	NamedRecipient ::= SEQUENCE {		NamedRecipient ::= SEQUENCE {
	recipient IA5String, -- name of the recipient		recipientName UTF8String, -- name of the recipient
	kekValue SEQUENCE {		keyIdentifier OCTET STRING OPTIONAL,
	kekIdentifier OCTET STRING,		keyValue RecipientInfo,
	keyValue RecipientInfo		...
	}
	}
	OneKek ::= SEQUENCE {
	kekIdentifier OCTET STRING,
	kekValue OCTET STRING
	}		}
	OneLabel ::= CHOICE {		OneCek ::= SEQUENCE {
	andLabels [1] SEQUENCE SIZE (2..MAX) OF OneLabel,		keyPolicy UTF8String OPTIONAL,
	orLabels [2] SEQUENCE SIZE (2..MAX) OF OneLabel,		keyIdentifier [1] OCTET STRING OPTIONAL,
	exclude [3] SEQUENCE SIZE (2) OF OneLabel,		keyValue OCTET STRING,
	uriLeaf [4] SEQUENCE {		...
	policyId UTF8String,
	names SEQUENCE SIZE (1..MAX) OF
	IA5String OPTIONAL
	},
	oidLeaf [5] ESSSecurityLabel,
	...
	}		}
	AttributeList ::= SEQUENCE SIZE (1..MAX) OF		AttributeList ::= SEQUENCE SIZE (1..MAX) OF
	SingleAttribute{{EPSAttributes}}		SingleAttribute{{PLASMAAttributes}}
	EPSAttributes ATTRIBUTE ::= { ... }		PLASMAAttributes ATTRIBUTE ::= { ... }
	In the above ASN.1, the following items are defined:		In the above ASN.1, the following items are defined:
	ct-eps-LockBox is a new CMS content type object, this object is		ct-plasma-LockBox is a new CMS content type object, this object is
	added to the set of content type objects in ContentSet (defined in		added to the set of content type objects in ContentSet (defined in
	the ASN.1 module in [CMS-ASN]). The content type associates the		the ASN.1 module in [CMS-ASN]). The content type associates the
	object identifier id-ct-eps-LockBox with the data type EPS-		object identifier id-ct-plasma-LockBox with the data type PLASMA-
	LockBox.		LockBox.
	id-ct-eps-LockBox is the identifier defined for the new content		id-ct-plasma-LockBox is the identifier defined for the new content
	type.		type.
	EPS-LockBox is the new type defined for new content type. This is a		PLASMA-LockBox is the new type defined for new content type. This
	sequence [anchor8] with the following fields:		is a sequence with the following fields:
	label contains the policy label that is to be applied to the KEK		label contains the policy label that is to be applied to the KEK
	values in the keyList field.		values in the keyList field.
	keyList contains the KEK values.		keyList contains the KEK values.
	attrList contains a set of attributes which are considered as		attrList contains a set of attributes which are considered as
	significant by the Plasma server internally.		significant by the Plasma server internally.
	KeyList is a new type that contains the KEK values or the		KeyList is a new type that contains CEK values or KeyRecipientInfo
	KeyRecipientInfo structures. This allows for messages to be sent		structures. This allows for messages to be sent with either
	with either early-binding, where a RecipientInfo structure is		early-binding, where a RecipientInfo structure is filled out for
	filled out for the receiving agent, or late-binding, where the KEK		the receiving agent, or late-binding, where the CEK value is sent
	value is sent from the Plasma Service to the receiving agent. It		from the Plasma Service to the receiving agent. It is required
	is required that at least one of these fields is populated.		that at least one of these fields is populated.
	namedRecipients contains the recipient info structures for		namedRecipients contains the recipient info structures for
	individually identified recipients.[anchor9]		individually identified recipients.
	defaultRecipients contains the KEK keys for those recipients that		defaultRecipients contains the CEK keys for those recipients that
	are not individual identified with their own recipient info		are not individual identified with their own recipient info
	structures.		structures.
	NamedRecipient contains the information identifying a single named		NamedRecipient contains the information identifying a single named
	recipient along with the recipient info structures for that		recipient along with the recipient info structures for that
	recipient.		recipient.
	recipient contains the name of the name of the recipient in the		recipientName contains the name of the name of the recipient in
	form of an RFC2822 email address.		the form of an RFC5321 email address.
	kekValue contains the recipient info structure for the named		keyIdentifier contains the identification value for the CEK.
	recipient. The fields in the sequence are:
	kekIdentifier contains the value of the kek identifier in the		keyValue contains the recipient info structure for the named
	message.		recipient.
	keyValue contains a recipient info structure wrapping the CEK		This structure is tagged as extensible; this was done because
	of the message.		there may be a need to add additional fields such as other name
			types in the future.
	OneKek contains the information that defines a single KEK to be		OneCek contains the information that defines a single CEK to be
	used. The sequence has the fields:		used. The sequence has the fields:
	kekIdentifier contains the identification value for the KEK.		keyPolicy contains a policy string specific to this key. If
	This value matches the KEKIdentifier.keyIdentifier value in the		present the policy MUST be evaluated as accept before this key
	recipient info information.		is released.
	kekValue contains the KEK value.
	OneLabel is the type structure used to specify the individual
	policies and how the policies interact with each other. The
	structure is explicitly setup to be extensible in future versions.
	Information on how the extensibility should be handled is in
	Section 3.2.1. The choices in the structure are:
	andLabels allows for a set of policies to be combined together in
	such as way as to state that for the overall statement to be
	true, each of the policies listed must also be true. The ASN.1
	is designed so that there must be at least two elements in the
	combined statement.
	orLabels allows for a set of policies to be combined together in
	such a way as to state that for the overall statement to be
	true, any of the policies listed needs to be true. The ASN.1
	is designed so that there must be at least two elements in the
	combined statement.
	exclude allows for two policies to be combined together such as		keyIdentifier contains the identification value for the CEK.
	to state that for the overall policy to be true, the first
	policy must be true and the second policy must not be true.
	This policy combination is designed to remove a set of people
	from the over all policy. (I.e. every one in the general group
	but is not working for company X.)
	uriLeaf allows for the specification of a policy as a URI. If		keyValue contains the KEK value.
	the policy is unknown then the policy evaluation fails. The
	use of a URI allows for the addition of parameters to be added
	to the policy statement.[anchor10]
	oidLeaf allows for the specification of a policy as an object		This structure is tagged as extensible; this was done because
	identifier. There is no option to provide for parameters.		there may be a need to add additional fields such as other name
	[anchor11]		types in the future.
	AttributeList defines a structure where a set of attributes can be		AttributeList defines a structure where a set of attributes can be
	included.		included.
	EPSAttributes defines an Object Set of attributes which can be		PLASMAAttributes defines an Object Set of attributes which can be
	included. The object set is intentionally open ended for later		included. The object set is intentionally open ended for later
	expansion. We currently do not define any items that go in this		expansion. We currently do not define any items that go in this
	field.		field.
	3.2.1. Label Extensibility		The recipientName field of the NamedRecipient structure is designed
			so that a client can build a CMS recipient info structure targeted to
	The ASN.1 type OneLabel has been explicitly defined to allow for		a specific recipient. In order for the Plasma server to know which
	later extensibility. When a new element is added, it will be added		of these named recipient structure to return it requires that the
	with at the end of the choice with a different tag value. ASN.1		sender identify the recipient for the CMS recipient info structure
	decoders need to following the current recommendations on dealing		and that the recipient identify itself so that the Plasma server can
	with extensibility. This means that when the decoder finds a new		find the correct structure. We are using Email names in the form of
	choice in this structure that is not part of the current syntax, the		internationalized RFC 5321 [RFC5321] address names. There are a
	element should be treated as an unknown blob and returned to the		number of issues that are associated with the use of this name form
	caller as an unrecognized blob. This allows for the calling code to		for comparison purposes. As stated in Section 2.3.11 of RFC 5321,
	make the decision on how the unknown element is treated.
	However the extensibility is not handled the same in all cases. Each
	of the four different cases is outlined below.
	3.2.1.1. Sender Composing
	The set of policies that can be used by the sender in applying a
	label is usually given as a list of policies, however under some
	circumstances the sender may be handed structured policies either for
	application or for checking that some policies can be used together.
	If structured policies are provided to the sender, it will not matter
	to the sender that they cannot evaluate the policy unless the details
	are to be shown to the sending user. Following the current ASN.1
	rules which allow for the decoding and then re-encoding of a type
	which contains unknown nodes allows the sending agent the most
	flexibility.
	The protocol used to give the policy information to the sending
	client may not use the ASN.1 structure provided here or configuration
	purposes but would generally be expected to provide for a different
	data format.
	3.2.1.2. Sender to Email Policy Service
	In the sending agent to Email Policy Service protocol (defined
	external to this document) the ASN.1 type OneLabel may or may not be
	used directly. If it is used, then the Email Policy Server is
	expected to reject the label if it contains elements which it does
	not understand. The general expectation is that the Email Policy
	Service that the sender is communicating with is going to be the same
	one as is later enforcing the policy. It makes no sense for this
	server to accept a policy that it would later be unable to enforce.
	The protocol should make provisions for the return of this as an
	explicit error code. Having the ASN.1 decoded allows for the
	communication of the exact tag that is causing the problem. Under
	most policies, the evaluation of sender policy would be expected to
	be different than laid out in the next session. As a general rule,
	the sender should be permitted to assert all of the leaf policies for
	the purpose of sending.
	3.2.1.3. Recipient to Email Policy Service
	The Email Policy Service which recipient communicates way is normally
	the same server as the sender communicated with. However the server
	can be a different server, or the server may have been downgraded in
	the mean time. In this case the policy evaluation need to be
	conservative. There are two different ways of doing this evaluation.
	The first option is to say that if an unknown node is found, then the
	policy evaluation results in "Deny" for all cases. The second option
	is to try and evaluation the policy, but to do so in a conservative
	manner. In this section we use the same terms as XACML [XACML] uses
	in section 7.2.1. If the second option is chosen then the following
	rules are used:
	uriLeaf results in "Permit", "Deny", "Not Applicable" or
	"Indeterminate". "Not Applicable" results if the policy is
	unknown. "Indeterminate" results if the policy cannot be
	evaluated.
	oidLeaf results in "Permit", "Deny", "Not Applicable" or
	"Indeterminate". "Not Applicable" results if the policy is
	unknown. "Indeterminate" results if the policy cannot be
	evaluated.
	andLabels results in "Deny" if any input node is "Deny" or "Not		the local-part MUST be interpreted and assigned semantics only by the
	Applicable". It results in "Permit" if all of the input nodes are		host specified in the domain part of the address. While many
	"Permit". Otherwise it results in "Indeterminate".		platforms do case-insensitive comparisons of mailbox names, there is
			not a way for an independent server to know if this is appropriate
			behavior. A similar issue exists with Unicode normalization as
			pointed out in Section 10.1 of RFC 6530 [RFC6530]. The server that
			holds the mailbox can have a consistent rule for normalization, but a
			Plasma server in separate domain may not know the appropriate rules
			to use.
	orLabels results in "Permit" if any input node is "Permit". It		Plasma servers SHOULD do the following when comparing the Email
	results in "Deny" if all nodes are either "Deny" or "Not		addresses found in the recipientName field:
	Applicable". Otherwise it results in "Indeterminate".
	exclude results in "Deny" if the first element is "Deny" or if the		1. The domain name portion is compared using procedure in Section
	second input is "Permit". It results in "Permit" if the first		2.3.2.4 of [RFC5890]. The rules are:
	input is "Permit" and the second is "Deny". It results in "Not
	Applicable" if either element is "Not Applicable". Otherwise it
	results in "Indeterminate".
	If the final node results in "Permit", then access is granted. If		* Exact (bit-string identity) matches between pairs of U-labels.
	the final result is either "Deny" or "Not Applicable" then access is
	denied. If the final result is "Indeterminate", then access is
	denied, however if the protocol permits, then the result can be "Not
	Applicable" and the attributes needed to do the policy evaluation can
	be requested and policy evaluation may be re-attempted.
	Any future element that is added to the choice needs to define a		* Matches between a pair of A-labels, using normal DNS case-
	similar rule to the set of rules above.		insensitive matching rules.
	3.2.1.4. Recipient User Agent Display		* Equivalence between a U-label and an A-label determined by
			translating the U-label form into an A-label form and then
			testing for a match between the A-labels using normal DNS
			case-insensitive rules.
	Recipient user agents may want to display the policy to the user.		2. The local name portion of the name is compared using bit-string
	This policy may be communicated from the Email Policy Service to the		identity. Plasma servers MAY apply appropriate transformations
	recipient using the OneLabel ASN.1 structure or using a different		for local domain names, but SHOULD NOT apply them for other
	type. The label has been successfully (or unsuccessfully) validated		domains.
	so access has been granted (or denied) to the message. At this point
	we are only talking about a user interface issue. The recipient user
	agent should make some type of provision for indicating that an
	operation was placed in that location of the tree, but the agent is
	not aware of what the operation is.
	3.3. EPS URL Authenticated Attribute		3.3. PLASMA URL Authenticated Attribute
	It is required that the name of the Email Policy Server be securely		It is required that the name of the Plasma Server be securely
	communicated to the message recipient. For this purpose a URL is		communicated to the message recipient. For this purpose a URL is
	used as this can communicate both a server name as well as additional		used as this can communicate both a server name as well as additional
	parameters that can be used to identify a specific service on the		parameters that can be used to identify a specific service on the
	server.		server.
	The relevant section from the ASN.1 module for this attribute is:		The relevant section from the ASN.1 module for this attribute is:
	--		--
	-- Define the Signed Attribute to carry the		-- Define the Signed Attribute to carry the
	-- Email Policy Server URL		-- Email Policy Server URL
	--		--
	-- This attribute is added to the SignedAttributSet set of		-- This attribute is added to the SignedAttributSet set of
	-- attributes in [CMS-ASN]		-- attributes in [CMS-ASN]
	--		--
	aa-eps-url ATTRIBUTE ::= {		aa-plasma-url ATTRIBUTE ::= {
	TYPE UTF8String IDENTIFIED BY id-aa-eps-url		TYPE UTF8String IDENTIFIED BY id-aa-plasma-url
	}		}
	id-aa-eps-url OBJECT IDENTIFIER ::= { iso(1) member-body(2)		id-aa-plasma-url OBJECT IDENTIFIER ::= { iso(1) member-body(2)
	us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBD3}		us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBD3}
	From this we can see the following:		From this we can see the following:
	A new attribute aa-eps-url has been defined.		A new attribute aa-plasma-url has been defined.
	The OID value of id-aa-eps-url has been created to identify the		The OID value of id-aa-plasma-url has been created to identify the
	new attribute.		new attribute.
	The type of the value associated with the attribute is a		The type of the value associated with the attribute is a
	UTF8String which contains the URL for the Email Policy Server.		UTF8String which contains the URL for the Plasma Server. The URL
	The URL defines both the destination server and the protocol to be		defines both the destination server and the protocol to be used.
	used. When the schema for the URL is "https", then the protocol		When the schema for the URL is "plasma", then the protocol used is
	used is [eps-token]		[plasma-token]
	The new attribute is to appear only as a Signed Attribute in a		The new attribute is to appear only as a Signed Attribute in a
	SignedData structure. It is therefore to be added to the		SignedData structure. It is therefore to be added to the
	attribute set SignedAttributeSet in the update ASN.1 module		attribute set SignedAttributeSet in the update ASN.1 module
	contained in [CMS-ASN].		contained in [CMS-ASN].
	The attribute structure defined for signed attributes allows for		The attribute structure defined for signed attributes allows for
	multiple values to be carried in a single attribute. For this		multiple values to be carried in a single attribute. For this
	attribute there MUST be at least one value. If there is more than		attribute there MUST be at least one value. If there is more than
	one value, each value MUST be a unique. Multiple values are allowed		one value, each value MUST be unique. Multiple values are allowed as
	as there can be multiple Plasma servers that can be used to evaluate		there can be multiple Plasma servers that can be used to evaluate the
	the policy. The order of URLs does not indicate any order of		policy. The order of URLs does not indicate any order of priority,
	priority, any of the values may be used.		any of the values may be used.
	This attribute is only included in a SignedData object by an Email		This attribute is only included in a SignedData object by a Plasma
	Policy Server. There are no processing rules for the sender of a		Server. There are no processing rules for the sender of a message.
	message. The processing rules for a recipient can be found in		The processing rules for a recipient can be found in Section 5.
	Section 5.
	3.4. EPS Encrypted Content Hash Attribute		3.4. PLASMA Encrypted Content Hash Attribute
	For privacy reasons, it is highly desirable that the recipient of a		For privacy reasons, it is highly desirable that the recipient of a
	message can validate that the Plasma lock box embedded in a message		message can validate that the Plasma lock box embedded in a message
	is associated with encrypted data it is attached to. For this		is associated with encrypted data it is attached to. For this
	reason, in addition to the requirement that a recipient validate the		reason, in addition to the requirement that a recipient validate the
	signature of the Plasma server over the lock box, a new attribute is		signature of the Plasma server over the lock box, a new attribute is
	defined which contains the hash of the encrypted content.		defined which contains the hash of the encrypted content.
	--		--
	-- Define the Signed Attribute to carry the		-- Define the Signed Attribute to carry the
	-- hash of encrypted data		-- hash of encrypted data
	--		--
	-- This attribute is added to the SignedAttributeSet set of		-- This attribute is added to the SignedAttributeSet set of
	-- attributes in [CMS-ASN]		-- attributes in [CMS-ASN]
	--		--
	aa-eps-hash ATTRIBUTE ::= {		aa-plasma-econtent-hash ATTRIBUTE ::= {
	TYPE HashValue IDENTIFIED BY id-aa-eps-hash		TYPE HashValue IDENTIFIED BY id-aa-plasma-econtent-hash
	}		}
	id-aa-eps-hash OBJECT IDENTIFIER ::= {iso(1) member-body(2)		id-aa-plasma-econtent-hash OBJECT IDENTIFIER ::= {iso(1) member-body(2)
	us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBD4}		us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBD4}
	HashValue ::= SEQUENCE {		HashValue ::= SEQUENCE {
	hashAlgorithm DigestAlgorithmIdentifier,		hashAlgorithm DigestAlgorithmIdentifier,
	hashValue OCTET STRING		hashValue OCTET STRING
	}		}
	The above ASN.1 fragment defines the following items:		The above ASN.1 fragment defines the following items:
	aa-eps-hash defines a new ATTRIBUTE object describing the encrypted		aa-plasma-econtent-hash defines a new ATTRIBUTE object describing
	content hash attribute. This attribute is always a signed object		the encrypted content hash attribute. This attribute is always a
	and is to be added to the SignedAttributeSet in the CMS ASN.1		signed object and is to be added to the SignedAttributeSet in the
	mdoule contained in [CMS-ASN].		CMS ASN.1 mdoule contained in [CMS-ASN].
	id-aa-eps-hash defines the unique identifier of the attribute.		id-aa-plasma-econtent-hash defines the unique identifier of the
			attribute.
	HashValue defines the data value to be associated with the		HashValue defines the data value to be associated with the
	attribute. The fields of this type are:		attribute. The fields of this type are:
	hashAlgorithm contains the identifier and parameters of the hash		hashAlgorithm contains the identifier and parameters of the hash
	function used.		function used.
	hashValue contains the value of the hash operation.		hashValue contains the value of the hash operation.
	The hash is computed over the encrypted content, without including		The hash is computed over the encrypted content, without including
	skipping to change at page 20, line 22 ¶		skipping to change at page 18, line 22 ¶
	1. Sender Agent obtains the set of policies under which it can send		1. Sender Agent obtains the set of policies under which it can send
	a message.		a message.
	2. Sender Agent composes the message content.		2. Sender Agent composes the message content.
	3. Sender Agent determines the policy label to be applied to the		3. Sender Agent determines the policy label to be applied to the
	message.		message.
	4. Sender Agent determines the set of recipients for the message.		4. Sender Agent determines the set of recipients for the message.
	5. Sender Agent randomly creates the KEK.		5. Sender Agent selects the content encryption algorithm (with
			input from the policies chosen) and randomly creates the CEK.
	6. Sender Agent randomly selects the content encryption algorithm
	(with input from the policies chosen) and randomly creates the
	CEK.
	7. Sender Agent encrypts the content with the CEK and computes the		6. Sender Agent encrypts the content with the CEK and computes the
	encrypted hash value.		encrypted hash value.
	8. Sender Agent may optionally create lock boxes for one or more of		7. Sender Agent may optionally creates lock boxes for one or more
	the message recipients, for those recipients which are to be		message recipients. (These are for the early-bind recipients
	protected by the policy server.		that are protected by the policy server.)
	9. Sender Agent transmits the KEK, the list of recipients, the set		8. Sender Agent transmits the CEK, the list of recipients, the set
	of recipient lock boxes, the encrypted hash value and the policy		of policy protected recipient lock boxes, the encrypted hash
	label to the EPS.		value and the policy label to the PLASMA server.
	10. Sender Agent receives an EPS-KEK attribute from the policy		9. Sender Agent receives a set of recipient info structures from
	server. If the policy validation fails then the sender agent		the policy server. If the policy validation fails then the
	cannot send the message under the current policy label.		sender agent cannot send the message under the current policy
			label.
	11. Sender Agent verifies the signature on the signed data structure		10. Sender Agent verifies the signature on the signed data structure
	inside of the EPS-KEK attribute.		inside of the PLASMA-KEK attribute.
	A. Signature is current and passes cryptographic processing.		A. Signature is current and passes cryptographic processing.
	B. Signed attributes contains the EPS URL attribute, the EPS		B. Signed attributes contains the PLASMA URL attribute, the
	Encrypted Hash attribute and the attribute is consistent		PLASMA Encrypted Hash attribute and the attribute is
	with the policy selected.		consistent with the policy selected.
	C. Other standard signature checks.		C. The certificate used to validate the signature MUST have the
			Plasma XXXX EKU (defined in Section X.Y of RFC XXXX).
	12. Sender Agent selects an appropriate content encryption algorithm		D. Other standard signature checks.
	and randomly generates a CEK and encrypts the message.
	13. Sender Agent creates a KEK recipient info structure with the		The Sender Agent SHOULD validate all of the signatures if more
	EPS-KEK attribute. Sender Agent also creates all other		than one signature exists.
	necessary recipient info structures (for recipients not
	protected by policy) including one itself if required.
	14. Sender Agent finishes encoding the message and transmits it to		11. Sender Agent adds the recipient info structures returned from
			the Plasma server to those it creates for early bind recipients
			which are not protected by policy.
			12. Sender Agent finishes encoding the message and transmits it to
	the MTA.		the MTA.
	5. Recipient Processing Rules		5. Recipient Processing Rules
	5.1. Flow		5.1. Flow
	In this section we expand on the list of actions that are		When looking at the validation steps that are given here, the results
	Section 2.3. When looking at the validation steps that are given		need to be the same but the order that the steps are taken can be
	here, the results need to be the same but the order that the steps		different. As an example, it can make sense to do the policy check
	are taken can be different. As an example, it can make sense to do		in step Paragraph 3.5 before doing the signature validation as this
	the policy check in step X before doing the signature validation as		would not require any network access.
	this would not require any network access.
	This is the set of processing that the recipient needs to do:		This is the set of processing that the recipient needs to do:
	1. The Receiving Agent obtains the message from a Mail Transfer		1. The Receiving Agent obtains the message from a Mail Transfer
	Agent using IMAP, POP or a similar protocol.		Agent using IMAP, POP or a similar protocol.
	2. The Receiving Agent recognizes that a KEK recipient info exists		2. The Receiving Agent recognizes that a KEK recipient info exists
	with an EPS-KEK attribute. It is recommended that the entire		with a PLASMA-KEK attribute. It is recommended that the entire
	list of recipient info structures be checked for one that can be		list of recipient info structures be checked for one that can be
	processed directly before processing this node.		processed directly before processing this node.
	3. The Receiving Agent validates the EPS-KEK attribute. The		3. The Receiving Agent validates the PLASMA-KEK attribute. The
	following steps need to be taken for validation.		following steps need to be taken for validation.
	A. The signature on the SignedData structure is validated. If		A. The signature on the SignedData structure is validated. If
	the validation fails then processing ends. If more than one		the validation fails then processing ends. If more than one
	SignerInfo element exists on the structure, then the		SignerInfo element exists on the structure, then the
	validation succeeds and the signed attributes from that		validation needs to succeed only on one SignerInfo element,
	SignerInfo structure are used. The order of performing the		the signed attributes from that SignerInfo structure are
	validation of the SignerInfo structures may be influenced by		used. The order of performing the validation of the
	the content of EPS URL attribute.		SignerInfo structures may be influenced by the content of
			PLASMA URL attribute.
	B. If an ESS security label attribute ([ESS-BASE]) is present,		B. The certificate used to validate the signature MUST contain
			the XXXX value in the EKU extension. The certificate MUST
			NOT contain the anyPolicy value in the EKU extension.
			C. If an ESS security label attribute ([ESS-BASE]) is present,
	then it must be evaluated and processing ends if the security		then it must be evaluated and processing ends if the security
	label processing fails or is denied.		label processing fails or is denied.
	C. The EPS URL attribute is absent, then processing fails.		D. The PLASMA URL attribute is absent, then processing fails.
	D. The URL value in the EPS URL attribute is checked against		E. The URL value in the PLASMA URL attribute is checked against
	local policy. If the check fails then processing fails.		local policy. If the check fails then processing fails.
	This check is performed so that information about the user is		This check is performed so that information about the user is
	not given to random Email Policy Services.		not given to a random Plasma server. The schema of the URL
			MUST be one that the client implements. (For example the
			"plasma" schema associated with RFC XXX [plasma-token].) As
			discussed in Section 4.5 of
			[I.D-draft-freeman-plasma-requirements], policy can be
			enforced on the edge of an enterprise, this means that if
			multiple URLs are present in the Plasma URL attribute they
			all need to be checked for policy and ability to use before
			this step fails.
	E. The EPS Encrypted Hash attribute value is checked against the		F. The PLASMA Encrypted Hash attribute value is checked against
	encrypted content. If this check fails then processing		the encrypted content. If this attribute is absent then
	fails.		processing fails. If the value does not matched the computed
			value on the encrypted content then processing fails.
	4. The recipient gathers the necessary identity and attribute		4. The recipient gathers the necessary identity and attribute
	statements, usual certificates or SASL statements.		statements, usual certificates or SASL statements.
	5. The recipient establishing a secure connection to the Email		5. The recipient establishing a secure connection to the Plasma
	Policy server and passes in the identity and attribute statements		server and passes in the identity and attribute statements and
	and receives back the KEK or lock box to allow it to obtain the		receives back the CEK or a lock box to allow it to obtain the CEK
	CEK value.		value.
	5.2. Reply and Forward Processing		5.2. Reply Processing
	In some circumstances a message recipient may be permitted to read a		In some circumstances a message recipient may be permitted to read a
	message sent under a certan policy, but it not permitted to send a		message sent under a certan policy, but it not permitted to send a
	message for that policy. In the event that a complex policy is used		message for that policy. In the event that a complex policy is used
	the recipient may be permitted to read under one policy, but not have		the recipient may be permitted to read under one policy, but not have
	any rights under a second policy. In both of these case a recipient		any rights under a second policy. In both of these case a recipient
	of a message would be unable to either reply or forward a message		of a message would be unable to either reply or forward a message
	using the same policy as they received it under. For this reason,		using the same policy as they received it under. For this reason,
	the protocol used to communicate with the Plasma server will		the protocol used to communicate with the Plasma server will
	frequently return a single purpose policy that permits a recipient to		frequently return a single purpose policy that permits a recipient to
	skipping to change at page 25, line 5 ¶		skipping to change at page 23, line 5 ¶
	id-cap-plasma-recipientInfo OBJECT IDENTIFIER ::= {		id-cap-plasma-recipientInfo OBJECT IDENTIFIER ::= {
	id-cap TBD5		id-cap TBD5
	}		}
	We define a new SMIME-CAPS object called cap-Plasma-RecipentInfo.		We define a new SMIME-CAPS object called cap-Plasma-RecipentInfo.
	This attribute is identified by the the OID id-cap-plasma-		This attribute is identified by the the OID id-cap-plasma-
	recipientInfo and has no data structure associated with it. When		recipientInfo and has no data structure associated with it. When
	encoded as an S/MIME capability the parameters MUST to be absent and		encoded as an S/MIME capability the parameters MUST to be absent and
	not NULL.		not NULL.
	7. Manditory Algorithms		7. Mandatory Algorithms
	KEK manditory to implement algorithms - MUST AES-128 KEK Wrap.		7.1. Plasma Servers
	SHOULD AES-256 KEK wrap.
	Key Transport - MUST RSA v 1.5		Servers MUST implement AES-GCC-128 ([RFC5084]) for the content
			encryption algorithm in section 3.1. Other authenticated encryption
			algorithms MAY be implemented.
	Key Agreement - MUST EC-DH for group ...		Servers MUST implement RSA v1.5 as a key transport algorithm for
			lockboxes created in section 3.1 and for pre-authenticated lock boxes
			returned in step 8 of section 4.1. Servers SHOULD implement RSA OAEP
			as a key transport algorithm in the same locations. Other key
			transport algorithms MAY be implemented.
	Content Encryption - MUST AES-128.		Servers MUST implement EC-DH as a key agreement algorithm for
			lockboxes created in section 3.1 and for pre-authenticated lock boxes
			returned in step 8 of section 4.1. Servers MAY implement other key
			agreement algorithms.
			Servers MUST implement the RSA v1.5 signature algorithm with SHA-256
			and SHA-512. Servers MUST implement the EC-DSA signature algorithm
			with SHA-256 and SHA-512 for producing signature on the Plasma lock
			box. Other signature algorithms MAY be implemented as well.
			7.2. Plasma Clients
			Clients MUST implement the mandatory algorithms defined for S/MIME
			[SMIME-MSG] for the lock boxes created in step 7 and transmitted to
			the server in step 8 of Section 4. Other algorithms MAY be
			implemented.
			Clients MUST implement SHA-256 and SHA-512 for computation of the
			Plasma Encrypted Content Hash in section 3.4. Other algorithms MAY
			be implemented, but doing so can cause clients that do not implement
			this algorithm to not attempt to read the message.
			When verifying signatures on the Plasma lock boxes, clients MUST be
			able to verify the RSA v1.5 signature algorithm with SHA-256 and SHA-
			512. Clients MUST also be able to verify the EC-DSA signature
			algorithm with SHA-256 and SHA-512 signature algorithm. Clients MAY
			be able to verify other signature algorithms.
	8. Security Considerations		8. Security Considerations
	Man in the middle attack on the protocol from the sending agent to		Man in the middle attack on the protocol from the sending agent to
	the email policy server.		the email policy server.
	Man in the middle attack on the protocol from the receiving agent to		Man in the middle attack on the protocol from the receiving agent to
	the email policy server.		the email policy server.
			Still more expansion....
			The hash computed for the Plasma Encrypted Content Hash attribute has
			different security concerns that a hash used for signature
			computation. This hash value is used to get a degree of assurance
			that the encrypted content is associated with Plasma lock box. In
			the event that a collision exists, then the client will go and talk
			to the server to get a content encryption key when that key will not
			successfully decrypt the content. However this does not affect the
			privacy of the client as the client's decision to talk to the server
			is based on the URL(s) of the server and the validation of the
			server's signature. This means that an attacker that substitutes an
			encrypted content needs not only to have the hash of the encrypted
			content be correct, but the decrypted content needs to make sense.
			In order for an attacker to have the client talk to it, it needs to
			attack the certificates or signature produced on the lock box and not
			the encrypted content itself.
	9. IANA Considerations		9. IANA Considerations
	All of the object identifiers defined by this document are done so		All of the object identifiers defined by this document are done so
	under the existing S/MIME Object Identifier arc. No actions by IANA		under the existing S/MIME Object Identifier arc. No actions by IANA
	are required for this document.		are required for this document.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	skipping to change at page 28, line 33 ¶		skipping to change at page 26, line 33 ¶
	RFC 2634, June 1999.		RFC 2634, June 1999.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[SMIME-MSG]		[SMIME-MSG]
	Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet		Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
	Mail Extensions (S/MIME) Version 3.2 Message		Mail Extensions (S/MIME) Version 3.2 Message
	Specification", RFC 5751, January 2010.		Specification", RFC 5751, January 2010.
	[Plasma] Freeman, T., Schaad, J., and P. Patterson, "Requirements		[RFC5752] Turner, S. and J. Schaad, "Multiple Signatures in
			Cryptographic Message Syntax (CMS)", RFC 5752,
			January 2010.
			[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
			October 2008.
			[RFC5890] Klensin, J., "Internationalized Domain Names for
			Applications (IDNA): Definitions and Document Framework",
			RFC 5890, August 2010.
			[RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for
			Internationalized Email", RFC 6530, February 2012.
			[I.D-draft-freeman-plasma-requirements]
			Freeman, T., Schaad, J., and P. Patterson, "Requirements
	for Message Access Control", Work in		for Message Access Control", Work in
	progress draft-freeman-message-access-control,		progress draft-freeman-plasma-requirements, October 2011.
	October 2011.
	10.2. Informative References		10.2. Informative References
	[RFC3369] Housley, R., "Cryptographic Message Syntax (CMS)",		[RFC3369] Housley, R., "Cryptographic Message Syntax (CMS)",
	RFC 3369, August 2002.		RFC 3369, August 2002.
	[RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630,		[RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630,
	June 1999.		June 1999.
	[RFC4262] Santesson, S., "X.509 Certificate Extension for Secure/		[RFC4262] Santesson, S., "X.509 Certificate Extension for Secure/
	Multipurpose Internet Mail Extensions (S/MIME)		Multipurpose Internet Mail Extensions (S/MIME)
	Capabilities", RFC 4262, December 2005.		Capabilities", RFC 4262, December 2005.
	[eps-token]		[RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated
	Schaad, J., "Email Policy Service Trust Processing", Work		Encryption in the Cryptographic Message Syntax (CMS)",
	in progress draft-schaad-plasma-service, March 2012.		RFC 5084, November 2007.
			[plasma-token]
			Schaad, J., "Plasma Service Trust Processing", Work in
			progress draft-schaad-plasma-service, March 2012.
	[XACML] Rissanen, E., "eXtensible Access Control Markup Language		[XACML] Rissanen, E., "eXtensible Access Control Markup Language
	(XACML) Version 3.0", OASIS Standard xacml-201008,		(XACML) Version 3.0", OASIS Standard xacml-201008,
	August 2010, <http://docs.oasis-open.org/xacml/3.0/		August 2010, <http://docs.oasis-open.org/xacml/3.0/
	xacml-3.0-core-spec-cs-01.en.doc>.		xacml-3.0-core-spec-cs-01.en.doc>.
	Editorial Comments		Editorial Comments
	[anchor6] Trevor: We need to clarify that you can still use the		[anchor4] JLS: It is going to still be possible to do any
	existing recipient info structure for backward		correlation using the key identifier anymore? since we no
	compatibility. When that is appropriate is a matter of		longer support multiple keys in the base spec it may no
	local policy.		longer make sens. This means that this value is totally
			ignored.
	[anchor8] JLS: OPEN ISSUE: At one point there was a discussion that
	we would allow for multiple KEKs to be wrapped in a
	single object, you would then be able to retrieve server
	KEK values with the same label or with different labels
	at one shot. This would allow for multiple encrypted
	parts in a single message to have their keys wrapped and
	retrieved in one shot.
	[anchor9] trevor: OPEN ISSUE: Should we be using GeneralName so as
	to allow for name types other than email addresses.
	[anchor10] JLS: Do we want to change the type? What do we want to
	say about internationalization?
	[anchor11] JLS: We could add such an option if we desired.		[anchor5] JLS: Do we move this up a level given that the key
			encryption algorithm no longer exists as a real value.
	Appendix A. 2009 ASN.1 Module		Appendix A. 2009 ASN.1 Module
	PolicySMime -- TBD Get a module number --		PolicySMime -- TBD Get a module number --
	DEFINITIONS IMPLICIT TAGS ::=		DEFINITIONS IMPLICIT TAGS ::=
	BEGIN		BEGIN
	IMPORTS		IMPORTS
	-- Cryptographic Message Syntax (CMS) [RFC5652]		-- Cryptographic Message Syntax (CMS) [RFC5652]
	CONTENT-TYPE, RecipientInfo, KEY-ATTRIBUTE, SignedData,
	DigestAlgorithmIdentifier
	FROM CryptographicMessageSyntax-2010
	{ iso(1) member-body(2) us(840) rsadsi(113549)
	pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) }
	-- Common PKIX structures [RFC5912]
	SMIME-CAPS		CONTENT-TYPE, RecipientInfo, KEY-ATTRIBUTE, SignedData,
	FROM AlgorithmInformation-2009		DigestAlgorithmIdentifier
	{ iso(1) identified-organization(3) dod(6) internet(1)		FROM CryptographicMessageSyntax-2010
	security(5) mechanisms(5) pkix(7) id-mod(0)		{ iso(1) member-body(2) us(840) rsadsi(113549)
	id-mod-algorithmInformation-02(58)}		pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) }
	ATTRIBUTE, SingleAttribute{}		-- Common PKIX structures [RFC5912]
	FROM PKIX-CommonTypes-2009
	{ iso(1) identified-organization(3) dod(6) internet(1)
	security(5) mechanisms(5) pkix(7) id-mod(0)
	id-mod-pkixCommon-02(57) }
	ESSSecurityLabel		SMIME-CAPS
	FROM ExtendedSecurityServices-2009		FROM AlgorithmInformation-2009
	{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)		{ iso(1) identified-organization(3) dod(6) internet(1)
	smime(16) modules(0) id-mod-ess-2006-02(42) }		security(5) mechanisms(5) pkix(7) id-mod(0)
			id-mod-algorithmInformation-02(58)}
	id-cap		ATTRIBUTE, SingleAttribute{}
	FROM SecureMimeMessage		FROM PKIX-CommonTypes-2009
	{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)		{ iso(1) identified-organization(3) dod(6) internet(1)
	smime(16) modules(0) id-mod-msg-v3dot1-02(39) }		security(5) mechanisms(5) pkix(7) id-mod(0)
	;		id-mod-pkixCommon-02(57) }
	--		ESSSecurityLabel
	-- EPS Content Type		FROM ExtendedSecurityServices-2009
	--		{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
			smime(16) modules(0) id-mod-ess-2006-02(42) }
	ct-eps-LockBox CONTENT-TYPE ::= {		id-cap
	TYPE EPS-LockBox		FROM SecureMimeMessage
	IDENTIFIED BY id-ct-eps-LockBox		{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
	}		smime(16) modules(0) id-mod-msg-v3dot1-02(39) }
	id-ct-eps-LockBox OBJECT IDENTIFIER ::= {iso(1) member-body(2)		;
	us(840) rsadsi(113549) pkcs(1) pkcs7(7) TBD1}
	EPS-LockBox ::= SEQUENCE {		--
	label OneLabel,		-- PLASMA Content Type
	keyList KeyList,		--
	attrList AttributeList OPTIONAL
	}
	KeyList ::= SEQUENCE {		ct-plasma-LockBox CONTENT-TYPE ::= {
	namedRecipients [0] SEQUENCE SIZE (1..MAX) OF		TYPE PLASMA-LockBox
	NamedRecipient OPTIONAL,		IDENTIFIED BY id-ct-plasma-LockBox
	defaultRecipients [1] SEQUENCE SIZE (1..MAX) OF		}
	OneKek OPTIONAL		id-ct-plasma-LockBox OBJECT IDENTIFIER ::= {iso(1) member-body(2)
	}		us(840) rsadsi(113549) pkcs(1) pkcs7(7) TBD1}
	(WITH COMPONENTS {
	...,
	namedRecipients PRESENT
	} |
	WITH COMPONENTS {
	...,
	defaultRecipients PRESENT
	})
	NamedRecipient ::= SEQUENCE {		PLASMA-LockBox ::= SEQUENCE {
	recipient IA5String, -- name of the recipient		label UTF8String,
	kekValue SEQUENCE {		keyList KeyList,
	kekIdentifier OCTET STRING,		attrList AttributeList OPTIONAL
	keyValue RecipientInfo		}
	}
	}
	OneKek ::= SEQUENCE {		KeyList ::= SEQUENCE {
	kekIdentifier OCTET STRING,		namedRecipients [0] SEQUENCE SIZE (1..MAX) OF
	kekValue OCTET STRING		NamedRecipient OPTIONAL,
	}		defaultRecipients [1] SEQUENCE SIZE (1..MAX) OF
			OneCek OPTIONAL,
			...
			}
			(WITH COMPONENTS {
			...,
			namedRecipients PRESENT
			} |
			WITH COMPONENTS {
			...,
			defaultRecipients PRESENT
			})
	OneLabel ::= CHOICE {		NamedRecipient ::= SEQUENCE {
	andLabels [1] SEQUENCE SIZE (2..MAX) OF OneLabel,		recipientName UTF8String, -- name of the recipient
	orLabels [2] SEQUENCE SIZE (2..MAX) OF OneLabel,		keyIdentifier OCTET STRING OPTIONAL,
	exclude [3] SEQUENCE SIZE (2) OF OneLabel,		keyValue RecipientInfo,
	uriLeaf [4] SEQUENCE {		...
	policyId UTF8String,		}
	names SEQUENCE SIZE (1..MAX) OF
	IA5String OPTIONAL
	},
	oidLeaf [5] ESSSecurityLabel,
	...
	}		OneCek ::= SEQUENCE {
			keyPolicy UTF8String OPTIONAL,
			keyIdentifier [1] OCTET STRING OPTIONAL,
			keyValue OCTET STRING,
			...
			}
	AttributeList ::= SEQUENCE SIZE (1..MAX) OF		AttributeList ::= SEQUENCE SIZE (1..MAX) OF
	SingleAttribute{{EPSAttributes}}		SingleAttribute{{PLASMAAttributes}}
	EPSAttributes ATTRIBUTE ::= { ... }		PLASMAAttributes ATTRIBUTE ::= { ... }
	--		--
	-- New Other Key Attribute value for Plasma		-- New Other Key Attribute value for Plasma
	-- This structure holds the encrypted KEK value for the server		-- This structure holds the encrypted KEK value for the server
	-- and other signed attributes used by the client for checking		-- and other signed attributes used by the client for checking
	-- the structure applies in this case		-- the structure applies in this case
	--		--
	keyatt-eps-kek KEY-ATTRIBUTE ::= {		keyatt-plasma-kek KEY-ATTRIBUTE ::= {
	SignedData IDENTIFIED BY id-keyatt-eps-token		SignedData IDENTIFIED BY id-keyatt-plasma-token
	}		}
	id-keyatt-eps-token OBJECT IDENTIFIER ::= {iso(1) member-body(2)		id-keyatt-plasma-token OBJECT IDENTIFIER ::= {iso(1) member-body(2)
	us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBD2 }		us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBD2 }
	--		--
	-- Define the Signed Attribute to carry the		-- Define the Signed Attribute to carry the
	-- Email Policy Server URL		-- Email Policy Server URL
	--		--
	-- This attribute is added to the SignedAttributSet set of		-- This attribute is added to the SignedAttributSet set of
	-- attributes in [CMS-ASN]		-- attributes in [CMS-ASN]
	--		--
	aa-eps-url ATTRIBUTE ::= {		aa-plasma-url ATTRIBUTE ::= {
	TYPE UTF8String IDENTIFIED BY id-aa-eps-url		TYPE UTF8String IDENTIFIED BY id-aa-plasma-url
	}		}
	id-aa-eps-url OBJECT IDENTIFIER ::= { iso(1) member-body(2)		id-aa-plasma-url OBJECT IDENTIFIER ::= { iso(1) member-body(2)
	us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBD3}		us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBD3}
	--		--
	-- Define the Signed Attribute to carry the		-- Define the Signed Attribute to carry the
	-- hash of encrypted data		-- hash of encrypted data
	--		--
	-- This attribute is added to the SignedAttributeSet set of		-- This attribute is added to the SignedAttributeSet set of
	-- attributes in [CMS-ASN]		-- attributes in [CMS-ASN]
	--		--
	aa-eps-hash ATTRIBUTE ::= {		aa-plasma-econtent-hash ATTRIBUTE ::= {
	TYPE HashValue IDENTIFIED BY id-aa-eps-hash		TYPE HashValue IDENTIFIED BY id-aa-plasma-econtent-hash
	}		}
	id-aa-eps-hash OBJECT IDENTIFIER ::= {iso(1) member-body(2)
	us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBD4}
	HashValue ::= SEQUENCE {		id-aa-plasma-econtent-hash OBJECT IDENTIFIER ::= {iso(1) member-body(2)
	hashAlgorithm DigestAlgorithmIdentifier,		us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBD4}
	hashValue OCTET STRING
	}
	--		HashValue ::= SEQUENCE {
	-- Create an S/MIME capability for advertising that		hashAlgorithm DigestAlgorithmIdentifier,
	-- a client can understand the PLASMA recipient info		hashValue OCTET STRING
	-- structure information		}
	--
	cap-Plasma-RecipientInfo SMIME-CAPS ::= {		--
	IDENTIFIED BY id-cap-plasma-recipientInfo		-- Create an S/MIME capability for advertising that
	}		-- a client can understand the PLASMA recipient info
			-- structure information
			--
	id-cap-plasma-recipientInfo OBJECT IDENTIFIER ::= {		cap-Plasma-RecipientInfo SMIME-CAPS ::= {
	id-cap TBD5		IDENTIFIED BY id-cap-plasma-recipientInfo
	}		}
	END		id-cap-plasma-recipientInfo OBJECT IDENTIFIER ::= {
			id-cap TBD5
			}
			END
	Author's Address		Author's Address
	Jim Schaad		Jim Schaad
	Soaring Hawk Consulting		Soaring Hawk Consulting
	Email: ietf@augustcellars.com		Email: ietf@augustcellars.com
End of changes. 159 change blocks.
	677 lines changed or deleted		587 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/