draft-ietf-smime-seclabel-00.txt   draft-ietf-smime-seclabel-01.txt 
S/MIME Working Group Weston Nicolls S/MIME Working Group Weston Nicolls
INTERNET DRAFT Ernst & Young LLP INTERNET DRAFT Telenisus Corporation
Expires in six months December 1999 Expires in six months July 2000
Implementing Company Classification Policy Implementing Company Classification Policy
with the S/MIME Security Label with the S/MIME Security Label
<draft-ietf-smime-seclabel-00.txt> <draft-ietf-smime-seclabel-01.txt>
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of [RFC2026]. provisions of Section 10 of [RFC2026].
This document is an Internet-Draft. Internet-Drafts are working documents This document is an Internet-Draft. Internet-Drafts are working documents
of the Internet Engineering Task Force (IETF), its areas, and its working of the Internet Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working documents as groups. Note that other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at line 40 skipping to change at line 40
<<Comments are contained in angle brackets like this.>> <<Comments are contained in angle brackets like this.>>
1. Introduction 1. Introduction
This document discusses how company security policy for data classification can This document discusses how company security policy for data classification can
be mapped to the S/MIME classification label. Actual policies from 3 companies be mapped to the S/MIME classification label. Actual policies from 3 companies
are used to provide worked examples. are used to provide worked examples.
Security labels are an optional security service for S/MIME. A security label is Security labels are an optional security service for S/MIME. A security label is
a set of security information regarding the sensitivity of the content that is a set of security information regarding the sensitivity of the content that is
protected by S/MIME encapsulation. A security label can be a bound attribute of protected by S/MIME encapsulation. A security label can be included in the
the original message content, the encrypted body, or both. The syntax and signed attributes of any SignedData object. A security label attribute may be
processing rules for security labels are described in [ESS]. included in either the inner signature, outer signature, or both. The syntax
and processing rules for security labels are described in [ESS].
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT','SHOULD', The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT','SHOULD',
'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be
interpreted as described in [MUSTSHOULD]. interpreted as described in [MUSTSHOULD].
This draft is being discussed on the 'ietf-smime' mailing list. To join the This draft is being discussed on the 'ietf-smime' mailing list. To join the
list, send a message to <ietf-smime-request@imc.org> with the single word list, send a message to <ietf-smime-request@imc.org> with the single word
'subscribe' in the body of the message. Also, there is a Web site for the 'subscribe' in the body of the message. Also, there is a Web site for the
mailing list at <http://www.imc.org/ietf-smime>. mailing list at <http://www.imc.org/ietf-smime>.
skipping to change at line 90 skipping to change at line 91
- Rule based access control is based on policies that can be algorithmically - Rule based access control is based on policies that can be algorithmically
expressed. expressed.
- Identity based access control is based on a policy which applies explicitly - Identity based access control is based on a policy which applies explicitly
to an individual person or host entity, or to a defined group of such entities. to an individual person or host entity, or to a defined group of such entities.
Once identity has been authenticated, if the identity is verified to be on the Once identity has been authenticated, if the identity is verified to be on the
access list, then access is granted. access list, then access is granted.
- Rank base access control is based on a policy of hierarchical positions in an - Rank base access control is based on a policy of hierarchical positions in an
organization. A rank-based policy would define what information that the organization. It is based on who you are in the company structure. A rank-based
position of Partner or Senior Consultant could access. policy would define what information that the position of Partner or Senior
Consultant could access.
- Role based access control is based on a policy of hierarchical roles in an - Role based access control is based on a policy of roles in an organization.
organization. The role-based policy would define what information that the role It may or may not be hierarchical. It is based on who you are in the company.
of Executive, Vice President or Staff could access. The role-based policy would define what information that the role of Database
Administrator, Network Administrator, Mailroom Clerk or Purchaser could access.
Rule, rank and role-based access control methods can rely on a security label as Rule, rank and role-based access control methods can rely on a security label as
the security mechanism to convey the sensitivity or classification of the the security mechanism to convey the sensitivity or classification of the
information. When verifying an S/MIME encapsulated message, the sensitivity information. When verifying an S/MIME encapsulated message, the sensitivity
information in the messages security label can be compared with the recipient's information in the message's security label can be compared with the recipient's
authorizations to determine if the recipient is allowed to access the protected authorizations to determine if the recipient is allowed to access the protected
content. content.
An S/MIME security label may be included as an authenticated attribute in the An S/MIME security label may be included as an authenticated attribute in the
inner (or only) signature or the outer signature. The inner signature would be inner (or only) signature or the outer signature. The inner signature would be
used for access control decisions related to the plaintext original content, used for access control decisions related to the plaintext original content,
while he outer signature would be used for access control decisions related to while the outer signature would be used for access control decisions related to
the encrypted message. the encrypted message.
1.3 User Authorizations 1.3 User Authorizations
Users need to be granted authorizations to access information that has been Users need to be granted authorizations to access information that has been
classified by an authority. The sending and receiving agent need to be able to classified by an authority. The sending and receiving agent need to be able to
securely determine the users authorizations for access control processing. securely determine the user's authorizations for access control processing.
[X.509] and the Internet profile for X.509 certificates [CERTCRL] do not define [X.509] and the Internet profile for X.509 certificates [CERTCRL] do not define
the means to represent and convey authorizations in a certificate. the means to represent and convey authorizations in a certificate.
[X.501] defines how to represent authorization in the form of a clearance [X.501] defines how to represent authorization in the form of a clearance
attribute. The clearance attribute identifies the security policy in force to attribute. The clearance attribute identifies the security policy in force to
which a list of possible classifications and security categories relates. which a list of possible classifications and security categories relates.
[X.501] also notes two means for binding the clearance to a named entity: an [X.501] also notes two means for binding the clearance to a named entity: an
Attribute Certificate and a Certificate extension field (e.g., within the Attribute Certificate and a Certificate extension field (e.g., within the
skipping to change at line 144 skipping to change at line 147
2.1 Classification Policies 2.1 Classification Policies
The following describes the information classification policies in effect at 3 The following describes the information classification policies in effect at 3
companies. companies.
2.1.1 Amoco Corporation 2.1.1 Amoco Corporation
The description for the Amoco information classification policy was taken from The description for the Amoco information classification policy was taken from
the Amoco Computer Security Guidelines. Amoco classifies its information assets the Amoco Computer Security Guidelines. Amoco classifies its information assets
based on confidentiality and integrity and defines 3 hierarchical based on confidentiality and integrity and defines 3 hierarchical
classifications for each. classifications for each. The confidentiality and integrity polices are
independent, so either or both may be applied to the information. Amoco also
defines an availability classification for time critical information.
Highly Confidential - Information whose unauthorized disclosure will cause the HIGHLY CONFIDENTIAL - Information whose unauthorized disclosure will cause the
company severe financial, legal or reputation damage. Examples: Certain company severe financial, legal or reputation damage. Examples: Certain
acquisitions, bid economics, negotiation strategies. acquisitions, bid economics, negotiation strategies.
Confidential - Information whose unauthorized disclosure may cause the company CONFIDENTIAL - Information whose unauthorized disclosure may cause the company
financial, legal, or reputation damage. Examples: Employee Personnel & Payroll financial, legal, or reputation damage. Examples: Employee Personnel & Payroll
Files, some interpreted Exploration Data. Files, some interpreted Exploration Data.
General - Information that, because of its personal, technical, or business GENERAL - Information that, because of its personal, technical, or business
sensitivity is restricted for use within the company. Unless otherwise sensitivity is restricted for use within the company. Unless otherwise
classified, all information within Amoco is in this category. classified, all information within Amoco is in this category.
Maximum - Information whose unauthorized modification and destruction will cause MAXIMUM - Information whose unauthorized modification and destruction will cause
the company severe financial, legal, or reputation damage. the company severe financial, legal, or reputation damage.
Medium - Information whose unauthorized modification and destruction may cause MEDIUM - Information whose unauthorized modification and destruction may cause
the company financial, legal, or reputation damage. Examples: Electronic Funds, the company financial, legal, or reputation damage. Examples: Electronic Funds,
Transfer, Payroll, and Commercial Checks Transfer, Payroll, and Commercial Checks
Minimum - Although an error in this data would be of minimal consequence, this MINIMUM - Although an error in this data would be of minimal consequence, this
is still important company information and therefore will require some minimal is still important company information and therefore will require some minimal
controls to ensure a minimal level of assurance that the integrity of the data controls to ensure a minimal level of assurance that the integrity of the data
is maintained. This applies to all data that is not placed in one of the above is maintained. This applies to all data that is not placed in one of the above
classifications. Examples: Lease Production Data, Expense Data, Financial Data, classifications. Examples: Lease Production Data, Expense Data, Financial Data,
and Exploration Data. and Exploration Data.
CRITICAL - It is important to assess the availability requirements of data,
applications and systems. A business decision will be required to determine the
length of unavailability that can be tolerated prior to expending additional
resources to ensure the information availability that is required. Information
should be labeled "CRITICAL" if it is determined that special procedures should
be used to ensure its' availability.
2.1.2 Caterpillar, Inc. 2.1.2 Caterpillar, Inc.
The description for the Caterpillar information classification policy is taken The description for the Caterpillar information classification policy is taken
from the Caterpillar Information Protection Guidelines. Caterpillar classifies from the Caterpillar Information Protection Guidelines. Caterpillar classifies
its information assets based on confidentiality and defines 4 hierarchical its information assets based on confidentiality and defines 4 hierarchical
classifications. classifications.
Caterpillar Confidential Red - Provides a significant competitive advantage. Caterpillar Confidential Red - Provides a significant competitive advantage.
Disclosure would cause severe damage to operations. Relates to or describes a Disclosure would cause severe damage to operations. Relates to or describes a
long-term strategy or critical business plans. Disclosure would cause regulatory long-term strategy or critical business plans. Disclosure would cause regulatory
skipping to change at line 223 skipping to change at line 235
"All information generated by or for Whirlpool, in whatever form, written, "All information generated by or for Whirlpool, in whatever form, written,
verbal, or electronic, is to be treated as WHIRLPOOL INTERNAL or WHIRLPOOL verbal, or electronic, is to be treated as WHIRLPOOL INTERNAL or WHIRLPOOL
CONFIDENTIAL. Classification of information in either category depends on its CONFIDENTIAL. Classification of information in either category depends on its
value, the impact of unauthorized disclosure, legal requirements, and the manner value, the impact of unauthorized disclosure, legal requirements, and the manner
in which it needs to be used by the company. Some WHIRLPOOL INTERNAL in which it needs to be used by the company. Some WHIRLPOOL INTERNAL
information may be authorized for public release." information may be authorized for public release."
WHIRLPOOL CONFIDENTIAL - A subset of Whirlpool Internal information, the WHIRLPOOL CONFIDENTIAL - A subset of Whirlpool Internal information, the
unauthorized disclosure or compromise of which would likely have an adverse unauthorized disclosure or compromise of which would likely have an adverse
impact on the companys competitive position, tarnish its reputation, or impact on the company's competitive position, tarnish its reputation, or
embarrass an individual. Examples: Customer, financial, pricing, or personnel embarrass an individual. Examples: Customer, financial, pricing, or personnel
data; merger/acquisition, product, or marketing plans; new product designs, data; merger/acquisition, product, or marketing plans; new product designs,
proprietary processes and systems. proprietary processes and systems.
WHIRLPOOL INTERNAL - All forms of proprietary information originated or owned by WHIRLPOOL INTERNAL - All forms of proprietary information originated or owned by
Whirlpool, or entrusted to it by others. Examples: Organization charts, Whirlpool, or entrusted to it by others. Examples: Organization charts,
policies, procedures, phone directories, some types of training materials. policies, procedures, phone directories, some types of training materials.
WHIRLPOOL PUBLIC - Information officially released by Whirlpool for widespread WHIRLPOOL PUBLIC - Information officially released by Whirlpool for widespread
public disclosure. Example: Press releases, public marketing materials, public disclosure. Example: Press releases, public marketing materials,
skipping to change at line 267 skipping to change at line 279
2.2.1.1 Security Policy Identifier 2.2.1.1 Security Policy Identifier
A security policy is a set of criteria for the provision of security services. A security policy is a set of criteria for the provision of security services.
The eSSSecurityLabel security-policy-identifier is used to identify the security The eSSSecurityLabel security-policy-identifier is used to identify the security
policy in force to which the security label relates. It indicates the semantics policy in force to which the security label relates. It indicates the semantics
of the other security label components. of the other security label components.
For the example policies, the following security policy object identifiers are For the example policies, the following security policy object identifiers are
defined: defined:
<<Need to obtain test S/MIME OIDs.>> -- S/MIME Working Group Object Identifier Registry
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549)
Amoco security-policy-identifier ::= { } pkcs(1) pkcs-9(9) 16 }
Caterpillar security-policy-identifier ::= { } -- S/MIME Test Securty Policy Arc
id-tsp OBJECT IDENTIFIER ::= { id-smime 7 }
Whirlpool security-policy-identifier ::= { } -- Test Security Policies
id-tsp-TEST-Amoco OBJECT IDENTIFIER ::= { id-tsp 1 }
id-tsp-TEST-Caterpillar OBJECT IDENTIFIER ::= { id-tsp 2 }
id-tsp-test-Whirlpool OBJECT IDENTIFIER ::= { id-tsp 3 }
2.2.1.2 Security Classification 2.2.1.2 Security Classification
The security classification values and meanings are defined by the governing The security classification values and meanings are defined by the governing
company policies. The security-classification values defined are hierarchical company policies. The security-classification values defined are hierarchical
and do not use integers 0 through 5. and do not use integers 0 through 5.
Amoco-SecurityClassification ::= { Amoco-SecurityClassification ::= {
amoco general (6), amoco general (6),
amoco confidential (7), amoco confidential (7),
amoco highly confidential (8), amoco highly confidential (8) } (0..ub-integer-options)
amoco minimum (9),
amoco medium (10),
amoco maximum (11) } (0..ub-integer-options)
Caterpillar-SecurityClassification values ::= { Caterpillar-SecurityClassification values ::= {
caterpillar public (6), caterpillar public (6),
caterpillar green (7), caterpillar green (7),
caterpillar yellow (8), caterpillar yellow (8),
caterpillar red (9) } (0..ub-integer-options) caterpillar red (9) } (0..ub-integer-options)
Whirlpool-SecurityClassification values ::= { Whirlpool-SecurityClassification values ::= {
whirlpool public (6), whirlpool public (6),
whirlpool internal (7), whirlpool internal (7),
whirlpool confidential (8) } (0..ub-integer-options) whirlpool confidential (8) } (0..ub-integer-options)
2.2.1.3 Privacy Mark 2.2.1.3 Privacy Mark
Privacy marks are specified the Whirlpool policy. The policy provides examples Privacy marks are specified the Whirlpool policy. The policy provides examples
of possible marking but other can be defined by users as necessary. User of possible markings but other can be defined by users as necessary (though no
specified privacy marks are defined using the following syntax. guidance is given). The Whirlpool policy provides the following examples:
MAKE NO COPIES, THIRD PARTY CONFIDENTIAL, ATTORNEY-CLIENT PRIVILEGED DOCUMENT,
DISTRIBUTION LIMITED TO ____, and COVERED BY A NON-ANALYSIS AGREEMENT.
<<Need to develop the syntax. Suggestions?>> The Amoco policy does not identify any privacy marks but the classification
labels defined for availability and integrity would be most appropriately
displayed here. The CRITICAL, MAXIMUM, MEDIUM, MINIMUM labels are examples of
information classification that are not used for access control.
In general, the privacy marks should provide brief but clear direction to the
user on how to handle the information.
2.2.1.4 Security Categories 2.2.1.4 Security Categories
Security categories or caveats are not specified to any of the sample policies. Security categories or caveats are not specified to any of the sample policies.
However, they are used in at least 2 of the companies informally. Though formal However, they are used in at least 2 of the companies. Though the security
security categories are not defined, some proprietary information does need more categories are not defined formally in the security policies, once locally
defined they are formal and are to be enforced. The security categories are
defined when necessary to provide identifiable proprietary information more
granular access control. A category can be based organizationally or by project granular access control. A category can be based organizationally or by project
(i.e., Legal or Project Vallor). User specified security categories are defined (i.e., Legal Only or Project Vallor).
using the following syntax.
<< Need to develop the syntax. Suggestions?>> 2.2.1.4.1 Syntax
User specified security categories are defined using the following syntax
(taken and expanded from [ESS]).
SecurityCategories ::= SET SIZE (1..ub-security-categories) OF SecurityCategory
ub-security-categories INTEGER ::= 64
SecurityCategory ::= SEQUENCE {
type [0] OBJECT IDENTIFIER <<need to get a generic SMIME OID>>
value [1] ANY DEFINED BY type -- defined by type
When id-securityCategoryValues is present in the SecurityCategory type field, then
the SecurityCategory value field will take the form of SecurityCategoryValues as
follows:
SecurityCategoryValues ::= SEQUENCE OF SecurityCategoryTagGroup
SecurityCategoryTagGroup ::= SEQUENCE {
securityCategoryTagGroupName OBJECT IDENTIFIER,
securityCategoryTagGroup SEQUENCE OF SecurityCategoryTag}
SecurityCategoryTag ::= CHOICE {
restrictiveBitMap [0] BIT STRING,
permissiveBitMap [1] BIT STRING,
noAccessControlBitMap [2] BIT STRING,
restrictiveEnumerated [3] SEQUENCE OF INTEGER,
permissiveEnumerated [4] SEQUENCE OF INTEGER,
noAccessControlEnumerated [5] SEQUENCE OF INTEGER}
2.2.1.4.2 Use
An organization will define a securityCategoryTagGroupName OID representing each
unique group of defined security category values (i.e. SecurityCategoryTagGroup)
within their security policy. An organization can define multiple
SecurityCategoryTagGroups within their security policy. A
SecurityCategoryTagGroup MUST not include multiple definitions for a
SecurityCategoryTag CHOICE. For example, there MUST not be multiple
permissiveBitMaps defined within a single SecurityCategoryTagGroup.
The Restrictive Bit Map Tag bit string is used to convey a set of non-hierarchical
attributes that apply to the labeled message. A bit is assigned to every security
policy-defined restrictive attribute. Bits corresponding to restrictive attributes
that apply will be set to 1, otherwise bits are set to 0. Access MUST be restricted
to only those entities whose set of attributes is a subset of the attributes for
the receiving end. Security compartments and caveats are examples of restrictive
security attributes.
The Permissive Bit Map Tag bit string is used to convey a set of non-hierarchical
attributes that apply to the labeled message. A bit is assigned to every security
policy-defined permissive attribute. Release markings are examples of permissive
security attributes. Bits corresponding to types or groups of entities that are
granted access to the message are set to 0, all other bits are set to 1. For
example, the label on entities to be available only to members of an
organization's Personnel Office will have the bit assigned to the Personnel
Office set to 0 and all others set to 1. A message can be accepted if the
receiving end belongs to any of the release groups in the release permission list
on the message label.
The No Access Control Bit Map Tag bit string is used to to represent security
category values for which no access control check is required (e.g. originator
controlled data).
The Restrictive Enumerated Tag non-negative integers convey a security level, a
hierarchical security attribute. The higher the value of this attribute the
higher the security level of the labeled message. Each of the integers that
follow represent a non-hierarchical attribute that applies to the labeled
message. This is an alternative to the bit-representation in the Restrictive Bit
Map Tag. It is intended to minimize label length in cases where only a few
attributes out of a large set apply to the message. An example of attributes
enumerated by this tag are compartments. Access MUST be restricted to
only those messages whose set of attributes is a subset of the attributes for the
receiving end.
The Permissive Enumerated Tag non-negative integers convey a security level, a
hierarchical security attribute. The higher the value of this attribute the
higher the security level of the labeled message. Each of the integers that
follow represent a non-hierarchical attribute that applies to the labeled
message. This is an alternative to the bit-representation in the Permissive
Enumerated Tag. It is intended to minimize label length in cases where only a few
attributes out of a large set apply to the message. An example of attributes
enumerated by this tag are release permissions. A message can be accepted if the
receiving end belongs to any of the release groups in the release permission list
on the message label.
The No Accesss Control Enumerated Tage non-negative integers convey security category
values for which no access control check is required (e.g. list of country codes).
2.2.1.4.3 Security Category Example
<<need to an at least example for each type with a test securityCategoryTagGroupNam
OID and sample values>>
2.2.2 Attribute Owner Clearance 2.2.2 Attribute Owner Clearance
The security clearance and category authorizations for the user are defined in The security clearance and category authorizations for the user are defined in
the clearance attribute. the clearance attribute.
2.2.2.1 Amoco User 2.2.2.1 Amoco User
Clearance ::= SEQUENCE { Clearance ::= SEQUENCE {
policyId OBJECT IDENTIFIER, policyId 1 2 840 113549 1 9 16 7 1,
classList ClassList DEFAULT {general}, classList ClassList DEFAULT {general},
securityCategories securityCategories
SET OF SecurityCategory OPTIONAL SET OF SecurityCategory OPTIONAL
} }
ClassList ::= BIT STRING { ClassList ::= BIT STRING {
amoco general (6), amoco general (6),
amoco confidential (7), amoco confidential (7),
amoco highly confidential (8), amoco highly confidential (8),
} }
SecurityCategory ::= SEQUENCE { SecurityCategory ::= SEQUENCE {
type [0] IMPLICIT OBJECT IDENTIFIER, type [0] IMPLICIT OBJECT IDENTIFIER,
value [1] ANY DEFINED BY type value [1] ANY DEFINED BY type
} }
2.2.2.1 Caterpillar User 2.2.2.2 Caterpillar User
Clearance ::= SEQUENCE { Clearance ::= SEQUENCE {
policyId OBJECT IDENTIFIER, policyId 1 2 840 113549 1 9 16 7 2,
classList ClassList DEFAULT {general}, classList ClassList DEFAULT {general},
securityCategories securityCategories
SET OF SecurityCategory OPTIONAL SET OF SecurityCategory OPTIONAL
} }
ClassList ::= BIT STRING { ClassList ::= BIT STRING {
caterpillar public (6), caterpillar public (6),
caterpillar confidential greeen (7), caterpillar confidential greeen (7),
caterpillar confidential yellow (8), caterpillar confidential yellow (8),
caterpillar confidential red (9) caterpillar confidential red (9)
} }
SecurityCategory ::= SEQUENCE { SecurityCategory ::= SEQUENCE {
type [0] IMPLICIT OBJECT IDENTIFIER, type [0] IMPLICIT OBJECT IDENTIFIER,
value [1] ANY DEFINED BY type value [1] ANY DEFINED BY type
} }
2.2.2.1 Whirlpool User 2.2.2.3 Whirlpool User
Clearance ::= SEQUENCE { Clearance ::= SEQUENCE {
policyId OBJECT IDENTIFIER, policyId 1 2 840 113549 1 9 16 7 3,
classList ClassList DEFAULT {general}, classList ClassList DEFAULT {general},
securityCategories securityCategories
SET OF SecurityCategory OPTIONAL SET OF SecurityCategory OPTIONAL
} }
ClassList ::= BIT STRING { ClassList ::= BIT STRING {
whirlpool public (6), whirlpool public (6),
whirlpool internal (7), whirlpool internal (7),
whirlpool confidential (8), whirlpool confidential (8),
} }
SecurityCategory ::= SEQUENCE { SecurityCategory ::= SEQUENCE {
type [0] IMPLICIT OBJECT IDENTIFIER, type [0] IMPLICIT OBJECT IDENTIFIER,
value [1] ANY DEFINED BY type value [1] ANY DEFINED BY type
} }
2.2.3 Additional ESSSecurityLabel Processing Guidance <<need to complete security category with example OIDs and values>>
<<What needs to be addressed here?>>
<<How does the app know how to interpret the values into meaningful text?>> 2.2.3 Additional ESSSecurityLabel Processing Guidance
When originating enveloped data, the agents MUST allow the security label of the An implementation issue with the security label is the mapping of the bit string
data to be specified. to displayable characters. This is an issue for users who want to develop and
retire their own classifications and categories a regular basis. Applications
should provide a means for the enterprise to manage these changes. The practice
of hard coding the mapping into the applications is discouraged.
Upon successful access control processing, the agents SHOULD display to the This issue is viewed as local issue for the application vendor, as the solution
recipient the security label for the encrypted data. does not need to be interoperable between vendors.
<<What is missing?>> An approach is the use of a Security Policy Information File (SPIF)[X.sio]. A
SPIF is a construct that conveys domain-specific security policy information.
It is also a sign object to protect it from unauthorized changes and to
authenticate the source of the policy information. It contains critical display
information such as the text string for security classifications and security
categories to be displayed to the user, as well as additional security policy
information.
3. Security Considerations 3. Security Considerations
All security considerations from [CMS] and [ESS] apply to applications that use All security considerations from [CMS] and [ESS] apply to applications that use
procedures described in this document. procedures described in this document.
A. References A. References
[AC509] Farrell, S., Housley, R., "An Internet AttributeCertificate Profile for [AC509] Farrell, S., Housley, R., "An Internet AttributeCertificate Profile for
Authorization", draft-ietf-pkix-ac509prof-01.txt. Authorization", draft-ietf-pkix-ac509prof-03.txt.
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630. [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630.
[ESS] Hoffman, P., Editor, "Enhanced Security Services for S/MIME", RFC 2634. [ESS] Hoffman, P., Editor, "Enhanced Security Services for S/MIME", RFC 2634.
[MUSTSHOULD] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement [MUSTSHOULD] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
Levels", Levels", RFC 2119.
RFC 2119.
[X.501] "ITU-T Recommendation X.501 : Information Technology - Open Systems [X.501] "ITU-T Recommendation X.501 : Information Technology - Open Systems
Interconnection - The Directory: Models", 1993. Interconnection - The Directory: Models", 1993.
[X.509] "ITU-T Recommendation X.509 (1997 E): Information [X.509] "ITU-T Recommendation X.509 (1997 E): Information
Technology - Open Systems Interconnection - The Directory: Authentication Technology - Open Systems Interconnection - The Directory: Authentication
Framework", June 1997. Framework", June 1997.
[X.sio] "Information Technology - Security Techniques - Security Information
Objects", IOS/IEC FCD 15816, 1999-11-12.
B. Acknowledgements B. Acknowledgements
I would like to thanks Russ Housley for helping me through the process of I would like to thank Russ Housley for helping me through the process of
developing this document. I would also like to thank the good people at (BP) developing this document. I would like to thank John Pawling for his technical
assistance and guidance. I would also like to thank the good people at (BP)
Amoco, Caterpillar and Whirlpool who allowed me to use their policies as the Amoco, Caterpillar and Whirlpool who allowed me to use their policies as the
real examples that make this document possible. real examples that make this document possible.
C. Authors Address C. Author's Address
Weston Nicolls Weston Nicolls
Ernst & Young LLP Telenisus Corporation (formerly with Ernst & Young LLP)
111 N. Canal St 1701 Golf Rd
Chicago, IL 60606 Tower 3, Suite 600
(312) 879-2075 Rolling Meadows, IL 60008
weston.nicolls@ey.com (847) 871-5086
wnicolls@telenisus.com
D. Open issues: D. Open issues:
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/