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]