Email Policy Service ASN.1 Processing
draft-schaad-eps-smime-00

Abstract

When using the Email Policy Service model, there exist the communications with the policy server which are based in XML and there are the communications which are S/MIME based and thus done in ASN.1. This document covers the ASN.1 requirements and the modifications in S/MIME processing needed to implement an Email Policy Service system.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This Internet-Draft will expire on July 25, 2011.

Copyright Notice

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1.  Introduction
    1.1.  Requirements Terminology
2.  Model
    2.1.  Overview
    2.2.  Sender
    2.3.  Recipient
3.  Recipient Info Encoding
    3.1.  EPS Other Key Attribute
    3.2.  EPS Content Type
        3.2.1.  Extensibility
        3.2.2.  Multiple KEKs
    3.3.  EPS URL Authenticated Attribute
4.  Sender Processing Rules
    4.1.  Flow
5.  Recipient Processing Rules
    5.1.  Flow
    5.2.  Reply and Forward Processing
6.  Policy Server Processing Rules
7.  Missing Pieces
    7.1.  Sender/Policy Server Protocol
    7.2.  Recipient/Policy Server Protocol
    7.3.  MLA/Policy Server Protocol
8.  Manditory Algorithms
9.  Security Considerations
10.  IANA Considerations
11.  Normative References
Appendix A.  2009 ASN.1 Module
§  Author's Address

1.  Introduction

In the traditional e-mail system, the sender of a message is responsible for determining the list of recipiemnts 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 responsiblities above to different entities in an attempt to make the process work better.

In an Email Policy Service deployment of S/MIME, the sender of the message is still responsible for determing the list of recipients for the message and determining the security label to be applied to the message, however the responsiblity of obtaining valid keys for each recipient is off-loaded to the policy server component. The recipient is no longer responible for enforcment of the policy as this is also off-loaded to the policy server component. Doing this allows for the following changes in behavior of the system:

• 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.
• The set of recipients that can decrypt the message can now be change dynamically after the message is sent, without resourting to a group keying stratigy.
• The enforcement of the policy is now done centrally, this means that updates to the policy are instantanous and the enforcement policy can be centerally audited.
• Since the label enforcement is done before the message is decrypted, there are no concerns about the message contents being leaked by poor client implemenations.
• 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 document is layed out as follows:

• In Section 2 (Model) a more complete discription of the components involved in the model are discussed.
• In Section 3 (Recipient Info Encoding) I describe 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.
• In Section 4 (Sender Processing Rules) I describe the modifications from the sender processing rules outlined in [SMIME‑MSG] (Ramsdell, B. and S. Turner, “Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification,” January 2010.).
• In Section 5 (Recipient Processing Rules) I describe the modification from the recipient processing rules outlined in [SMIME‑MSG] (Ramsdell, B. and S. Turner, “Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification,” January 2010.).

1.1.  Requirements Terminology

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 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

2.  Model

To be supplied from the problem statement document.

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)

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 (Message Access Control Actors). Talk about the expansion in section x.x

1. The Sending Agent composes the message, determines the set of recipients and a policy label to be applied to the message.
2. The Sending Agent randomly creates a KEK.
3. The Sending Agent transmits the KEK, the list of recipents and the policy label to the Email Policy Service. One possible protocol for this is [EPS‑WS‑TRUST] (Schaad, J., “Using WS Trust as an EPS protocol,” December 2010.).
4. The Email Policy Service validates that the set of recipients, the sender and policy label are consistant.
5. The Email Policy Service returns an EPS-KEK attribute to the Sending Agent.
6. 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.
7. The Sending Agent send the mesage to the Mail Transfer Agent using SMTP or a simliar protocol.

2.3.  Recipient

The general steps that need to be taken by a Reciving Agent for an EPS messaging system. The steps refer to the bottom half ov Figure 1 (Message Access Control Actors). An expansion of this is covered in Section 5 (Recipient Processing Rules).

1. The Recieving Agent obtains the message from a Mail Transfer Agent using IMAP, POP or simliar protocol.
2. The Recieving Agent recognizes that a KEK recipient info with an EPS-KEK attribute exists and validates the attribute.
3. The Recieving Agent sends the KEK idnetifer and the EPS-KEK attribute along with other information to the Email Policy Service.
4. The Email Policy Service evalutes the policy label and the recipient information.
5. The Email Policy Service returns the KEK to the Recieving Agent.
6. The Recieving Agent decrypts the message and displays it to the user.

