idnits 2.17.1 draft-ietf-smime-seclabel-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 568 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 205 instances of too long lines in the document, the longest one being 13 characters in excess of 72. ** There are 17 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 376: '...CategoryTagGroup MUST not include mult...' RFC 2119 keyword, line 377: '...or example, there MUST not be multiple...' RFC 2119 keyword, line 383: '...re set to 0. Access MUST be restricted...' RFC 2119 keyword, line 410: '...artments. Access MUST be restricted to...' RFC 2119 keyword, line 444: '... SET OF SecurityCategory OPTIONAL...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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 document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2000) is 8683 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC2026' on line 13 looks like a reference -- Missing reference section? 'ESS' on line 532 looks like a reference -- Missing reference section? 'MUSTSHOULD' on line 534 looks like a reference -- Missing reference section? 'CERTCRL' on line 119 looks like a reference -- Missing reference section? 'AC509' on line 527 looks like a reference -- Missing reference section? '0' on line 495 looks like a reference -- Missing reference section? '1' on line 496 looks like a reference -- Missing reference section? '2' on line 365 looks like a reference -- Missing reference section? '3' on line 366 looks like a reference -- Missing reference section? '4' on line 367 looks like a reference -- Missing reference section? '5' on line 368 looks like a reference -- Missing reference section? 'CMS' on line 530 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 S/MIME Working Group Weston Nicolls 2 INTERNET DRAFT Telenisus Corporation 3 Expires in six months July 2000 5 Implementing Company Classification Policy 6 with the S/MIME Security Label 7 9 Status of this memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of [RFC2026]. 14 This document is an Internet-Draft. Internet-Drafts are working documents 15 of the Internet Engineering Task Force (IETF), its areas, and its working 16 groups. Note that other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months and 20 may be updated, replaced, or obsoleted by other documents at any time. It 21 is inappropriate to use Internet-Drafts as reference material or to cite 22 them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 <> 32 1. Introduction 34 This document discusses how company security policy for data classification can 35 be mapped to the S/MIME classification label. Actual policies from 3 companies 36 are used to provide worked examples. 38 Security labels are an optional security service for S/MIME. A security label is 39 a set of security information regarding the sensitivity of the content that is 40 protected by S/MIME encapsulation. A security label can be included in the 41 signed attributes of any SignedData object. A security label attribute may be 42 included in either the inner signature, outer signature, or both. The syntax 43 and processing rules for security labels are described in [ESS]. 45 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT','SHOULD', 46 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be 47 interpreted as described in [MUSTSHOULD]. 49 This draft is being discussed on the 'ietf-smime' mailing list. To join the 50 list, send a message to with the single word 51 'subscribe' in the body of the message. Also, there is a Web site for the 52 mailing list at . 54 1.1 Information Classification Policies 56 Information is an asset, but not all information has the same value for a 57 business. Not all information needs to be protected as strongly as other 58 information. 60 Research and development plans, marketing strategies and manufacturing quality 61 specifications developed and used by a company provide competitive advantage. 62 This type of information needs stronger protective measures than other 63 information, which if disclosed or modified, would cause little or no damage to 64 the company. 66 Other types of information such as internal organization charts, employee lists 67 and policies may need little and no protective measures based on value the 68 organization places on it. 70 A corporate information classification policy defines how its information assets 71 are to be protected. It provides guidance to employees on how to classify 72 information assets. It defines how to label and protect an asset based on its 73 classification and state (e.g. facsimile, electronic transfer, storage, 74 shipping, etc.). 76 1.2 Access Control and Security Labels 78 "Access control" is a means of enforcing authorizations. There are a variety of 79 access control methods that are based on different types of policies and rely on 80 different security mechanisms. 82 - Rule based access control is based on policies that can be algorithmically 83 expressed. 85 - Identity based access control is based on a policy which applies explicitly 86 to an individual person or host entity, or to a defined group of such entities. 87 Once identity has been authenticated, if the identity is verified to be on the 88 access list, then access is granted. 90 - Rank base access control is based on a policy of hierarchical positions in an 91 organization. It is based on who you are in the company structure. A rank-based 92 policy would define what information that the position of Partner or Senior 93 Consultant could access. 95 - Role based access control is based on a policy of roles in an organization. 96 It may or may not be hierarchical. It is based on who you are in the company. 97 The role-based policy would define what information that the role of Database 98 Administrator, Network Administrator, Mailroom Clerk or Purchaser could access. 100 Rule, rank and role-based access control methods can rely on a security label as 101 the security mechanism to convey the sensitivity or classification of the 102 information. When verifying an S/MIME encapsulated message, the sensitivity 103 information in the message's security label can be compared with the recipient's 104 authorizations to determine if the recipient is allowed to access the protected 105 content. 107 An S/MIME security label may be included as an authenticated attribute in the 108 inner (or only) signature or the outer signature. The inner signature would be 109 used for access control decisions related to the plaintext original content, 110 while the outer signature would be used for access control decisions related to 111 the encrypted message. 113 1.3 User Authorizations 115 Users need to be granted authorizations to access information that has been 116 classified by an authority. The sending and receiving agent need to be able to 117 securely determine the user's authorizations for access control processing. 119 [X.509] and the Internet profile for X.509 certificates [CERTCRL] do not define 120 the means to represent and convey authorizations in a certificate. 122 [X.501] defines how to represent authorization in the form of a clearance 123 attribute. The clearance attribute identifies the security policy in force to 124 which a list of possible classifications and security categories relates. 126 [X.501] also notes two means for binding the clearance to a named entity: an 127 Attribute Certificate and a Certificate extension field (e.g., within the 128 subjectDirectoryAttribute extension). 130 [AC509] defines a profile of X.509 Attribute Certificate (AC) suitable for use 131 with authorization information within Internet Protocols. One of the defined 132 attributes is Clearance, which carries clearance (security labeling) information 133 about the AC owner. The syntax for Clearance is imported from [X.501]. 135 2. Developed Examples 137 2.1 Classification Policies 139 The following describes the information classification policies in effect at 3 140 companies. 142 2.1.1 Amoco Corporation 144 The description for the Amoco information classification policy was taken from 145 the Amoco Computer Security Guidelines. Amoco classifies its information assets 146 based on confidentiality and integrity and defines 3 hierarchical 147 classifications for each. The confidentiality and integrity polices are 148 independent, so either or both may be applied to the information. Amoco also 149 defines an availability classification for time critical information. 151 HIGHLY CONFIDENTIAL - Information whose unauthorized disclosure will cause the 152 company severe financial, legal or reputation damage. Examples: Certain 153 acquisitions, bid economics, negotiation strategies. 155 CONFIDENTIAL - Information whose unauthorized disclosure may cause the company 156 financial, legal, or reputation damage. Examples: Employee Personnel & Payroll 157 Files, some interpreted Exploration Data. 159 GENERAL - Information that, because of its personal, technical, or business 160 sensitivity is restricted for use within the company. Unless otherwise 161 classified, all information within Amoco is in this category. 163 MAXIMUM - Information whose unauthorized modification and destruction will cause 164 the company severe financial, legal, or reputation damage. 166 MEDIUM - Information whose unauthorized modification and destruction may cause 167 the company financial, legal, or reputation damage. Examples: Electronic Funds, 168 Transfer, Payroll, and Commercial Checks 170 MINIMUM - Although an error in this data would be of minimal consequence, this 171 is still important company information and therefore will require some minimal 172 controls to ensure a minimal level of assurance that the integrity of the data 173 is maintained. This applies to all data that is not placed in one of the above 174 classifications. Examples: Lease Production Data, Expense Data, Financial Data, 175 and Exploration Data. 177 CRITICAL - It is important to assess the availability requirements of data, 178 applications and systems. A business decision will be required to determine the 179 length of unavailability that can be tolerated prior to expending additional 180 resources to ensure the information availability that is required. Information 181 should be labeled "CRITICAL" if it is determined that special procedures should 182 be used to ensure its' availability. 184 2.1.2 Caterpillar, Inc. 186 The description for the Caterpillar information classification policy is taken 187 from the Caterpillar Information Protection Guidelines. Caterpillar classifies 188 its information assets based on confidentiality and defines 4 hierarchical 189 classifications. 191 Caterpillar Confidential Red - Provides a significant competitive advantage. 192 Disclosure would cause severe damage to operations. Relates to or describes a 193 long-term strategy or critical business plans. Disclosure would cause regulatory 194 or contractual liability. Disclosure would cause severe damage to our reputation 195 or the public image. Disclosure would cause a severe loss of market share or the 196 ability to be first to market. Disclosure would cause a loss of an important 197 customer, shareholder, or business partner. Disclosure would cause a long-term 198 or severe drop in stock value. Strong likelihood somebody is seeking to acquire 199 this information. 201 Caterpillar Confidential Yellow - Provides a competitive advantage. Disclosure 202 could cause moderate damage to the company or an individual. Relates to or 203 describes an important part of the operational direction of the company over 204 time. Important technical or financial aspects of a product line or a business 205 unit. Disclosure could cause a loss of Customer or Shareholder confidence. 206 Disclosure could cause a temporary drop in stock value. A likelihood that 207 somebody could seek to acquire this information. 209 Caterpillar Confidential Green - Might provide a business advantage over those 210 who do not have access to the same information. Might be useful to a competitor. 211 Not easily identifiable by inspection of a product. Not generally known outside 212 the company or available from public sources. Generally available internally. 213 Little competitive interest. 215 Caterpillar Public - Would not provide a business or competitive advantage. 216 Routinely made available to interested members of the General Public. Little or 217 no competitive interest. 219 2.1.3 Whirlpool Corporation 221 The description for the Whirlpool information classification policy is taken 222 from the Whirlpool Information Protection Policy. Whirlpool classifies its 223 information assets based on confidentiality and defines 2 hierarchical 224 classifications. The policy states that: 226 "All information generated by or for Whirlpool, in whatever form, written, 227 verbal, or electronic, is to be treated as WHIRLPOOL INTERNAL or WHIRLPOOL 228 CONFIDENTIAL. Classification of information in either category depends on its 229 value, the impact of unauthorized disclosure, legal requirements, and the manner 230 in which it needs to be used by the company. Some WHIRLPOOL INTERNAL 231 information may be authorized for public release." 233 WHIRLPOOL CONFIDENTIAL - A subset of Whirlpool Internal information, the 234 unauthorized disclosure or compromise of which would likely have an adverse 235 impact on the company's competitive position, tarnish its reputation, or 236 embarrass an individual. Examples: Customer, financial, pricing, or personnel 237 data; merger/acquisition, product, or marketing plans; new product designs, 238 proprietary processes and systems. 240 WHIRLPOOL INTERNAL - All forms of proprietary information originated or owned by 241 Whirlpool, or entrusted to it by others. Examples: Organization charts, 242 policies, procedures, phone directories, some types of training materials. 244 WHIRLPOOL PUBLIC - Information officially released by Whirlpool for widespread 245 public disclosure. Example: Press releases, public marketing materials, 246 employment advertising, annual reports, product brochures, the public web site, 247 etc 249 The policy also states that privacy markings are allowable. Specifically: 251 For WHIRLPOOL INTERNAL, additional markings or caveats are option at the 252 discretion of the information owner. 254 For WHIRLPOOL CONFIDENTIAL, add additional marking or caveats as necessary to 255 comply with regulatory or heightened security requirements. Examples: MAKE NO 256 COPIES, THIRD PARTY CONFIDENTIAL, ATTORNEY-CLIENT PRIVILEGED DOCUMENT, 257 DISTRIBUTION LIMITED TO ____, COVERED BY A NON-ANALYSIS AGREEMENT. 259 2.2 S/MIME Classification Label Developed Examples 261 [ESS] defines the ESSSecurityLabel syntax and processing rules. This section 262 builds upon those definitions to define detailed example policies. 264 2.2.1 Security Label Components 266 The examples are detailed using the various components of the eSSSecurity Label 267 syntax. 269 2.2.1.1 Security Policy Identifier 271 A security policy is a set of criteria for the provision of security services. 272 The eSSSecurityLabel security-policy-identifier is used to identify the security 273 policy in force to which the security label relates. It indicates the semantics 274 of the other security label components. 276 For the example policies, the following security policy object identifiers are 277 defined: 279 -- S/MIME Working Group Object Identifier Registry 280 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) 281 pkcs(1) pkcs-9(9) 16 } 283 -- S/MIME Test Securty Policy Arc 284 id-tsp OBJECT IDENTIFIER ::= { id-smime 7 } 286 -- Test Security Policies 287 id-tsp-TEST-Amoco OBJECT IDENTIFIER ::= { id-tsp 1 } 288 id-tsp-TEST-Caterpillar OBJECT IDENTIFIER ::= { id-tsp 2 } 289 id-tsp-test-Whirlpool OBJECT IDENTIFIER ::= { id-tsp 3 } 291 2.2.1.2 Security Classification 293 The security classification values and meanings are defined by the governing 294 company policies. The security-classification values defined are hierarchical 295 and do not use integers 0 through 5. 297 Amoco-SecurityClassification ::= { 298 amoco general (6), 299 amoco confidential (7), 300 amoco highly confidential (8) } (0..ub-integer-options) 302 Caterpillar-SecurityClassification values ::= { 303 caterpillar public (6), 304 caterpillar green (7), 305 caterpillar yellow (8), 306 caterpillar red (9) } (0..ub-integer-options) 308 Whirlpool-SecurityClassification values ::= { 309 whirlpool public (6), 310 whirlpool internal (7), 311 whirlpool confidential (8) } (0..ub-integer-options) 313 2.2.1.3 Privacy Mark 315 Privacy marks are specified the Whirlpool policy. The policy provides examples 316 of possible markings but other can be defined by users as necessary (though no 317 guidance is given). The Whirlpool policy provides the following examples: 318 MAKE NO COPIES, THIRD PARTY CONFIDENTIAL, ATTORNEY-CLIENT PRIVILEGED DOCUMENT, 319 DISTRIBUTION LIMITED TO ____, and COVERED BY A NON-ANALYSIS AGREEMENT. 321 The Amoco policy does not identify any privacy marks but the classification 322 labels defined for availability and integrity would be most appropriately 323 displayed here. The CRITICAL, MAXIMUM, MEDIUM, MINIMUM labels are examples of 324 information classification that are not used for access control. 326 In general, the privacy marks should provide brief but clear direction to the 327 user on how to handle the information. 329 2.2.1.4 Security Categories 331 Security categories or caveats are not specified to any of the sample policies. 332 However, they are used in at least 2 of the companies. Though the security 333 categories are not defined formally in the security policies, once locally 334 defined they are formal and are to be enforced. The security categories are 335 defined when necessary to provide identifiable proprietary information more 336 granular access control. A category can be based organizationally or by project 337 (i.e., Legal Only or Project Vallor). 339 2.2.1.4.1 Syntax 341 User specified security categories are defined using the following syntax 342 (taken and expanded from [ESS]). 344 SecurityCategories ::= SET SIZE (1..ub-security-categories) OF SecurityCategory 346 ub-security-categories INTEGER ::= 64 348 SecurityCategory ::= SEQUENCE { 349 type [0] OBJECT IDENTIFIER <> 350 value [1] ANY DEFINED BY type -- defined by type 352 When id-securityCategoryValues is present in the SecurityCategory type field, then 353 the SecurityCategory value field will take the form of SecurityCategoryValues as 354 follows: 356 SecurityCategoryValues ::= SEQUENCE OF SecurityCategoryTagGroup 358 SecurityCategoryTagGroup ::= SEQUENCE { 359 securityCategoryTagGroupName OBJECT IDENTIFIER, 360 securityCategoryTagGroup SEQUENCE OF SecurityCategoryTag} 362 SecurityCategoryTag ::= CHOICE { 363 restrictiveBitMap [0] BIT STRING, 364 permissiveBitMap [1] BIT STRING, 365 noAccessControlBitMap [2] BIT STRING, 366 restrictiveEnumerated [3] SEQUENCE OF INTEGER, 367 permissiveEnumerated [4] SEQUENCE OF INTEGER, 368 noAccessControlEnumerated [5] SEQUENCE OF INTEGER} 370 2.2.1.4.2 Use 372 An organization will define a securityCategoryTagGroupName OID representing each 373 unique group of defined security category values (i.e. SecurityCategoryTagGroup) 374 within their security policy. An organization can define multiple 375 SecurityCategoryTagGroups within their security policy. A 376 SecurityCategoryTagGroup MUST not include multiple definitions for a 377 SecurityCategoryTag CHOICE. For example, there MUST not be multiple 378 permissiveBitMaps defined within a single SecurityCategoryTagGroup. 380 The Restrictive Bit Map Tag bit string is used to convey a set of non-hierarchical 381 attributes that apply to the labeled message. A bit is assigned to every security 382 policy-defined restrictive attribute. Bits corresponding to restrictive attributes 383 that apply will be set to 1, otherwise bits are set to 0. Access MUST be restricted 384 to only those entities whose set of attributes is a subset of the attributes for 385 the receiving end. Security compartments and caveats are examples of restrictive 386 security attributes. 388 The Permissive Bit Map Tag bit string is used to convey a set of non-hierarchical 389 attributes that apply to the labeled message. A bit is assigned to every security 390 policy-defined permissive attribute. Release markings are examples of permissive 391 security attributes. Bits corresponding to types or groups of entities that are 392 granted access to the message are set to 0, all other bits are set to 1. For 393 example, the label on entities to be available only to members of an 394 organization's Personnel Office will have the bit assigned to the Personnel 395 Office set to 0 and all others set to 1. A message can be accepted if the 396 receiving end belongs to any of the release groups in the release permission list 397 on the message label. 399 The No Access Control Bit Map Tag bit string is used to to represent security 400 category values for which no access control check is required (e.g. originator 401 controlled data). 403 The Restrictive Enumerated Tag non-negative integers convey a security level, a 404 hierarchical security attribute. The higher the value of this attribute the 405 higher the security level of the labeled message. Each of the integers that 406 follow represent a non-hierarchical attribute that applies to the labeled 407 message. This is an alternative to the bit-representation in the Restrictive Bit 408 Map Tag. It is intended to minimize label length in cases where only a few 409 attributes out of a large set apply to the message. An example of attributes 410 enumerated by this tag are compartments. Access MUST be restricted to 411 only those messages whose set of attributes is a subset of the attributes for the 412 receiving end. 414 The Permissive Enumerated Tag non-negative integers convey a security level, a 415 hierarchical security attribute. The higher the value of this attribute the 416 higher the security level of the labeled message. Each of the integers that 417 follow represent a non-hierarchical attribute that applies to the labeled 418 message. This is an alternative to the bit-representation in the Permissive 419 Enumerated Tag. It is intended to minimize label length in cases where only a few 420 attributes out of a large set apply to the message. An example of attributes 421 enumerated by this tag are release permissions. A message can be accepted if the 422 receiving end belongs to any of the release groups in the release permission list 423 on the message label. 425 The No Accesss Control Enumerated Tage non-negative integers convey security category 426 values for which no access control check is required (e.g. list of country codes). 428 2.2.1.4.3 Security Category Example 430 <> 433 2.2.2 Attribute Owner Clearance 435 The security clearance and category authorizations for the user are defined in 436 the clearance attribute. 438 2.2.2.1 Amoco User 440 Clearance ::= SEQUENCE { 441 policyId 1 2 840 113549 1 9 16 7 1, 442 classList ClassList DEFAULT {general}, 443 securityCategories 444 SET OF SecurityCategory OPTIONAL 445 } 447 ClassList ::= BIT STRING { 448 amoco general (6), 449 amoco confidential (7), 450 amoco highly confidential (8), 451 } 453 SecurityCategory ::= SEQUENCE { 454 type [0] IMPLICIT OBJECT IDENTIFIER, 455 value [1] ANY DEFINED BY type 456 } 458 2.2.2.2 Caterpillar User 460 Clearance ::= SEQUENCE { 461 policyId 1 2 840 113549 1 9 16 7 2, 462 classList ClassList DEFAULT {general}, 463 securityCategories 464 SET OF SecurityCategory OPTIONAL 465 } 467 ClassList ::= BIT STRING { 468 caterpillar public (6), 469 caterpillar confidential greeen (7), 470 caterpillar confidential yellow (8), 471 caterpillar confidential red (9) 472 } 474 SecurityCategory ::= SEQUENCE { 475 type [0] IMPLICIT OBJECT IDENTIFIER, 476 value [1] ANY DEFINED BY type 477 } 479 2.2.2.3 Whirlpool User 481 Clearance ::= SEQUENCE { 482 policyId 1 2 840 113549 1 9 16 7 3, 483 classList ClassList DEFAULT {general}, 484 securityCategories 485 SET OF SecurityCategory OPTIONAL 486 } 488 ClassList ::= BIT STRING { 489 whirlpool public (6), 490 whirlpool internal (7), 491 whirlpool confidential (8), 492 } 494 SecurityCategory ::= SEQUENCE { 495 type [0] IMPLICIT OBJECT IDENTIFIER, 496 value [1] ANY DEFINED BY type 497 } 499 <> 501 2.2.3 Additional ESSSecurityLabel Processing Guidance 503 An implementation issue with the security label is the mapping of the bit string 504 to displayable characters. This is an issue for users who want to develop and 505 retire their own classifications and categories a regular basis. Applications 506 should provide a means for the enterprise to manage these changes. The practice 507 of hard coding the mapping into the applications is discouraged. 509 This issue is viewed as local issue for the application vendor, as the solution 510 does not need to be interoperable between vendors. 512 An approach is the use of a Security Policy Information File (SPIF)[X.sio]. A 513 SPIF is a construct that conveys domain-specific security policy information. 514 It is also a sign object to protect it from unauthorized changes and to 515 authenticate the source of the policy information. It contains critical display 516 information such as the text string for security classifications and security 517 categories to be displayed to the user, as well as additional security policy 518 information. 520 3. Security Considerations 522 All security considerations from [CMS] and [ESS] apply to applications that use 523 procedures described in this document. 525 A. References 527 [AC509] Farrell, S., Housley, R., "An Internet Attribute Certificate Profile for 528 Authorization", draft-ietf-pkix-ac509prof-03.txt. 530 [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630. 532 [ESS] Hoffman, P., Editor, "Enhanced Security Services for S/MIME", RFC 2634. 534 [MUSTSHOULD] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement 535 Levels", RFC 2119. 537 [X.501] "ITU-T Recommendation X.501: Information Technology - Open Systems 538 Interconnection - The Directory: Models", 1993. 540 [X.509] "ITU-T Recommendation X.509 (1997 E): Information 541 Technology - Open Systems Interconnection - The Directory: Authentication 542 Framework", June 1997. 544 [X.sio] "Information Technology - Security Techniques - Security Information 545 Objects", IOS/IEC FCD 15816, 1999-11-12. 547 B. Acknowledgements 549 I would like to thank Russ Housley for helping me through the process of 550 developing this document. I would like to thank John Pawling for his technical 551 assistance and guidance. I would also like to thank the good people at (BP) 552 Amoco, Caterpillar and Whirlpool who allowed me to use their policies as the 553 real examples that make this document possible. 555 C. Author's Address 557 Weston Nicolls 558 Telenisus Corporation (formerly with Ernst & Young LLP) 559 1701 Golf Rd 560 Tower 3, Suite 600 561 Rolling Meadows, IL 60008 562 (847) 871-5086 563 wnicolls@telenisus.com 565 D. Open issues: