Network Working Group J. Schaad Internet-Draft Soaring Hawk Consulting Intended status: Standards Track July 26, 2011 Expires: January 27, 2012 Email Policy Service ASN.1 Processing draft-schaad-eps-smime-01 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 January 27, 2012. 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 Schaad Expires January 27, 2012 [Page 1] Internet-Draft EPS ASN.1 July 2011 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Terminology . . . . . . . . . . . . . . . . . 4 2. Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Sender . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Recipient . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Recipient Info Encoding . . . . . . . . . . . . . . . . . . . 7 3.1. EPS Other Key Attribute . . . . . . . . . . . . . . . . . 8 3.2. EPS Content Type . . . . . . . . . . . . . . . . . . . . . 9 3.2.1. Extensibility . . . . . . . . . . . . . . . . . . . . 14 3.2.2. Multiple KEKs . . . . . . . . . . . . . . . . . . . . 16 3.3. EPS URL Authenticated Attribute . . . . . . . . . . . . . 16 4. Sender Processing Rules . . . . . . . . . . . . . . . . . . . 18 4.1. Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5. Recipient Processing Rules . . . . . . . . . . . . . . . . . . 19 5.1. Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.2. Reply and Forward Processing . . . . . . . . . . . . . . . 20 6. Policy Server Processing Rules . . . . . . . . . . . . . . . . 21 7. Missing Pieces . . . . . . . . . . . . . . . . . . . . . . . . 22 7.1. Sender/Policy Server Protocol . . . . . . . . . . . . . . 22 7.2. Recipient/Policy Server Protocol . . . . . . . . . . . . . 22 7.3. MLA/Policy Server Protocol . . . . . . . . . . . . . . . . 22 8. Manditory Algorithms . . . . . . . . . . . . . . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 11. Normative References . . . . . . . . . . . . . . . . . . . . . 26 Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . . Appendix A. 2009 ASN.1 Module . . . . . . . . . . . . . . . . . . 28 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 31 Schaad Expires January 27, 2012 [Page 2] Internet-Draft EPS ASN.1 July 2011 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: o 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. o 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. o 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. o 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. 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 deployment of information. This document is layed out as follows: o In Section 2 a more complete discription of the components involved in the model are discussed. Schaad Expires January 27, 2012 [Page 3] Internet-Draft EPS ASN.1 July 2011 o In Section 3 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. o In Section 4 I describe the modifications from the sender processing rules outlined in [SMIME-MSG]. o In Section 5 I describe the modification from the recipient processing rules outlined in [SMIME-MSG]. 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]. Schaad Expires January 27, 2012 [Page 4] Internet-Draft EPS ASN.1 July 2011 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) 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. 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]. 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. Schaad Expires January 27, 2012 [Page 5] Internet-Draft EPS ASN.1 July 2011 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. An expansion of this is covered in Section 5. 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. Schaad Expires January 27, 2012 [Page 6] Internet-Draft EPS ASN.1 July 2011 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. Schaad Expires January 27, 2012 [Page 7] Internet-Draft EPS ASN.1 July 2011 keyEncryptionAlgorithm contains the identifier and the type information for the key encryption algorithm. Section 8 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: Schaad Expires January 27, 2012 [Page 8] Internet-Draft EPS ASN.1 July 2011 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 Schaad Expires January 27, 2012 [Page 9] Internet-Draft EPS ASN.1 July 2011 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: Schaad Expires January 27, 2012 [Page 10] Internet-Draft EPS ASN.1 July 2011 -- -- 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, ... } Schaad Expires January 27, 2012 [Page 11] Internet-Draft EPS ASN.1 July 2011 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]. 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] 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. Schaad Expires January 27, 2012 [Page 12] Internet-Draft EPS ASN.1 July 2011 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. 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] oidLeaf allows for the specifiction of a policy as an object identifier. THere is no option to provide for parameters. [anchor8] An unrecognized policy to evaluated as fails. Schaad Expires January 27, 2012 [Page 13] Internet-Draft EPS ASN.1 July 2011 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. Schaad Expires January 27, 2012 [Page 14] Internet-Draft EPS ASN.1 July 2011 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. Schaad Expires January 27, 2012 [Page 15] Internet-Draft EPS ASN.1 July 2011 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][anchor16] 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]. 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. Schaad Expires January 27, 2012 [Page 16] Internet-Draft EPS ASN.1 July 2011 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. Schaad Expires January 27, 2012 [Page 17] Internet-Draft EPS ASN.1 July 2011 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. Schaad Expires January 27, 2012 [Page 18] Internet-Draft EPS ASN.1 July 2011 5. Recipient Processing Rules 5.1. Flow In this section we expand on the list of actions that are Section 2.3. 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]) 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] Schaad Expires January 27, 2012 [Page 19] Internet-Draft EPS ASN.1 July 2011 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. Schaad Expires January 27, 2012 [Page 20] Internet-Draft EPS ASN.1 July 2011 6. Policy Server Processing Rules Schaad Expires January 27, 2012 [Page 21] Internet-Draft EPS ASN.1 July 2011 7. Missing Pieces 7.1. Sender/Policy Server Protocol 7.2. Recipient/Policy Server Protocol 7.3. MLA/Policy Server Protocol Schaad Expires January 27, 2012 [Page 22] Internet-Draft EPS ASN.1 July 2011 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. Schaad Expires January 27, 2012 [Page 23] Internet-Draft EPS ASN.1 July 2011 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. Schaad Expires January 27, 2012 [Page 24] Internet-Draft EPS ASN.1 July 2011 10. IANA Considerations No action by IANA is required for this document. Schaad Expires January 27, 2012 [Page 25] Internet-Draft EPS ASN.1 July 2011 11. Normative References [CMS-ASN] Hoffman, P. and J. Schaad, "New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, June 2010. [EPS-WS-TRUST] Schaad, J., "Using WS Trust as an EPS protocol", draft-TBD (work in progress), December 2010. [ESS-BASE] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634, June 1999. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [SMIME-MSG] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010. Schaad Expires January 27, 2012 [Page 26] Internet-Draft EPS ASN.1 July 2011 Editorial Comments [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. [anchor7] JLS: Do we want to change the type? What do we want to say about internaltionalization? [anchor8] JLS: We could add such an option if we desired. [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? [anchor19] JLS: At the present we don't give any idea of how this is to be done. Schaad Expires January 27, 2012 [Page 27] Internet-Draft EPS ASN.1 July 2011 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 Schaad Expires January 27, 2012 [Page 28] Internet-Draft EPS ASN.1 July 2011 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 ::= { Schaad Expires January 27, 2012 [Page 29] Internet-Draft EPS ASN.1 July 2011 TYPE UTF8String IDENTIFIED BY id-aa-eps-url } id-aa-eps-url OBJECT IDENTIFIER ::= {1 1 1 1 1 3} END Schaad Expires January 27, 2012 [Page 30] Internet-Draft EPS ASN.1 July 2011 Author's Address Jim Schaad Soaring Hawk Consulting Email: ietf@augustcellars.com Schaad Expires January 27, 2012 [Page 31]