3.  Recipient Info Encoding

When creating an Email Policy S/MIME message we use the Other Key Attribute field in the KEKRecipentInfo.kekid structure to hold the required information about how to find the KEK that is required to decrypt the message. For the convenience of the reader we include the KEKRecipientInfo structure and its pieces here:

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})}

When you look at the KEKRecipientInfo structure you fill out the fields as follows:

version

is set to the value of 4.

kekid

is a sequence where the fields are:

keyIdentifier

is a randomly generated value. The value is created without any internal symantics and should be unique within the message. It is suggested that the value be between 20 and 30 octets in length.

date

is not used and should be omitted.

other

is a sequence where the fields are:

keyAttrId

contains the value id-keyatt-eps-token.

keyAttr

contains a SignedData structure. The internal details of this data structure are covered in Section 3.1 (EPS Other Key Attribute).

keyEncryptionAlgorithm

contains the identifier and the type information for the key encryption algorithm. Section 8 (Manditory Algorithms) lays out the manditory algorithms. 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 Email Policy Server can process the algorithm.

encryptedKey

contains the content encryption key encrypted by the key encryption key.

3.1.  EPS Other Key Attribute

The EPS Other Key Attribute functions as the lock box for the key encryption key used in encrypting the content encryption key. 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.

The relevant section from the ASN.1 module which contains the content is:

   --
   --
   --

   keyatt-eps-kek KEY-ATTRIBUTE ::= {
      SignedData IDENTIFIED BY id-keyatt-eps-token
   }

   id-keyatt-eps-token OBJECT IDENTIFIER ::= {1 1 1 1 2}

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 assocated with this key attribute is the CMS SignedData structure.

When you look at the SignedData structure, the fields are filled in as follows (some less signficant fields are omitted):

encapContentInfo

is a structure containing the fields:

eContentType

is id-envelopedData.

eContent

is CMS EnvelopedData structure with the following fields:

recipientInfos

contains the lock box for the Email Policy Server to get access to the data encrypted in this object. See below for some additional dicussion on what lock boxes need to be created.

encryptedContentInfo

is a structure containing the following elements:

contentType

is id-ct-eps-LockBox.

contentEncryptionAlgorithm

contains the identifier and parameters for the content encryption algorithm. This algorithm only needs to be understood by the Email Policy Service.

encryptedContent

contains the encrypted EPS LockBox content. Details on this type are in the next section.

certificates

SHOULD contain the set of certificates (up to but not including the trust anchor) needed to validate the set of signer info structures.

signerInfos

will contain one or more signer info structures. In each signature the signed attributes:

MUST contain the signing time, the message digest, the content type and the EPS url attributes.

MAY contain the ESS security label attribute.

other attributes can also be included.

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 identifer that is meaningful only to the Email Policy Service can be used.

3.2.  EPS Content Type

The innermost content type for an EPS Other Key Attribute is always an EPS Lockbox. This content is always contained in an encrypted CMS object which is encrypted for the Email Policy server itself, as such the contents and structure is known just to the EPS server.

The relevant section from the ASN.1 module which devines this content is:

   --
   --  EPS Content Type
   --

   ct-eps-LockBox CONTENT-TYPE ::= {
       TYPE EPS-LockBox
       IDENTIFIED BY id-ct-eps-LockBox
   }

   id-ct-eps-LockBox OBJECT IDENTIFIER ::= {1 1 1 1}

   EPS-LockBox ::= SEQUENCE {
      label        OneLabel,
      keyList      KeyList
   }

   KeyList ::= SEQUENCE {
      namedRecipients    [0] SEQUENCE SIZE (1..MAX) OF
                                NamedRecipient OPTIONAL,
      defaultRecipients  [1] SEQUENCE SIZE (1..MAX) OF
                                OneKek OPTIONAL
   }

   NamedRecipient ::= SEQUENCE {
      recipient    IA5String, -- name of the recipient
      kekValues    SEQUENCE SIZE (1..MAX) OF 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,
        ...
   }

In the above ASN.1, the following items are defined:

ct-eps-LockBox

is a new CMS content type object, this object is to be added to the conten type object set ContentSet in [CMS‑ASN] (Hoffman, P. and J. Schaad, “New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME,” June 2010.).

id-ct-eps-LockBox

