[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01

Network Working Group                                          J. Schaad
Internet-Draft                                   Soaring Hawk Consulting
Intended status: Standards Track                        January 18, 2011
Expires: July 22, 2011


                 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 22, 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



Schaad                    Expires July 22, 2011                 [Page 1]


Internet-Draft                  EPS ASN.1                   January 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 July 22, 2011                 [Page 2]


Internet-Draft                  EPS ASN.1                   January 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 July 22, 2011                 [Page 3]


Internet-Draft                  EPS ASN.1                   January 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 July 22, 2011                 [Page 4]


Internet-Draft                  EPS ASN.1                   January 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 July 22, 2011                 [Page 5]


Internet-Draft                  EPS ASN.1                   January 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 July 22, 2011                 [Page 6]


Internet-Draft                  EPS ASN.1                   January 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 July 22, 2011                 [Page 7]


Internet-Draft                  EPS ASN.1                   January 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 July 22, 2011                 [Page 8]


Internet-Draft                  EPS ASN.1                   January 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 July 22, 2011                 [Page 9]


Internet-Draft                  EPS ASN.1                   January 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 July 22, 2011                [Page 10]


Internet-Draft                  EPS ASN.1                   January 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 July 22, 2011                [Page 11]


Internet-Draft                  EPS ASN.1                   January 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 July 22, 2011                [Page 12]


Internet-Draft                  EPS ASN.1                   January 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 July 22, 2011                [Page 13]


Internet-Draft                  EPS ASN.1                   January 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 July 22, 2011                [Page 14]


Internet-Draft                  EPS ASN.1                   January 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 July 22, 2011                [Page 15]


Internet-Draft                  EPS ASN.1                   January 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 July 22, 2011                [Page 16]


Internet-Draft                  EPS ASN.1                   January 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 July 22, 2011                [Page 17]


Internet-Draft                  EPS ASN.1                   January 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 July 22, 2011                [Page 18]


Internet-Draft                  EPS ASN.1                   January 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 July 22, 2011                [Page 19]


Internet-Draft                  EPS ASN.1                   January 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 July 22, 2011                [Page 20]


Internet-Draft                  EPS ASN.1                   January 2011


6.  Policy Server Processing Rules


















































Schaad                    Expires July 22, 2011                [Page 21]


Internet-Draft                  EPS ASN.1                   January 2011


7.  Missing Pieces

7.1.  Sender/Policy Server Protocol

7.2.  Recipient/Policy Server Protocol

7.3.  MLA/Policy Server Protocol












































Schaad                    Expires July 22, 2011                [Page 22]


Internet-Draft                  EPS ASN.1                   January 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 July 22, 2011                [Page 23]


Internet-Draft                  EPS ASN.1                   January 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 July 22, 2011                [Page 24]


Internet-Draft                  EPS ASN.1                   January 2011


10.  IANA Considerations

   No action by IANA is required for this document.
















































Schaad                    Expires July 22, 2011                [Page 25]


Internet-Draft                  EPS ASN.1                   January 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 July 22, 2011                [Page 26]


Internet-Draft                  EPS ASN.1                   January 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 July 22, 2011                [Page 27]


Internet-Draft                  EPS ASN.1                   January 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 July 22, 2011                [Page 28]


Internet-Draft                  EPS ASN.1                   January 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 July 22, 2011                [Page 29]


Internet-Draft                  EPS ASN.1                   January 2011


        TYPE UTF8String IDENTIFIED BY id-aa-eps-url
     }

     id-aa-eps-url OBJECT IDENTIFIER ::= {1 1 1 1 1 3}

  END













































Schaad                    Expires July 22, 2011                [Page 30]


Internet-Draft                  EPS ASN.1                   January 2011


Author's Address

   Jim Schaad
   Soaring Hawk Consulting

   Email: ietf@augustcellars.com













































Schaad                    Expires July 22, 2011                [Page 31]


Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/