One document matched: draft-schaad-plasma-cms-00.xml
<?xml version="1.0" encoding="UTF-8"?><?rfc linefile="1:eps.xml"?>
<!-- automatically generated by xml2rfc v1.35 on 2012-03-02T22:15:20Z -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- xml2rfc-processed-entity RFC2119 -->
<!-- xml2rfc-processed-entity RFC2630 -->
<!-- xml2rfc-processed-entity RFC3369 -->
<!-- xml2rfc-processed-entity RFC4262 -->
<!-- xml2rfc-processed-entity SMIME-REFS -->
<?rfc linefile="1:bibxml/smime.xml"?> <!-- xml2rfc-processed-entity ESS-BASE -->
<!-- xml2rfc-processed-entity CMS -->
<!-- xml2rfc-processed-entity CMS-ASN -->
<!-- xml2rfc-processed-entity CMS-AED -->
<!-- xml2rfc-processed-entity SMIME-MSG -->
<!-- xml2rfc-processed-entity AED-RANT -->
<!-- xml2rfc-processed-entity XOR-HASH -->
<!-- xml2rfc-processed-entity SMIMEv3-MSG -->
<!-- xml2rfc-processed-entity SMIME-MSG -->
<?rfc linefile="9:eps.xml"?>
<!-- xml2rfc-processed-entity EPS-WS-TRUST -->
<!-- xml2rfc-processed-entity EPS-ASN -->
<!-- xml2rfc-processed-entity EPS-CT -->
<!-- xml2rfc-processed-entity EPS-OKA -->
<!-- xml2rfc-processed-entity EPS-URL-ATTR -->
<!-- xml2rfc-processed-entity EPS-HASH-ATTR -->
<!-- xml2rfc-processed-entity EPS-SMIMECAP -->
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xlst' ?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc comments="yes"?>
<rfc category="std" docName="draft-schaad-plasma-cms-00" ipr="trust200902">
<front>
<title abbrev="PLASMA ASN.1">Plasma Service CMS Processing</title>
<author fullname="Jim Schaad" initials="J." surname="Schaad">
<organization>Soaring Hawk Consulting</organization>
<address>
<email>ietf@augustcellars.com</email>
</address>
</author>
<date/>
<abstract>
<t>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. In <xref target="EPS-WS-TRUST"/> a new model has been presented where a third party is used as the enforcement point of the label. This document provides the details needed to implement the new Plasma model in the CMS infrastructure.</t>
<t>Additional benefits of using the Plasma module include moving responsibility of building lock boxes to the server and determining, based on policy, who should be a message recipient.</t>
<t>The document describes and details how the encryption process is performed, defines a new lock box attribute to hold the information needed to valid the label and to obtain the keys needed to decrypt the message. The document does not cover the protocol between the client and the Plasma policy enforcement server.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>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 message, obtaining a valid public or group key for each recipient, applying a security label to a message, and sending the message. The recipient of a message is responsible for the enforcement of any security labels on a message. While this system works in theory, in practice it has some difficulties that have lead to problems in getting S/MIME mail widely deployed. This document is part of an effort to provide an alternative method of allocating the responsibilities above to different entities in an attempt to make the process work better.</t>
<t>In an Email Policy Service (PLASMA) deployment of S/MIME, the sender of the message is still responsible for determining the list of recipients for the message and determining the security label to be applied to the message, however the responsibility of obtaining valid keys for each recipient can be off-loaded to the Plasma server component. The recipient is no longer responsible for enforcement of the policy as this is off-loaded to the Plasma server component. Doing this allows for the following changes in behavior of the system:
<list style="symbols">
<t>The sender is no longer responsible for finding and validating the set of public keys used for the message. This simplifies the complexity of the sender and lowers the resources required by the sender. This is especially true when a large number of recipients is involved.</t>
<t>The set of recipients that can decrypt the message can be change dynamically after the message is sent, without resorting to a group keying strategy.</t>
<t>The enforcement of the policy is done centrally, this means that updates to the policy are instantaneous and the enforcement policy can be centrally audited.</t>
<t>The label enforcement is done before the message is decrypted, this means there are no concerns about the message contents being leaked by poor client implementations.</t>
<t>Many of the same components used in a web-based deployment of policy enforcement in a confederation can be used for e-mail based deployment of information. This includes using credentials other than X.509 certificates.</t>
</list>
</t>
<t>This document is laid out as follows:
<list style="symbols">
<t>In <xref target="model"/> a more complete description of the components involved in the model are discussed.</t>
<t>In <xref target="RI"/> is description the new ASN.1 structures that are used to carry the additional information, and the way that these structures are used in a recipient info structure.</t>
<t>In <xref target="sender"/> is a description of the modifications from the sender processing rules outlined in <xref target="SMIME-MSG"/>.</t>
<t>In <xref target="recipient"/> is a description of the modification from the recipient processing rules outlined in <xref target="SMIME-MSG"/>.</t>
</list>
</t>
<section title="Vocabulary">
<t>Some of the terms used in this document include:
<list style="hanging">
<t hangText="Authenticated Encryption with Additional Data (AEAD):"> Are a set of encryption algorithms where an authentication method stronger than the PKCS #1 packing method is used for authentication and, optionally, a set of unencrypted attribute values are included in the authentication step.</t>
<t hangText="Content Encryption Key (CEK):"> The symmetric key used to encryption the content of a message.</t>
<t hangText="Key Encryption Key (KEK):"> The encryption of a CEK by another key. This may be done by either a symmetric key or an asymmetric key.</t>
</list>
</t>
</section>
<section title="Requirements Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119"/>.</t>
</section>
</section>
<section title="Model" anchor="model">
<t>To be supplied from the problem statement document.</t>
<section title="Overview">
<t>To be supplied from the problem statement document.</t>
<figure align="center" title="Message Access Control Actors" anchor="fig1"><artwork>
(1)(2)(6)
(3)(5) +----------+ (7)
+------------|Sending |-------------+
| |Agent | |
(4) | +----------+ |
+----------+ +---------+
|Email | |Mail |
|Policy | |Transfer |
|Service | |Agent |
+----------+ +---------+
(4) | +----------+ |
| |Receiving | |
+------------|Agent |-------------+
(3)(5) +----------+ (1)
(2)(6)
</artwork></figure>
<t>List the boxes above and give some info about them.</t>
</section>
<section title="Sender">
<t>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 <xref target="fig1"/>. Talk about the expansion in section x.x</t>
<t>
<list style="numbers">
<t>This list needs to be re-done - it does not include early-binding issues.</t>
<t>The Sending Agent composes the message, determines the set of recipients and a policy label to be applied to the message.</t>
<t>The Sending Agent randomly creates a KEK.</t>
<t>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 <xref target="EPS-WS-TRUST"/>.</t>
<t>The Email Policy Service validates that the set of recipients, the sender and policy label are consistent.</t>
<t>The Email Policy Service returns an EPS-KEK attribute to the Sending Agent.</t>
<t>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.</t>
<t>The Sending Agent send the message to the Mail Transfer Agent using SMTP or a similar protocol.</t>
</list>
</t>
</section>
<section title="Recipient" anchor="model-recip">
<t>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 <xref target="fig1"/>. An expansion of this is covered in <xref target="recipient"/>. <cref source="Trevor">We need to clarify that you can still use the existing recipient info structure for backward compatibility. When that is appropriate is a matter of local policy.</cref></t>
<t>
<list style="numbers">
<t>The Receiving Agent obtains the message from a Mail Transfer Agent using IMAP, POP or similar protocol.</t>
<t>The Receiving Agent recognizes that a KEK recipient info with an EPS-KEK attribute exists and validates the attribute.</t>
<t>The Receiving Agent sends the KEK identifier and the EPS-KEK attribute along with other information to the Email Policy Service.</t>
<t>The Email Policy Service evaluates the policy label and the recipient information.</t>
<t>The Email Policy Service returns the KEK to the Receiving Agent.</t>
<t>The Receiving Agent decrypts the message and displays it to the user.</t>
</list>
</t>
</section>
</section>
<section title="Recipient Info Encoding" anchor="RI">
<t>This documents defines a new Other Key Attribute to be used in the KEK Recipient Info structure. There are two distinct ways that the problem of defining a new recipient info structure for Plasma could be approached. 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.</t>
<t>The use of a new recipient info structure would have been the easiest to document and implement, if most major CMS implementations had kept up with the latest versions. However it is known that several implementations stopped with RFC 2630 <xref target="RFC2630"/> and it was not until RFC 3369 <xref target="RFC3369"/> that the other recipient info choice was introduced along with the language stating that implementations need to gracefully handle unimplemented alternatives in the choice. This means that if a new recipient info structure was defined and adopted, the mail message would fail decoding for many recipients, even for those recipients that had a key transfer or key agreement recipient info structure. For this reason it was decided that the second option would be chosen.</t>
<t>The use of the KEKRecipeintInfo type may seem to be a stretch at first, it was defined for those situations where a symmetric key had already been distributed and either a specific key or a specific transformation on the key was to be applied in order to decrypt the KEK value. However, in the most generic situation, Plasma will distribute a symmetric key back to the client so the difference between the original usage and how Plasma uses it is when the 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.</t>
<t>The attribute is created only by a Plasma server and not by the client software. A protocol such as the one in RFC TBD1 <xref target="EPS-WS-TRUST"/> is used for clients to obtain the attribute from a Plasma server.</t>
<t>For the convenience of the reader we include the KEKRecipientInfo structure pieces here (copied from <xref target="CMS-ASN"/>:</t>
<figure><artwork>
KEKRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 4
kekid KEKIdentifier,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
KEKIdentifier ::= SEQUENCE {
keyIdentifier OCTET STRING,
date GeneralizedTime OPTIONAL,
other OtherKeyAttribute OPTIONAL }
OtherKeyAttribute ::= SEQUENCE {
keyAttrId KEY-ATTRIBUTE.
&id({SupportedKeyAttributes}),
keyAttr KEY-ATTRIBUTE.
&Type({SupportedKeyAttributes}{@keyAttrId})}
</artwork></figure>
<t> When you look at the KEKRecipientInfo structure you fill out the fields as follows:
<list style="hanging">
<t hangText="version">is set to the value of 4.</t>
<t hangText="kekid">is a sequence where the fields are:
<list style="hanging">
<t hangText="keyIdentifier">is a randomly generated value. The value is created without any internal semantics and should be unique 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.</t>
<t hangText="date">is not used and is omitted.</t>
<t hangText="other">is a sequence where the fields are:
<list style="hanging">
<t hangText="keyAttrId">contains the value id-keyatt-eps-token.</t>
<t hangText="keyAttr">contains a the value of the attribute. The details of this structure are covered in <xref target="eps-oka"/>.</t>
</list>
</t>
</list>
</t>
<t hangText="keyEncryptionAlgorithm">contains the identifier and the type information for the key encryption algorithm. The mandatory to implement algorithms are specified in section <xref target="algs"/>. This algorithm must be understandable by the sender of the message and by the recipient of the message, but it is not a requirement that the Plasma Server can process the algorithm.</t>
<t hangText="encryptedKey">contains the CEK encrypted by the KEK.</t>
</list>
</t>
<section title="EPS Other Key Attribute" anchor="eps-oka">
<t>The EPS Other Key Attribute functions as the lock box for the KEK used in encrypting the CEK. In addition to the KEK, the lock box also contains the information that is needed by the Email Policy Server to know the policy(s) applied to the encrypted data and possible parameters for the policy and for the client to validate that the lock box applies to the encrypted content.</t>
<t>The relevant section from the ASN.1 module which contains the content is:</t>
<?rfc linefile="1:ForDraft/eps-oak.incl"?><figure><artwork>
--
-- New Other Key Attribute value for Plasma
-- This structure holds the encrypted KEK value for the server
-- and other signed attributes used by the client for checking
-- the structure applies in this case
--
keyatt-eps-kek KEY-ATTRIBUTE ::= {
SignedData IDENTIFIED BY id-keyatt-eps-token
}
id-keyatt-eps-token OBJECT IDENTIFIER ::= {iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBD2 }
</artwork></figure>
<?rfc linefile="195:eps.xml"?>
<t>We define a new KEY-ATTRIBUTE called keyatt-eps-kek. This attribute is identified by the id-keyatt-eps-token. The data structure that is associated with this key attribute is the CMS SignedData structure. The CMS SignedData structure is used directly without a CMS ContentInfo structure wrapping it.</t>
<t>The SignedData structure fields are filled as follows (some less significant fields are omitted):
<list style="hanging">
<t hangText="encapContentInfo"> is a structure containing the fields:
<list style="hanging">
<t hangText="eContentType"> is id-envelopedData or id-ct-authEnvelopedData.</t>
<t hangText="eContent"> is CMS EnvelopedData or AuthEnvelopedData structure with the following fields:
<list style="hanging">
<t hangText="recipientInfos"> contains the lock box(s) for the Plasma servers(s) to get access to the encrypted data. There MUST NOT be recipient info structures added for any entity not trusted to correctly perform the policy decision processing. See below for some additional discussion on what lock boxes need to be created.</t>
<t hangText="encryptedContentInfo/authEncryptedContentInfo"> is a structure containing the following elements:
<list style="hanging">
<t hangText="contentType"> is id-ct-eps-LockBox.</t>
<t hangText="contentEncryptionAlgorithm"> contains the identifier and parameters for the content encryption algorithm. This algorithm only needs to be understood by the Plasma service.</t>b
<t hangText="encryptedContent"> contains the encrypted EPS LockBox content. Details on this type are in the next section.</t>
</list>
</t>
</list>
</t>
</list>
</t>
<t hangText="certificates"> SHOULD contain the set of certificates (up to but not including the trust anchor) needed to validate the set of signer info structures.</t>
<t hangText="signerInfos"> will contain one or more signer info structures. In each signature the signed attributes:
<list style="symbols">
<t>MUST contain the signing time, the message digest, the content type and the EPS url attributes.</t>
<t>MAY contain the ESS security label attribute.</t>
<t>other attributes can also be included.</t>
</list>
</t>
</list>
</t>
<t>When creating the recipient info structures for the EnvelopedData 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 the Email Policy Service. In the event that the service is distributed over multiple servers then multiple lock boxes may need to be created. One of the implications of the fact that the originator of the message is the only recipient is that, although the signing key needs to be contained in a certificate, there is no corresponding requirement that the encryption key needs to be in a certificate. Instead of using a certificate, a subject key identifier that is meaningful only to the Email Policy Service can be used.</t>
</section>
<section title="EPS Content Type">
<t>The inner content type for an EPS Other Key Attribute is an EPS Lockbox. This content is contained in an encrypted CMS object which is encrypted by and for the Plasma server itself, as such the contents and structure is known just to the Plasma server.</t>
<t>The relevant section from the ASN.1 module which defines this content is:</t>
<?rfc linefile="1:ForDraft/eps-ct.incl"?><figure><artwork>
--
-- EPS Content Type
--
ct-eps-LockBox CONTENT-TYPE ::= {
TYPE EPS-LockBox
IDENTIFIED BY id-ct-eps-LockBox
}
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,
keyList KeyList,
attrList AttributeList OPTIONAL
}
KeyList ::= SEQUENCE {
namedRecipients [0] SEQUENCE SIZE (1..MAX) OF
NamedRecipient OPTIONAL,
defaultRecipients [1] SEQUENCE SIZE (1..MAX) OF
OneKek OPTIONAL
}
(WITH COMPONENTS {
...,
namedRecipients PRESENT
} |
WITH COMPONENTS {
...,
defaultRecipients PRESENT
})
NamedRecipient ::= SEQUENCE {
recipient IA5String, -- name of the recipient
kekValue SEQUENCE {
kekIdentifier OCTET STRING,
keyValue RecipientInfo
}
}
OneKek ::= SEQUENCE {
kekIdentifier OCTET STRING,
kekValue OCTET STRING
}
OneLabel ::= CHOICE {
andLabels [1] SEQUENCE SIZE (2..MAX) OF OneLabel,
orLabels [2] SEQUENCE SIZE (2..MAX) OF OneLabel,
exclude [3] SEQUENCE SIZE (2) OF OneLabel,
uriLeaf [4] SEQUENCE {
policyId UTF8String,
names SEQUENCE SIZE (1..MAX) OF
IA5String OPTIONAL
},
oidLeaf [5] ESSSecurityLabel,
...
}
AttributeList ::= SEQUENCE SIZE (1..MAX) OF
SingleAttribute{{EPSAttributes}}
EPSAttributes ATTRIBUTE ::= { ... }
</artwork></figure>
<?rfc linefile="246:eps.xml"?>
<t>In the above ASN.1, the following items are defined:
<list style="hanging">
<t hangText="ct-eps-LockBox"> is a new CMS content type object, this object is added to the set of content type objects in ContentSet (defined in the ASN.1 module in <xref target="CMS-ASN"/>). The content type associates the object identifier id-ct-eps-LockBox with the data type EPS-LockBox.</t>
<t hangText="id-ct-eps-LockBox"> is the identifier defined for the new content type.</t>
<t hangText="EPS-LockBox"> is the new type defined for new content type. This is a sequence <cref source="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.</cref> with the following fields:
<list style="hanging">
<t hangText="label"> contains the policy label that is to be applied to the KEK values in the keyList field.</t>
<t hangText="keyList"> contains the KEK values.</t>
<t hangText="attrList"> contains a set of attributes which are considered as significant by the Plasma server internally.</t>
</list>
</t>
<t hangText="KeyList"> is a new type that contains the KEK values or the KeyRecipientInfo structures. This allows for messages to be sent with either early-binding, where a RecipientInfo structure is filled out for the receiving agent, or late-binding, where the KEK value is sent from the Plasma Service to the receiving agent. It is required that at least one of these fields is populated.
<list style="hanging">
<t hangText="namedRecipients"> contains the recipient info structures for individually identified recipients.<cref source="trevor">OPEN ISSUE: Should we be using GeneralName so as to allow for name types other than email addresses.</cref></t>
<t hangText="defaultRecipients"> contains the KEK keys for those recipients that are not individual identified with their own recipient info structures.</t>
</list>
</t>
<t hangText="NamedRecipient"> contains the information identifying a single named recipient along with the recipient info structures for that recipient.
<list style="hanging">
<t hangText="recipient"> contains the name of the name of the recipient in the form of an RFC2822 email address.</t>
<t hangText="kekValue"> contains the recipient info structure for the named recipient. The fields in the sequence are:
<list style="hanging">
<t hangText="kekIdentifier"> contains the value of the kek identifier in the message.</t>
<t hangText="keyValue"> contains a recipient info structure wrapping the CEK of the message.</t>
</list>
</t>
</list>
</t>
<t hangText="OneKek"> contains the information that defines a single KEK to be used. The sequence has the fields:
<list style="hanging">
<t hangText="kekIdentifier"> contains the identification value for the KEK. This value matches the KEKIdentifier.keyIdentifier value in the recipient info information.</t>
<t hangText="kekValue"> contains the KEK value.</t>
</list>
</t>
<t hangText="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 <xref target="extend"/>. The choices in the structure are:
<list style="hanging">
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="exclude">allows for two policies to be combined together such as 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.)</t>
<t hangText="uriLeaf">allows for the specification of a policy as a URI. If 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.<cref source="JLS">Do we want to change the type? What do we want to say about internationalization?</cref></t>
<t hangText="oidLeaf">allows for the specification of a policy as an object identifier. There is no option to provide for parameters. <cref source="JLS">We could add such an option if we desired.</cref></t>
</list>
</t>
<t hangText="AttributeList"> defines a structure where a set of attributes can be included.</t>
<t hangText="EPSAttributes"> defines an Object Set of attributes which can be included. The object set is intentionally open ended for later expansion. We currently do not define any items that go in this field.</t>
</list>
</t>
<section title="Label Extensibility" anchor="extend">
<t>The ASN.1 type OneLabel has been explicitly defined to allow for later extensibility. When a new element is added, it will be added with at the end of the choice with a different tag value. ASN.1 decoders need to following the current recommendations on dealing with extensibility. This means that when the decoder finds a new choice in this structure that is not part of the current syntax, the element should be treated as an unknown blob and returned to the caller as an unrecognized blob. This allows for the calling code to make the decision on how the unknown element is treated.</t>
<t>However the extensibility is not handled the same in all cases. Each of the four different cases is outlined below.</t>
<section title="Sender Composing">
<t>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.</t>
<t>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.</t>
</section>
<section title="Sender to Email Policy Service">
<t>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.</t>
</section>
<section title="Recipient to Email Policy Service">
<t>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 <xref target="XACML"/> uses in section 7.2.1. If the second option is chosen then the following rules are used:
<list style="hanging">
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="andLabels"> results in "Deny" if any input node is "Deny" or "Not Applicable". It results in "Permit" if all of the input nodes are "Permit". Otherwise it results in "Indeterminate".</t>
<t hangText="orLabels"> results in "Permit" if any input node is "Permit". It results in "Deny" if all nodes are either "Deny" or "Not Applicable". Otherwise it results in "Indeterminate".</t>
<t hangText="exclude"> results in "Deny" if the first element is "Deny" or if the second input is "Permit". It results in "Permit" if the first input is "Permit" and the second is "Deny". It results in "Not Applicable" if either element is "Not Applicable". Otherwise it results in "Indeterminate".</t>
</list>
If the final node results in "Permit", then access is granted. If 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.</t>
<t>Any future element that is added to the choice needs to define a similar rule to the set of rules above.</t>
</section>
<section title="Recipient User Agent Display">
<t>Recipient user agents may want to display the policy to the user. This policy may be communicated from the Email Policy Service to the recipient using the OneLabel ASN.1 structure or using a different type. The label has been successfully (or unsuccessfully) validated 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.</t>
</section>
</section>
</section>
<section title="EPS URL Authenticated Attribute">
<t>It is required that the name of the Email Policy Server be securely communicated to the message recipient. For this purpose a URL is 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 server.</t>
<t>The relevant section from the ASN.1 module for this attribute is:</t>
<?rfc linefile="1:ForDraft/eps-url-attr.incl"?><figure><artwork>
--
-- Define the Signed Attribute to carry the
-- Email Policy Server URL
--
-- This attribute is added to the SignedAttributSet set of
-- attributes in [CMS-ASN]
--
aa-eps-url ATTRIBUTE ::= {
TYPE UTF8String IDENTIFIED BY id-aa-eps-url
}
id-aa-eps-url OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBD3}
</artwork></figure>
<?rfc linefile="324:eps.xml"?>
<t>From this we can see the following:
<list>
<t>A new attribute aa-eps-url has been defined.</t>
<t>The OID value of id-aa-eps-url has been created to identify the new attribute.</t>
<t>The type of the value associated with the attribute is a UTF8String which contains the URL for the Email Policy Server. The URL defines both the destination server and the protocol to be used. When the schema for the URL is "https", then the protocol used is <xref target="eps-token"/></t>
<t>The new attribute is to appear only as a Signed Attribute in a SignedData structure. It is therefore to be added to the attribute set SignedAttributeSet in the update ASN.1 module contained in <xref target="CMS-ASN"/>.</t>
</list>
</t>
<t>The attribute structure defined for signed attributes allows for multiple values to be carried in a single attribute. For this 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 as there can be multiple Plasma servers that can be used to evaluate the policy. The order of URLs does not indicate any order of priority, any of the values may be used.</t>
<t>This attribute is only included in a SignedData object by an Email Policy Server. There are no processing rules for the sender of a message. The processing rules for a recipient can be found in <xref target="recipient"/>.</t>
</section>
<section title="EPS Encrypted Content Hash Attribute">
<t>For privacy reasons, it is highly desirable that the recipient of a message can validate that the Plasma lock box embedded in a message is associated with encrypted data it is attached to. For this reason, in addition to the requirement that a recipient validate the signature of the Plasma server over the lock box, a new attribute is defined which contains the hash of the encrypted content.</t>
<?rfc linefile="1:ForDraft/eps-hash-attr.incl"?><figure><artwork>
--
-- Define the Signed Attribute to carry the
-- hash of encrypted data
--
-- This attribute is added to the SignedAttributeSet set of
-- attributes in [CMS-ASN]
--
aa-eps-hash ATTRIBUTE ::= {
TYPE HashValue IDENTIFIED BY id-aa-eps-hash
}
id-aa-eps-hash OBJECT IDENTIFIER ::= {iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBD4}
HashValue ::= SEQUENCE {
hashAlgorithm DigestAlgorithmIdentifier,
hashValue OCTET STRING
}
</artwork></figure>
<?rfc linefile="338:eps.xml"?>
<t>The above ASN.1 fragment defines the following items:
<list style="hanging">
<t hangText="aa-eps-hash"> defines a new ATTRIBUTE object describing the encrypted content hash attribute. This attribute is always a signed object and is to be added to the SignedAttributeSet in the CMS ASN.1 mdoule contained in <xref target="CMS-ASN"/>.</t>
<t hangText="id-aa-eps-hash"> defines the unique identifier of the attribute.</t>
<t hangText="HashValue"> defines the data value to be associated with the attribute. The fields of this type are:
<list style="hanging">
<t hangText="hashAlgorithm"> contains the identifier and parameters of the hash function used.</t>
<t hangText="hashValue"> contains the value of the hash operation.</t>
</list>
</t>
</list>
</t>
<t>The hash is computed over the encrypted content, without including any of the ASN.1 wrapping around the content. Thus this value does not cover the content type identifier, the encryption algorithm and parameters or any authenticated attributes for AEAD algorithms.</t>
</section>
</section>
<section title="Sender Processing Rules" anchor="sender">
<section title="Flow">
<t>This is the set of processing steps that a sender needs to do (the order of the steps is not normative):
<list style="numbers">
<t>Sender Agent obtains the set of policies under which it can send a message.</t>
<t>Sender Agent composes the message content.</t>
<t>Sender Agent determines the policy label to be applied to the message.</t>
<t>Sender Agent determines the set of recipients for the message.</t>
<t>Sender Agent randomly creates the KEK.</t>
<t>Sender Agent randomly selects the content encryption algorithm (with input from the policies chosen) and randomly creates the CEK.</t>
<t>Sender Agent encrypts the content with the CEK and computes the encrypted hash value.</t>
<t>Sender Agent may optionally create lock boxes for one or more of the message recipients, for those recipients which are to be protected by the policy server.</t>
<t>Sender Agent transmits the KEK, the list of recipients, the set of recipient lock boxes, the encrypted hash value and the policy label to the EPS.</t>
<t>Sender Agent receives an EPS-KEK attribute from the policy server. If the policy validation fails then the sender agent cannot send the message under the current policy label.</t>
<t>Sender Agent verifies the signature on the signed data structure inside of the EPS-KEK attribute.
<list style="letters">
<t>Signature is current and passes cryptographic processing.</t>
<t>Signed attributes contains the EPS URL attribute, the EPS Encrypted Hash attribute and the attribute is consistent with the policy selected.</t>
<t>Other standard signature checks.</t>
</list>
</t>
<t>Sender Agent selects an appropriate content encryption algorithm and randomly generates a CEK and encrypts the message.</t>
<t>Sender Agent creates a KEK recipient info structure with the EPS-KEK attribute. Sender Agent also creates all other necessary recipient info structures (for recipients not protected by policy) including one itself if required.</t>
<t>Sender Agent finishes encoding the message and transmits it to the MTA.</t>p
</list>
</t>
</section>
</section>
<section title="Recipient Processing Rules" anchor="recipient">
<section title="Flow">
<t>In this section we expand on the list of actions that are <xref target="model-recip"/>. When looking at the validation steps that are given here, the results need to be the same but the order that the steps are taken can be different. As an example, it can make sense to do the policy check in step X before doing the signature validation as this would not require any network access.</t>
<t>This is the set of processing that the recipient needs to do:
<list style="numbers">
<t>The Receiving Agent obtains the message from a Mail Transfer Agent using IMAP, POP or a similar protocol.</t>
<t>The Receiving Agent recognizes that a KEK recipient info exists with an EPS-KEK attribute. It is recommended that the entire list of recipient info structures be checked for one that can be processed directly before processing this node.</t>
<t>The Receiving Agent validates the EPS-KEK attribute. The following steps need to be taken for validation.
<list style="letters">
<t>The signature on the SignedData structure is validated. If the validation fails then processing ends. If more than one SignerInfo element exists on the structure, then the validation succeeds and the signed attributes from that SignerInfo structure are used. The order of performing the validation of the SignerInfo structures may be influenced by the content of EPS URL attribute.</t>
<t>If an ESS security label attribute (<xref target="ESS-BASE"/>) is present, then it must be evaluated and processing ends if the security label processing fails or is denied.</t>
<t>The EPS URL attribute is absent, then processing fails.</t>
<t>The URL value in the EPS URL attribute is checked against local policy. If the check fails then processing fails. This check is performed so that information about the user is not given to random Email Policy Services.</t>
<t>The EPS Encrypted Hash attribute value is checked against the encrypted content. If this check fails then processing fails.</t>
</list>
</t>
<t>The recipient gathers the necessary identity and attribute statements, usual certificates or SASL statements.</t>
<t>The recipient establishing a secure connection to the Email Policy server and passes in the identity and attribute statements and receives back the KEK or lock box to allow it to obtain the CEK value.</t>
</list>
</t>
</section>
<section title="Reply and Forward Processing">
<t>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 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 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 using the same policy as they received it under. For this reason, the protocol used to communicate with the Plasma server will frequently return a single purpose policy that permits a recipient to reply to a message using the same policy as the original message.</t>
</section>
</section>
<section title="S/MIME Capability">
<t>The SMIMECapabilities attribute was defined by S/MIME in <xref target="SMIME-MSG"/> so that the abilities of a client can be advertised to the recipients of an S/MIME message. This information can be advertised either directly in an S/MIME message sent from a client to a recipient, or more indirectly by publishing the information in an LDAP directory <xref target="RFC4262"/>.</t>
<t>A new S/MIME capability is defined by this document so that a client can advertise to others that it understands how to deal with Plasma recipient information. The ASN.1 for this attribute is:</t>
<?rfc linefile="1:ForDraft/eps-smime-cap.incl"?><figure><artwork>
--
-- Create an S/MIME capability for advertising that
-- a client can understand the PLASMA recipient info
-- structure information
--
cap-Plasma-RecipientInfo SMIME-CAPS ::= {
IDENTIFIED BY id-cap-plasma-recipientInfo
}
id-cap-plasma-recipientInfo OBJECT IDENTIFIER ::= {
id-cap TBD5
}
</artwork></figure>
<?rfc linefile="410:eps.xml"?>
<t>We define a new SMIME-CAPS object called cap-Plasma-RecipentInfo. This attribute is identified by the the OID id-cap-plasma-recipientInfo and has no data structure associated with it. When encoded as an S/MIME capability the parameters MUST to be absent and not NULL.</t>
</section>
<section title="Manditory Algorithms" anchor="algs">
<t>KEK manditory to implement algorithms - MUST AES-128 KEK Wrap. SHOULD AES-256 KEK wrap.</t>
<t>Key Transport - MUST RSA v 1.5</t>
<t>Key Agreement - MUST EC-DH for group ...</t>
<t>Content Encryption - MUST AES-128.</t>
</section>
<section title="Security Considerations">
<t>Man in the middle attack on the protocol from the sending agent to the email policy server.</t>
<t>Man in the middle attack on the protocol from the receiving agent to the email policy server.</t>
</section>
<section title="IANA Considerations">
<t>All of the object identifiers defined by this document are done so under the existing S/MIME Object Identifier arc. No actions by IANA are required for this document.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc linefile="1:bibxml/reference.RFC.5911.xml"?>
<reference anchor="CMS-ASN">
<front>
<title>New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME</title>
<author initials='P.' surname='Hoffman' fullname='P. Hoffman'>
<organization /></author>
<author initials='J.' surname='Schaad' fullname='J. Schaad'>
<organization /></author>
<date year='2010' month='June' />
<abstract>
<t>The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes.</t></abstract></front>
<seriesInfo name='RFC' value='5911' />
<format type='TXT' octets='101576' target='http://www.rfc-editor.org/rfc/rfc5911.txt' />
</reference>
<?rfc linefile="429:eps.xml"?>
<?rfc linefile="1:bibxml/reference.RFC.5083.xml"?>
<reference anchor="CMS-AED">
<front>
<title>Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type</title>
<author initials='R.' surname='Housley' fullname='R. Housley'>
<organization /></author>
<date year='2007' month='November' />
<abstract>
<t>This document describes an additional content type for the Cryptographic Message Syntax (CMS). The authenticated-enveloped-data content type is intended for use with authenticated encryption modes. All of the various key management techniques that are supported in the CMS enveloped-data content type are also supported by the CMS authenticated-enveloped-data content type. [STANDARDS TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5083' />
<format type='TXT' octets='22810' target='http://www.rfc-editor.org/rfc/rfc5083.txt' />
</reference>
<?rfc linefile="430:eps.xml"?>
<?rfc linefile="1:bibxml3/reference.I-D.draft-eps-ws-trust.xml"?>
<reference anchor='EPS-WS-TRUST'>
<front>
<title>Using WS Trust as an EPS protocol</title>
<author initials='J' surname='Schaad' fullname='Jim Schaad'>
<organization />
</author>
<date month='December' day='17' year='2010' />
<abstract><t>New hash algorithms are being developed and these algorithms may include parameters. CMS has not currently defined any hash algorithms with parameters, but anecdotic evidence suggests that defining one could cause major problems. In this document we define just such an algorithm and describe how to use it so that we can run experiments to find out how bad including hash parameters will be.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-TBD' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-TBD' />
</reference>
<?rfc linefile="431:eps.xml"?>
<?rfc linefile="1:bibxml/reference.RFC.2634.xml"?>
<reference anchor='ESS-BASE'>
<front>
<title>Enhanced Security Services for S/MIME</title>
<author initials='P.' surname='Hoffman' fullname='Paul Hoffman'>
<organization>Internet Mail Consortium</organization>
<address>
<postal>
<street>127 Segre Place</street>
<city>Santa Cruz</city>
<region>CA</region>
<code>95060</code>
<country>US</country></postal>
<email>phoffman@imc.org</email></address></author>
<date year='1999' month='June' /></front>
<seriesInfo name='RFC' value='2634' />
<format type='TXT' octets='131153' target='http://www.rfc-editor.org/rfc/rfc2634.txt' />
</reference>
<?rfc linefile="432:eps.xml"?>
<?rfc linefile="1:bibxml/reference.RFC.2119.xml"?>
<reference anchor='RFC2119'>
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year='1997' month='March' />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
<list>
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
</t></list></t>
<t>
Note that the force of these words is modified by the requirement
level of the document in which they are used.
</t></abstract></front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='http://www.rfc-editor.org/rfc/rfc2119.txt' />
<format type='HTML' octets='17491' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5777' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>
<?rfc linefile="433:eps.xml"?>
<?rfc linefile="1:bibxml/reference.RFC.5751.xml"?>
<reference anchor="SMIME-MSG">
<front>
<title>Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification</title>
<author initials='B.' surname='Ramsdell' fullname='B. Ramsdell'>
<organization /></author>
<author initials='S.' surname='Turner' fullname='S. Turner'>
<organization /></author>
<date year='2010' month='January' />
<abstract>
<t>This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.2. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 3851. [STANDARDS TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5751' />
<format type='TXT' octets='98638' target='http://www.rfc-editor.org/rfc/rfc5751.txt' />
</reference>
<?rfc linefile="434:eps.xml"?>
<reference anchor="Plasma">
<front>
<title>Requirements for Message Access Control</title>
<author initials="T." surname="Freeman"/>
<author initials="J." surname="Schaad"/>
<author initials="P." surname="Patterson"/>
<date month="October" year="2011"/>
</front>
<seriesInfo name="Work in progress" value="draft-freeman-message-access-control"/>
</reference>
</references>
<references title="Informative References">
<?rfc linefile="1:bibxml/reference.RFC.3369.xml"?>
<reference anchor='RFC3369'>
<front>
<title>Cryptographic Message Syntax (CMS)</title>
<author initials='R.' surname='Housley' fullname='R. Housley'>
<organization /></author>
<date year='2002' month='August' /></front>
<seriesInfo name='RFC' value='3369' />
<format type='TXT' octets='113975' target='http://www.rfc-editor.org/rfc/rfc3369.txt' />
</reference>
<?rfc linefile="447:eps.xml"?>
<?rfc linefile="1:bibxml/reference.RFC.2630.xml"?>
<reference anchor='RFC2630'>
<front>
<title>Cryptographic Message Syntax</title>
<author initials='R.' surname='Housley' fullname='Russell Housley'>
<organization>SPYRUS</organization>
<address>
<postal>
<street>381 Elden Street</street>
<street>Suite 1120</street>
<city>Herndon</city>
<region>VA</region>
<code>20170</code>
<country>US</country></postal>
<email>housley@spyrus.com</email></address></author>
<date year='1999' month='June' />
<abstract>
<t>This document describes the Cryptographic Message Syntax. This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary messages.</t>
<t>The Cryptographic Message Syntax is derived from PKCS #7 version 1.5 as specified in . Wherever possible, backward compatibility is preserved; however, changes were necessary to accommodate attribute certificate transfer and key agreement techniques for key management.</t></abstract></front>
<seriesInfo name='RFC' value='2630' />
<format type='TXT' octets='128599' target='http://www.rfc-editor.org/rfc/rfc2630.txt' />
</reference>
<?rfc linefile="448:eps.xml"?>
<?rfc linefile="1:bibxml/reference.RFC.4262.xml"?>
<reference anchor='RFC4262'>
<front>
<title>X.509 Certificate Extension for Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities</title>
<author initials='S.' surname='Santesson' fullname='S. Santesson'>
<organization /></author>
<date year='2005' month='December' />
<abstract>
<t>This document defines a certificate extension for inclusion of Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities in X.509 public key certificates, as defined by RFC 3280. This certificate extension provides an optional method to indicate the cryptographic capabilities of an entity as a complement to the S/MIME Capabilities signed attribute in S/MIME messages according to RFC 3851. [STANDARDS TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='4262' />
<format type='TXT' octets='9801' target='http://www.rfc-editor.org/rfc/rfc4262.txt' />
</reference>
<?rfc linefile="449:eps.xml"?>
<reference anchor="eps-token">
<front>
<title>Email Policy Service Trust Processing</title>
<author initials="J." surname="Schaad"/>
<date month="March" year="2012"/>
</front>
<seriesInfo name="Work in progress" value="draft-schaad-plasma-service"/>
</reference>
<reference anchor="XACML" target="http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-cs-01.en.doc">
<front>
<title>eXtensible Access Control Markup Language (XACML) Version 3.0</title>
<author initials="E" surname="Rissanen" role="Editor"/>
<date month="August" day='10' year='2010'/>
</front>
<seriesInfo name="OASIS Standard" value="xacml-201008"/>
<format type='HTML' target="http://docs.oasis-open.org/xacml/3.0/xacml03.0-core-spec-cs-01-en.html"/>
</reference>
</references>
<section title="2009 ASN.1 Module">
<?rfc linefile="1:ForDraft/eps.incl"?><figure><artwork>
PolicySMime -- TBD Get a module number --
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
IMPORTS
-- 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
FROM AlgorithmInformation-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58)}
ATTRIBUTE, SingleAttribute{}
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
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) }
id-cap
FROM SecureMimeMessage
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-msg-v3dot1-02(39) }
;
--
-- EPS Content Type
--
ct-eps-LockBox CONTENT-TYPE ::= {
TYPE EPS-LockBox
IDENTIFIED BY id-ct-eps-LockBox
}
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,
keyList KeyList,
attrList AttributeList OPTIONAL
}
KeyList ::= SEQUENCE {
namedRecipients [0] SEQUENCE SIZE (1..MAX) OF
NamedRecipient OPTIONAL,
defaultRecipients [1] SEQUENCE SIZE (1..MAX) OF
OneKek OPTIONAL
}
(WITH COMPONENTS {
...,
namedRecipients PRESENT
} |
WITH COMPONENTS {
...,
defaultRecipients PRESENT
})
NamedRecipient ::= SEQUENCE {
recipient IA5String, -- name of the recipient
kekValue SEQUENCE {
kekIdentifier OCTET STRING,
keyValue RecipientInfo
}
}
OneKek ::= SEQUENCE {
kekIdentifier OCTET STRING,
kekValue OCTET STRING
}
OneLabel ::= CHOICE {
andLabels [1] SEQUENCE SIZE (2..MAX) OF OneLabel,
orLabels [2] SEQUENCE SIZE (2..MAX) OF OneLabel,
exclude [3] SEQUENCE SIZE (2) OF OneLabel,
uriLeaf [4] SEQUENCE {
policyId UTF8String,
names SEQUENCE SIZE (1..MAX) OF
IA5String OPTIONAL
},
oidLeaf [5] ESSSecurityLabel,
...
}
AttributeList ::= SEQUENCE SIZE (1..MAX) OF
SingleAttribute{{EPSAttributes}}
EPSAttributes ATTRIBUTE ::= { ... }
--
-- New Other Key Attribute value for Plasma
-- This structure holds the encrypted KEK value for the server
-- and other signed attributes used by the client for checking
-- the structure applies in this case
--
keyatt-eps-kek KEY-ATTRIBUTE ::= {
SignedData IDENTIFIED BY id-keyatt-eps-token
}
id-keyatt-eps-token OBJECT IDENTIFIER ::= {iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBD2 }
--
-- Define the Signed Attribute to carry the
-- Email Policy Server URL
--
-- This attribute is added to the SignedAttributSet set of
-- attributes in [CMS-ASN]
--
aa-eps-url ATTRIBUTE ::= {
TYPE UTF8String IDENTIFIED BY id-aa-eps-url
}
id-aa-eps-url OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBD3}
--
-- Define the Signed Attribute to carry the
-- hash of encrypted data
--
-- This attribute is added to the SignedAttributeSet set of
-- attributes in [CMS-ASN]
--
aa-eps-hash ATTRIBUTE ::= {
TYPE HashValue IDENTIFIED BY id-aa-eps-hash
}
id-aa-eps-hash OBJECT IDENTIFIER ::= {iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBD4}
HashValue ::= SEQUENCE {
hashAlgorithm DigestAlgorithmIdentifier,
hashValue OCTET STRING
}
--
-- Create an S/MIME capability for advertising that
-- a client can understand the PLASMA recipient info
-- structure information
--
cap-Plasma-RecipientInfo SMIME-CAPS ::= {
IDENTIFIED BY id-cap-plasma-recipientInfo
}
id-cap-plasma-recipientInfo OBJECT IDENTIFIER ::= {
id-cap TBD5
}
END
</artwork></figure>
<?rfc linefile="470:eps.xml"?>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 07:26:10 |