is the identifier defined for the new content type.

EPS-LockBox

is the new type defined for new content type. This is a sequence [anchor6] (JLS: I wonder if this should be a sequence of rather than a sequence so that you can define multiple KEK values each with a different label on it as well as a set of KEKs that have a single common label.) with the following fields:

label

contains the policy label that is to be applied to the KEK values in the keyList field.

keyList

contains the KEK values.

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 recieving agent, or late-binding, where the KEK value is sent from the Email Policy Service to the recieving agent.

namedRecipients

contains the recipient info structures for individually identified recipients.

defaultRecipients

contains the KEK keys for those recipients that are not individual identified with their own recipient info structures.

NamedRecipient

contains the information identifying a single named recpient along with the recipient info structures for that recipient.

recipient

contains the name of the name of the recipient in the form of an RFC2822 email address.

kekValues

contains the recipient info structures for the named recipient. The information is contained in a sequence of values, one for each possible encrypted block. The fields in the sequence are:

kekIdentifier

contains the value of the kek identifier in the message.

keyValue

contains a recpient info structure wrapping the CEK of the message.

OneKek

contains the information that defines a single KEK to be used. The sequence has the fields:

kekIdentifier

contains the identification value for the KEK. This value matches the KEKIdentifier.keyIdentifier value in the recipient info information.

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 extensisbility should be handled is in Section 3.2.1 (Extensibility). 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 elementsin the combined statement.

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

uriLeaf

allows for the specifiction 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.[anchor7] (JLS: Do we want to change the type? What do we want to say about internaltionalization?)

oidLeaf

allows for the specifiction of a policy as an object identifier. THere is no option to provide for parameters. [anchor8] (JLS: We could add such an option if we desired.) An unrecognized policy to evaluated as fails.

3.2.1.  Extensibility

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.

However the extensisiblity 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 flexiblity.

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 protoocl (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 contiains 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.

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 way s of doing this evaluation. The first option is to say that if an unknown node is found, then the policy evaluation fails for all cases. The second option is to try and evaluation the policy, but to do so in a conserative manner. If the second option is chosen then the following rules are used:

uriLeaf

results in true, false or unknown. The unknown state results if the policy is unknown or cannot currently be evaluated.

oidLeaf

results in true, false or unknown. The unknown state results if the policy is unknown or cannot currently be evaluated.

andLabels

results in false if any input node is false. It results in true if all of the input nodes are true. Otherwise it results in unknown.

orLabels

results in unknown if any input node is unknown. It results in true if any node is true and no nodes are unknown. Otherwise it results in false.

exclude

results in false if the second input is true or unknown. It results in true if the first input is true and the second is false. Otherwise it results in unknown.

If the final node results in true, then access is gracted. If the final result is either false or unknown then access is denied. Any future element that is added to the choice needs to define a similar rule to the set of rules above.

3.2.1.4.  Recipient User Agent Display

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.

3.2.2.  Multiple KEKs

Discuss cases where multiple KEKs are placed in the message.

3.3.  EPS URL Authenticated Attribute

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, but also additional parameters that can be used to identify a specific service on the server.

The relevent section from the ASN.1 module for this attribute is:

   --
   --  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 ::= {1 1 1 1 1 3}

From this we can see the following:

A new attribute aa-eps-url has been defined.

The OID value of id-aa-eps-url has been created to identify the new attribute.

The type of the value associated with the attribute is a UTF8String which contains the URL for the Email Policy Server. [anchor15] (jls: It might be that we should use IA5String for this depending on how you feel about the ability to include i18n strings in the domain name. I.e. should it be done before it is placed here or afterwords?)[anchor16] (jls: Do we care about allowing things other than http here? For example should these be specified as soap:... URIs?)

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 [CMS‑ASN] (Hoffman, P. and J. Schaad, “New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME,” June 2010.).

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.

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 Section 5 (Recipient Processing Rules).

4.  Sender Processing Rules

4.1.  Flow

This is the set of processing steps that a sender needs to do:

1. Sender Agent obtains the set of policies under which it can send a message.
2. Sender Agent composes the message content.
3. Sender Agent determines the policy label to be applied to the message.
4. Sender Agent determines the set of recipients for the message.
5. Sender Agent randomly creates the KEK.
6. Sender Agent transmits the KEK, the list of recipients and the policy label to the EPS.
7. Sender Agent recieves 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.
8. Sender Agent verifies the signature on the signed data structure inside of the EPS-KEK attribute.
   1. Signature is current and passes cryptographic processing.
   2. Signed attributes contains the EPS URL attribute, and the attribute is consistant with the policy selected.
   3. Other checks
9. Sender Agent selects an appropriate content encryption algorithm and randomly generates a CEK and encrypts the message.
10. Sender Agent creates a KEK recipient info structure with the EPS-KEK attribute. Sender Agent also creates all other necessary recipient info structures including one itself if required.
11. Sender Agent finishs encoding the message and transmits it to the MTA.

5.  Recipient Processing Rules

5.1.  Flow

In this section we expand on the list of actions that are Section 2.3 (Recipient). 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.

This is the set of processing that the recipient needs to do:

1. The Recieving Agent obtains the message from a Mail Transfer Agent using IMAP, POP or a similar protocol.
2. The Recieving 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.
3. The Recieving Agent validates the EPS-KEK attribute. THe following steps need to be taken for validation.

   A.

   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.

   B.

   If an ESS security label attribute ([ESS‑BASE] (Hoffman, P., “Enhanced Security Services for S/MIME,” June 1999.)) is present, then it must be evaluated and processing ends if the security label processing fails or is denied.

   C.

   The EPS URL attribute is absent, then processing fails.

   D.

   The URL value in the EPS URL attribute is checked againist 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.

   E.

   ...Other steps....

4. The recipient gathers the necessary identity and attribute statements, usual certificates or SASL statements. [anchor19] (JLS: At the present we don't give any idea of how this is to be done.)
5. The recipient establishing a secure connection to the Email Policy server and passes in the identity and attribute statements.

5.2.  Reply and Forward Processing

Cover the fact that a token should be returned when a message is read so that a reply message can be sent even if they do not normally have permission to send a message.

6.  Policy Server Processing Rules

7.  Missing Pieces

7.1.  Sender/Policy Server Protocol

7.2.  Recipient/Policy Server Protocol

7.3.  MLA/Policy Server Protocol

8.  Manditory Algorithms

KEK manditory to implement algorithms - MUST AES-128 KEK Wrap. SHOULD AES-256 KEK wrap.

Key Transport - MUST RSA v 1.5

Key Agreement - MUST EC-DH for group ...

Content Encryption - MUST AES-128.

9.  Security Considerations

Man in the middle attack on the protocol from the sending agent to the email policy server.

Man in the middle attack on the protocol from the recieving agent to the email policy server.

10.  IANA Considerations

No action by IANA is required for this document.

11. Normative References

Editorial Comments

Appendix A.  2009 ASN.1 Module

PolicySMime -- TBD Get a module number --
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
  IMPORTS
   -- Cryptographic Message Syntax (CMS) [RFC5652]

   CONTENT-TYPE, RecipientInfo, KEY-ATTRIBUTE, SignedData
   FROM  CryptographicMessageSyntax-2009
     { iso(1) member-body(2) us(840) rsadsi(113549)
       pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2004-02(41) }

   -- Common PKIX structures [RFC5912]

   ATTRIBUTE
   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) }

   ;

   --
   --  EPS Content Type
   --

   ct-eps-LockBox CONTENT-TYPE ::= {
       TYPE EPS-LockBox
       IDENTIFIED BY id-ct-eps-LockBox
   }

   id-ct-eps-LockBox OBJECT IDENTIFIER ::= {1 1 1 1}

   EPS-LockBox ::= SEQUENCE {
      label        OneLabel,
      keyList      KeyList
   }

   KeyList ::= SEQUENCE {
      namedRecipients    [0] SEQUENCE SIZE (1..MAX) OF
                                NamedRecipient OPTIONAL,
      defaultRecipients  [1] SEQUENCE SIZE (1..MAX) OF
                                OneKek OPTIONAL
   }

   NamedRecipient ::= SEQUENCE {
      recipient    IA5String, -- name of the recipient
      kekValues    SEQUENCE SIZE (1..MAX) OF 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,
        ...
   }

   --
   --
   --

   keyatt-eps-kek KEY-ATTRIBUTE ::= {
      SignedData IDENTIFIED BY id-keyatt-eps-token
   }

   id-keyatt-eps-token OBJECT IDENTIFIER ::= {1 1 1 1 2}

   --
   --  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 ::= {1 1 1 1 1 3}

END

Author's Address