Network Working Group W. Nicolls
Request for Comments: 3114 Forsythe Solutions
Category: Informational May 2002
Implementing Company Classification Policy
with the S/MIME Security Label
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
This document discusses how company security policy for data classification can be mapped to the S/MIME security label. Actual policies from three companies provide worked examples.
このドキュメントでは、データ分類のための会社のセキュリティポリシーは、S / MIMEセキュリティラベルにマッピングすることができる方法について説明します。三社からの実際の政策が働い例を提供します。
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 protected by S/MIME encapsulation. A security label can be included in the signed attributes of any SignedData object. A security label attribute may be included in either the inner signature, outer signature, or both. The syntax and processing rules for security labels are described in RFC 2634 [ESS].
セキュリティラベルは、S / MIMEのためのオプションのセキュリティサービスです。セキュリティラベルは、S / MIMEカプセル化によって保護されたコンテンツの感度に関するセキュリティ情報のセットです。セキュリティラベルは、任意のSignedDataオブジェクトの署名の属性に含めることができます。セキュリティ・ラベル属性は内側の署名、外側の署名、または両方に含まれてもよいです。セキュリティラベルの構文と処理規則は、RFC 2634 [ESS]に記載されています。
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 RFC 2119 [MUSTSHOULD].
キーワード 'MUST'、 'REQUIRED'、、、、 'べきではない' 'べきです' 'ないもの' '（SHALL）' 'てはならない'、 '推奨'、 'MAY'、および 'OPTIONAL' この文書に記載されていますRFC 2119 [MUSTSHOULD]に記載されているように解釈されます。
Information is an asset, but not all information has the same value for a business. Not all information needs to be protected as strongly as other information.
情報は資産ですが、すべての情報は、ビジネスのために同じ値を持っていません。いないすべての情報は、他の情報として強く保護される必要があります。
Research and development plans, marketing strategies and manufacturing quality specifications developed and used by a company provide competitive advantage. This type of information needs stronger protective measures than other information, which if disclosed or modified, would cause moderate to severe damage to the company.
同社が開発し、使用研究開発計画、マーケティング戦略と製造品質仕様は、競争上の優位性を提供します。この種の情報は開示されているか、または変更された場合、会社に重大な損傷に適度な原因となるその他の情報を、より強力な保護措置を必要とします。
Other types of information such as internal organization charts, employee lists and policies may need little or no protective measures based on value the organization places on it.
このような内部組織図、従業員のリストや政策などの情報の他の種類は、組織がそれに置く値に基づいて、ほとんど、あるいはまったく保護措置が必要な場合があります。
A corporate information classification policy defines how its information assets are to be protected. It provides guidance to employees on how to classify information assets. It defines how to label and protect an asset based on its classification and state (e.g., facsimile, electronic transfer, storage, shipping, etc.).
企業情報分類ポリシーは、その情報資産が保護される方法を定義します。これは、情報資産を分類する方法については、従業員へのガイダンスを提供します。それは、ラベルとその分類および状態（例えば、ファクシミリ、電子転送、貯蔵、出荷、等）に基づいて資産を保護する方法を定義します。
"Access control" is a means of enforcing authorizations. There are a variety of access control methods that are based on different types of policies and rely on different security mechanisms.
「アクセス制御」の権限を強化する手段です。ポリシーの異なる種類に基づいており、異なるセキュリティ・メカニズムに依存しているアクセス制御の様々な方法があります。
- Rule based access control is based on policies that can be algorithmically expressed.
- ルールベースのアクセス制御は、アルゴリズム的に表すことができ、ポリシーに基づいています。
- 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. Once identity has been authenticated, if the identity is verified to be on the access list, then access is granted.
- アイデンティティベースのアクセス制御は、個人またはホストエンティティへ、またはそのような実体の定義されたグループに明示的に適用されたポリシーに基づいています。アイデンティティが認証されるとアイデンティティがアクセスリストにあることが確認された場合、アクセスが許可されます。
- Rank base access control is based on a policy of hierarchical positions in an organization. It is based on who you are in the company structure. A rank-based 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 roles in an organization. It may or may not be hierarchical. It is based on who you are in the company. 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 the security mechanism to convey the sensitivity or classification of the information. When processing an S/MIME encapsulated message, the sensitivity 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 content.
ルール、ランクおよび役割ベースのアクセス制御方法は、情報の機密性や分類を伝えるために、セキュリティ・メカニズムとしてのセキュリティラベルに頼ることができます。 S / MIMEカプセル化されたメッセージを処理するとき、メッセージのセキュリティ・ラベルに感度情報は、受信者が保護されたコンテンツにアクセスすることを許可されているかどうかを決定するために受信者の権限と比較することができます。
An S/MIME security label may be included as a signed attribute in the inner (or only) signature or the outer signature. In the case of a triple-wrapped message as defined in RFC 2634, the inner signature would be used for access control decisions related to the plaintext original content, while the outer signature would be used for access control decisions related to the encrypted message.
S / MIMEのセキュリティ・ラベルは、内部（または唯一の）署名または外側署名で署名された属性として含まれてもよいです。外側の署名が暗号化されたメッセージに関連するアクセス制御の決定のために使用されるであろうしながら、RFC 2634で定義されるようにトリプルラップされたメッセージの場合には、内部署名は、平文のオリジナルコンテンツに関連するアクセス制御の決定のために使用されるであろう。
Users need to be granted authorizations to access information that has been classified by an authority. The sending and receiving agents need to be able to securely determine the user's authorizations for access control processing.
ユーザーは、認証局によって分類されている情報にアクセスする権限を付与する必要があります。送受信剤が確実アクセス制御処理のためのユーザの権限を決定することができる必要があります。
X.509 [X.509] and the Internet profile for X.509 certificates [CERTCRL] do not define the means to represent and convey authorizations in a certificate.
X.509証明書のX.509 [X.509]とインターネットプロファイルは[CERTCRL]証明書に権限を表現し、伝えるための手段を定義していません。
X.501 [X.501] defines how to represent authorization in the form of a clearance attribute. The clearance attribute identifies the security policy in force to which a list of possible classifications and security categories relates.
X.501は、[X.501]クリアランス属性の形で承認を表現する方法を定義します。クリアランス属性が可能な分類とセキュリティカテゴリのリストが関係する力でセキュリティポリシーを識別します。
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 subjectDirectoryAttribute extension).
（subjectDirectoryAttribute延長内、例えば）属性証明書と証明書の拡張フィールド：X.501も名前付きエンティティへのクリアランスを結合するための2つの手段を指摘しています。
RFC 3281 [AC509] defines a profile of X.509 Attribute Certificate (AC) suitable for use with authorization information within Internet Protocols. One of the defined attributes is Clearance, which carries clearance (security labeling) information about the AC owner. The syntax for Clearance is imported from X.501.
RFC 3281 [AC509]はX.509のプロファイルがインターネットプロトコル内の権限情報とともに使用するのに適した証明書（AC）を属性定義します。定義された属性の1つはACの所有者についてのクリアランス（セキュリティラベル）情報を運ぶクリアランス、です。クリアランスのための構文は、X.501から輸入されます。
The following describes the information classification policies in effect at 3 companies.
以下は、3社で有効な情報分類方針を説明しています。
The description for the Amoco information classification policy was taken from the Amoco Computer Security Guidelines. Amoco classifies its information assets based on confidentiality and integrity and defines 3 hierarchical 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.
アモコ情報分類方針について説明がアモココンピュータセキュリティガイドラインから取られました。アモコは、機密性と整合性に基づいてその情報資産を分類し、それぞれに3つの階層分類を定義します。機密性と完全性ポリシーは独立しているので、いずれか一方または両方は、情報に適用することができます。アモコもタイムクリティカルな情報の可用性の分類を定義します。
HIGHLY CONFIDENTIAL - Information whose unauthorized disclosure will cause the company severe financial, legal or reputation damage. Examples: Certain acquisitions, bid economics, negotiation strategies.
機密性の高い - その不正な開示会社に厳しい財政、法的または評判損傷を与える可能性があります情報。例：特定の買収、入札経済学、交渉戦略。
CONFIDENTIAL - Information whose unauthorized disclosure may cause the company financial, legal, or reputation damage. Examples: Employee Personnel & Payroll Files, some interpreted Exploration Data.
CONFIDENTIAL - その不正な開示会社は、金融法務、または評判の破損原因となります情報。例：従業員の人事・給与ファイル、いくつかの解釈探査データ。
GENERAL - Information that, because of its personal, technical, or business sensitivity is restricted for use within the company. Unless otherwise classified, all information within Amoco is in this category.
GENERAL - 、その個人的、技術的、またはビジネス感度の会社内で使用するために制限されている、という情報。それ以外の場合は分類されない限り、アモコ内のすべての情報は、このカテゴリです。
MAXIMUM - Information whose unauthorized modification and destruction will cause the company severe financial, legal, or reputation damage.
MAXIMUM - その不正な変更と破壊会社に厳しい財政、法的、または評判の損傷の原因となります情報。
MEDIUM - Information whose unauthorized modification and destruction may cause the company financial, legal, or reputation damage. Examples: Electronic Funds, Transfer, Payroll, and Commercial Checks.
MEDIUM - その不正な変更及び破壊の会社は、金融法務、または評判の破損原因となります情報。例：電子資金、転送、給与計算、およびコマーシャルをチェックします。
MINIMUM - Although an error in this data would be of minimal consequence, this 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 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, and Exploration Data.
MINIMUM - このデータにエラーが最小限の結果であろうが、これは重要な企業情報がまだあるため、データの整合性が維持されるという保証の最小レベルを確保するために、いくつかの最小限のコントロールが必要になります。これは、上記の分類のいずれかに配置されていないすべてのデータに適用されます。例：リース生産データ、費用データ、財務データ、および探査データ。
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.
CRITICAL - データ、アプリケーションやシステムの可用性の要件を評価することが重要です。ビジネスの意思決定が必要とされる情報の可用性を確保するために追加のリソースを消費する前に許容できる使用できないの長さを決定する必要があります。特別な手順は、その可用性を確保するために使用されるべきであると判断された場合の情報は、「CRITICAL」ラベル付けされなければなりません。
The description for the Caterpillar information classification policy is taken from the Caterpillar Information Protection Guidelines. Caterpillar classifies its information assets based on confidentiality and defines 4 hierarchical classifications.
キャタピラー情報分類ポリシーの説明は、キャタピラー情報保護指針から取られています。キャタピラーは、機密性に基づいて、その情報資産を分類し、4つの階層分類を定義します。
Caterpillar Confidential Red - Provides a significant competitive advantage. Disclosure would cause severe damage to operations. Relates to or describes a long-term strategy or critical business plans. Disclosure would cause regulatory or contractual liability. Disclosure would cause severe damage to our reputation or the public image. Disclosure would cause a severe loss of market share or the ability to be first to market. Disclosure would cause a loss of an important customer, shareholder, or business partner. Disclosure would cause a long-term or severe drop in stock value. Strong likelihood somebody is seeking to acquire this information.
キャタピラー機密レッド - 重要な競争上の優位性を提供します。本開示は、業務に重大な損傷を引き起こします。または長期戦略や重要な事業計画を説明しています。開示は、規制や契約上の責任を引き起こします。本開示は、当社の評判や公共のイメージに重大な損傷を引き起こします。本開示は、市場シェアや市場に最初に能力の深刻な損失を引き起こします。開示は重要な顧客、株主、またはビジネスパートナーの損失を引き起こします。本開示は、株式価値の長期的または重度の低下を引き起こします。強い可能性の誰かがこの情報を取得しようとしています。
Caterpillar Confidential Yellow - Provides a competitive advantage. Disclosure could cause moderate damage to the company or an individual. Relates to or describes an important part of the operational direction of the company over time. Important technical or financial aspects of a product line or a business unit. Disclosure could cause a loss of Customer or Shareholder confidence. Disclosure could cause a temporary drop in stock value. A likelihood that somebody could seek to acquire this information.
キャタピラー機密イエロー - 競争上の優位性を提供します。本開示は、企業や個人へ中等度の損傷を引き起こす可能性があります。または時間をかけて、会社の動作方向の重要な部分を説明しています。製品ラインやビジネスユニットの重要な技術的または財務的側面。本開示は、お客様や株主の信頼の喪失を引き起こす可能性があります。本開示は、株式価値の一時的な低下を引き起こす可能性があります。誰かがこの情報を取得することを求めることができると見込み。
Caterpillar Confidential Green - Might provide a business advantage over those who do not have access to the same information. Might be useful to a competitor. Not easily identifiable by inspection of a product. Not generally known outside the company or available from public sources. Generally available internally. Little competitive interest.
キャタピラー機密グリーンは - 同じ情報へのアクセス権を持っていない人を介してビジネスの優位性を提供するかもしれません。競合他社に役に立つかもしれません。製品の検査によって容易に同定されていません。一般的に、会社の外に知られている、または公共のソースから利用できません。内部で一般的に利用できます。リトル競争力のある金利。
Caterpillar Public - Would not provide a business or competitive advantage. Routinely made available to interested members of the General Public. Little or no competitive interest.
キャタピラーパブリック - ビジネスや競争上の優位性を提供しないであろう。日常一般公衆の興味メンバーに利用可能となります。ほとんど、あるいはまったく競争力の関心。
The description for the Whirlpool information classification policy is taken from the Whirlpool Information Protection Policy. Whirlpool classifies its information assets based on confidentiality and defines 3 hierarchical classifications. The policy states that:
ワールプール情報分類ポリシーの説明は、ワールプール情報保護ポリシーから取得されます。ワールプールは、機密性に基づいて、その情報資産を分類し、3つの階層分類を定義します。ポリシーは、と述べています：
"All information generated by or for Whirlpool, in whatever form, written, verbal, or electronic, is to be treated as WHIRLPOOL INTERNAL or WHIRLPOOL CONFIDENTIAL. Classification of information in either category depends on its value, the impact of unauthorized disclosure, legal requirements, and the manner in which it needs to be used by the company. Some WHIRLPOOL INTERNAL information may be authorized for public release."
「口頭、または電子書かれたものは何でも形でワールプールによってまたはのために生成されたすべての情報は、、、WHIRLPOOL INTERNALまたはWHIRLPOOL CONFIDENTIALとして扱われることである。情報の分類カテゴリのいずれかで、その値、不正な開示の影響、法的要件に依存します、そしてそれが必要とする方法は、企業によって使用される。いくつかのWHIRLPOOL INTERNAL情報は一般公開を許可することができます。」
WHIRLPOOL CONFIDENTIAL - A subset of Whirlpool Internal information, the unauthorized disclosure or compromise of which would likely have an adverse impact on the company's competitive position, tarnish its reputation, or embarrass an individual. Examples: Customer, financial, pricing, or personnel data; merger/acquisition, product, or marketing plans; new product designs, proprietary processes and systems.
WHIRLPOOL CONFIDENTIAL - ワールプール内部情報のサブセット、おそらく、企業の競争力に悪影響を与えるの評判を傷つける、または個々を困らことになるの不正な開示または妥協。例：顧客、財務、価格設定、または個人データ。合併/買収、製品、またはマーケティング計画。新製品の設計、独自のプロセスとシステム。
WHIRLPOOL INTERNAL - All forms of proprietary information originated or owned by Whirlpool, or entrusted to it by others. Examples: Organization charts, policies, procedures, phone directories, some types of training materials.
WHIRLPOOL INTERNAL - 専有情報の全ての形態が生まれたりワールプールが所有する、または他の人がそれに委託します。例：組織図、方針、手順、電話帳、研修教材の一部のタイプ。
WHIRLPOOL PUBLIC - Information officially released by Whirlpool for widespread public disclosure. Example: Press releases, public marketing materials, employment advertising, annual reports, product brochures, the public web site, etc.
WHIRLPOOL PUBLIC - 正式に広範な情報公開のためのワールプールによってリリース情報。例：プレスリリース、公共マーケティング資料、雇用広告、年次報告書、製品カタログ、公共のウェブサイトなど
The policy also states that privacy markings are allowable. Specifically:
ポリシーはまた、プライバシーのマーキングが許容されていると述べています。具体的に：
For WHIRLPOOL INTERNAL, additional markings or caveats are optional at the discretion of the information owner.
WHIRLPOOL INTERNALために、追加のマーキングまたは警告は、情報の所有者の裁量で任意です。
For WHIRLPOOL CONFIDENTIAL, add additional marking or caveats as
necessary to comply with regulatory or heightened security
requirements. Examples: MAKE NO COPIES, THIRD PARTY CONFIDENTIAL,
ATTORNEY-CLIENT PRIVILEGED DOCUMENT, DISTRIBUTION LIMITED TO ____,
COVERED BY A NON-ANALYSIS AGREEMENT.
RFC 2634 [ESS] defines the ESSSecurityLabel syntax and processing rules. This section builds upon those definitions to define detailed example policies.
RFC 2634 [ESS]はESSSecurityLabel構文と処理規則を定義します。このセクションでは、詳細な例ポリシーを定義するためにそれらの定義に基づいて構築します。
The examples are detailed using the various components of the eSSSecurityLabel syntax.
例はeSSSecurityLabel構文の様々な構成要素を用いて詳述します。
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 policy in force to which the security label relates. It indicates the semantics of the other security label components.
セキュリティポリシーは、セキュリティサービスの提供のための基準のセットです。 eSSSecurityLabelセキュリティポリシー識別子は、セキュリティラベルが関係する力のセキュリティポリシーを識別するために使用されます。これは、他のセキュリティ・ラベル・コンポーネントの意味を示します。
For the example policies, the following security policy object identifiers are defined:
たとえばポリシーについては、次のセキュリティポリシーのオブジェクト識別子が定義されています。
-- S/MIME Working Group Object Identifier Registry
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) 16 }
-- S/MIME Test Security Policy Arc
id-tsp OBJECT IDENTIFIER ::= { id-smime 7 }
-- 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 }
The security classification values and meanings are defined by the governing company policies. The security-classification values defined are hierarchical and do not use integers 0 through 5.
セキュリティ分類の値と意味は支配会社の方針によって定義されています。定義されたセキュリティ・分類値は階層的であり、5までの整数0を使用しないでください。
Amoco-SecurityClassification ::= INTEGER {
amoco-general (6),
amoco-confidential (7),
amoco-highly-confidential (8) }
Caterpillar-SecurityClassification ::= INTEGER {
caterpillar-public (6),
caterpillar-green (7),
caterpillar-yellow (8),
caterpillar-red (9) }
Whirlpool-SecurityClassification ::= INTEGER {
whirlpool-public (6),
whirlpool-internal (7),
whirlpool-confidential (8) }
Privacy marks are specified the Whirlpool policy. The policy
provides examples of possible markings but others can be defined by
users as necessary (though no 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.
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, and MINIMUM labels are examples of information classifications that are not used for access control.
アモコポリシーは、どのプライバシーマークを識別しませんが、可用性と整合性のために定義された分類ラベルは、最も適切にここに表示されます。 CRITICAL、MAXIMUM、MEDIUM、および最小のラベルは、アクセス制御のために使用されていない情報の分類の一例です。
In general, the privacy marks should provide brief but clear direction to the user on how to handle the information.
一般的には、プライバシーマークは、情報を処理する方法でユーザーに簡潔な、しかし、明確な方向性を提供する必要があります。
Security categories or caveats are not specified in any of the sample policies. However, they are used in at least 2 of the companies. Though the security categories are not defined formally in their 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 (i.e., Legal Only or Project Vallor).
セキュリティカテゴリまたは警告は、サンプルポリシーのいずれかで指定されていません。しかし、彼らは企業の少なくとも2で使用されています。セキュリティカテゴリは、セキュリティポリシーで正式に定義されていないものの、一度ローカルに定義された彼らは、正式であり、施行されることになります。識別可能な専有情報より詳細なアクセス制御を提供する際に必要なセキュリティカテゴリが定義されています。カテゴリが組織的またはプロジェクトによって基づくことができる（すなわち、法律のみまたはプロジェクトVallor）。
Security categories are represented in the RFC 2634 ESSSecurityLabel (to specify the sensitivity of labeled data) and X.501 Clearance attribute (to specify an entity's authorizations) using the following syntax.
セキュリティカテゴリはRFC 2634 ESSSecurityLabelで表され、X.501クリアランス属性（ラベル付きデータの感度を指定する）は、次の構文を使用して（エンティティの権限を指定します）。
SecurityCategories ::= SET SIZE (1..ub-security-categories)
OF SecurityCategory
ub-security-categories INTEGER ::= 64
SecurityCategory ::= SEQUENCE {
type [0] OBJECT IDENTIFIER
value [1] ANY DEFINED BY type } -- defined by type
One example of a SecurityCategory syntax is SecurityCategoryValues, as follows.
次のようにSecurityCategory構文の一例は、SecurityCategoryValuesです。
When id-securityCategoryValues is present in the SecurityCategory type field, then the SecurityCategory value field could take the form of:
ID-セキュリティカテゴリ値は、セキュリティカテゴリータイプフィールドに存在する場合には、その後、SecurityCategory値フィールドは次の形式を取ることができます。
SecurityCategoryValues ::= SEQUENCE OF UTF8String
An organization will define a securityCategoryType OID representing the syntax for representing a security category value within their security policy.
組織は、セキュリティポリシー内のセキュリティカテゴリ値を表すための構文を表すsecurityCategoryType OIDを定義します。
For the example security category syntax, a UTF8String is used to convey the security category value that applies to the labeled message. Access MUST be restricted to only those entities who are authorized to access every SecurityCategoryValue. Access is authorized if the ESSSecurityLabel SecurityCategoryValue EXACTLY matches the Clearance SecurityCategoryValue.
たとえば、セキュリティカテゴリの構文については、UTF8Stringを、標識されたメッセージに適用されるセキュリティカテゴリ価値を伝えるために使用されます。アクセスは、すべてのSecurityCategoryValueにアクセスすることを許可されたエンティティのみに制限されなければなりません。 ESSSecurityLabel SecurityCategoryValueが正確にクリアランスSecurityCategoryValueと一致した場合は、アクセスが許可されています。
The security clearance and category authorizations for the user are defined in the clearance attribute.
ユーザーのセキュリティクリアランスとカテゴリ権限はクリアランス属性で定義されています。
Clearance: policyId: 1 2 840 113549 1 9 16 7 1 classList: amoco-general (6), amoco-confidential (7), amoco-highly-confidential (8)
クリアランス：POLICYID：1 2 840 113549 1 9 16 7 1 CLASSLIST：アモコ・一般（6）、アモコ機密（7）、アモコ・機密性の高い（8）
Clearance: policyId: 1 2 840 113549 1 9 16 7 2 classList: caterpillar-public (6), caterpillar-confidential-green (7), caterpillar-confidential-yellow (8), caterpillar-confidential-red (9)
クリアランス：POLICYID：1 2 840 113549 1 9 16 7 2 CLASSLIST：キャタピラ公開（6）、キャタピラ機密グリーン（7）、キャタピラ機密黄色（8）、キャタピラ機密レッド（9）
Clearance: policyId: 1 2 840 113549 1 9 16 7 3 classList: whirlpool-public (6), whirlpool-internal (7), whirlpool-confidential (8)
クリアランス：POLICYID：1 2 840 113549 1 9 16 7 3 CLASSLIST：ジェット・パブリック（6）、ワール内部（7）、ワール機密（8）
This section includes an example RFC 2634 ESSSecurityLabel including the example Security Category syntax. This section also includes example X.501 Clearance attributes. One of the example Clearance attributes includes a set of authorizations that pass the access control check for the example ESSSecurityLabel. The other example Clearance attributes each include a set of authorizations that fail the access control check for the example ESSSecurityLabel.
このセクションでは、例のセキュリティカテゴリの構文を含む例RFC 2634 ESSSecurityLabelが含まれています。このセクションでは、また、例えばX.501クリアランス属性が含まれます。例えば、クリアランス属性の1つは、例えばESSSecurityLabelのアクセス制御チェックを通過権限のセットが含まれています。他の例示的なクリアランスは、それぞれが例えばESSSecurityLabelのアクセス制御チェックに失敗権限のセットを含む属性。
These examples use the id-tsp-TEST-Whirlpool OID defined in section 2.2.1.1. Assume that the security policy identified by id-tsp-TEST-Whirlpool defines one securityCategoryType OIDs as follows:
これらの例は、セクション2.2.1.1で定義されたID-TSP-TEST-ワールOIDを使用します。次のようにID-TSP-TEST-ワールによって識別されたセキュリティポリシーが1つのsecurityCategoryType OIDを定義すると仮定する。
id-tsp-TEST-Whirlpool-Categories OBJECT IDENTIFIER ::= { id-tsp 4 }
Example ESSSecurityLabel: security-policy-identifier: id-tsp-3 security-classification: 8 privacy-mark: ATTORNEY-CLIENT PRIVILEGED INFORMATION security-categories: SEQUENCE OF SecurityCategory
例えばESSSecurityLabel：セキュリティポリシー識別子：ID-TSP-3セキュリティ分類：8プライバシーマーク：弁護士CLIENT PRIVILEGED情報セキュリティカテゴリ：SecurityCategory OF SEQUENCE
SecurityCategory #1 type: id-tsp-4 value: LAW DEPARTMENT USE ONLY
SecurityCategory＃1タイプ：ID-TSP-4値：法律部門のみを使用
Example Clearance Attribute #1 (passes access control check):
例クリアランス属性＃1は、（アクセス制御チェックをパス）：
Clearance: policyId: id-tsp-3 classList BIT STRING: Bits 6, 7, 8 are set to TRUE securityCategories: SEQUENCE OF SecurityCategory
クリアランス：POLICYID：ID-TSP-3 CLASSLISTビット列：ビット6、7、8はTRUE securityCategoriesに設定されている：SecurityCategory OF SEQUENCE
SecurityCategory #1 type: id-tsp-4 value: LAW DEPARTMENT USE ONLY
SecurityCategory＃1タイプ：ID-TSP-4値：法律部門のみを使用
Example Clearance Attribute #2 (fails access control check because SecurityCategoryValues do not match):
例クリアランス属性＃2（SecurityCategoryValuesが一致しないため、アクセス制御チェックに失敗しました）：
Clearance: policyId: id-tsp-3 classList BIT STRING: Bits 6, 7, 8 are set to TRUE securityCategories: SEQUENCE OF SecurityCategory
クリアランス：POLICYID：ID-TSP-3 CLASSLISTビット列：ビット6、7、8はTRUE securityCategoriesに設定されている：SecurityCategory OF SEQUENCE
SecurityCategory #1: type: id-tsp-4 value: HUMAN RESOURCES USE ONLY
SecurityCategory＃1：タイプ：ID-TSP-4値：人材ONLY USE
An implementation issue can be the mapping of the security label values to displayable characters. This is an issue for users who want to develop and retire their own classifications and categories on a regular basis and when the values are encoded in non-human readable form. Applications should provide a means for the enterprise to manage these changes. The practice of hard coding the mapping into the applications is discouraged.
実装上の問題が表示可能な文字にセキュリティラベル値のマッピングすることができます。これは、開発した値が非人間が読める形式でエンコードされている場合、定期的に自分の分類とカテゴリを引退し、したいユーザーのための問題です。アプリケーションは、企業がこれらの変更を管理するための手段を提供する必要があります。アプリケーションへのマッピングをハードコーディングの実践はお勧めしません。
This issue is viewed as local issue for the application vendor, as the solution does not need to be interoperable between vendors.
解決策は、ベンダー間の相互運用可能である必要はありませんので、この問題は、アプリケーションベンダーのためのローカルな問題と見られています。
An approach is the use of a Security Policy Information File (SPIF) [ISO15816]. A SPIF is a construct that conveys domain-specific security policy information. It is a signed 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.
アプローチは、セキュリティポリシー情報ファイル（SPIF）[ISO15816]の使用です。 SPIFは、ドメイン固有のセキュリティポリシー情報を伝える構造です。不正な変更から保護するために、ポリシー情報のソースを認証するために署名したオブジェクトです。このようなセキュリティの分類とユーザーだけでなく、追加のセキュリティポリシー情報に表示されるセキュリティカテゴリのためのテキスト文字列として重要な表示情報が含まれています。
Another implementation issue can be obtaining the recipient's certificate when sending a signed-only message with a security label. Normally the recipient's certificate is only needed when sending an encrypted message. Applications will need to be able to retrieve the recipient's certificate so that the recipient's clearance information is available for the access control check.
セキュリティラベルと署名のみのメッセージを送信するときには、別の実装の問題は、受信者の証明書を取得することができます。暗号化されたメッセージを送信する際に、通常、受信者の証明書のみを必要とされています。アプリケーションは、受信者のクリアランス情報は、アクセス制御チェックのために利用できるように、受信者の証明書を取得することができるようにする必要があります。
All security considerations from RFC 2630 [CMS] and RFC 2634 [ESS] apply to applications that use procedures described in this document.
すべてのRFC 2630からのセキュリティ上の考慮事項[CMS]およびRFC 2634 [ESS]は、この文書に記載されている手順を使用するアプリケーションに適用されます。
References
リファレンス
[AC509] Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002.
[AC509]ファレル、S.とR. Housley氏、 "認可のためのインターネット属性証明書プロフィール"、RFC 3281、2002年4月。
[CERTCRL] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[CERTCRL] Housley氏、R.、ポーク、W.、フォード、W.およびD.ソロ、 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィール"、RFC 3280、2002年4月。
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
[CMS] Housley氏、R.、 "暗号メッセージ構文"、RFC 2630、1999年6月。
[ESS] Hoffman, P., Editor, "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[ESS]ホフマン、P.、エディタ、 "S / MIMEのためのセキュリティサービスの強化"、RFC 2634、1999年6月。
[MUSTSHOULD] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[MUSTSHOULD]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[X.501] "ITU-T Recommendation X.501: Information Technology - Open Systems Interconnection - The Directory: Models", 1993.
[X.501] "ITU-T勧告X.501：情報技術 - 開放型システム間相互接続 - ディレクトリ：モデル"、1993年。
[X.509] "ITU-T Recommendation X.509 (1997 E): Information Technology - Open Systems Interconnection - The Directory: Authentication Framework", June 1997.
[X.509] "ITU-T勧告X.509（1997 E）：情報技術 - 開放型システム間相互接続 - ディレクトリ：認証フレームワーク"、1997年6月。
[ISO15816] "Information Technology - Security Techniques - Security Information Objects for Access Control", ISO/IEC FDIS 15816:2000.
[ISO15816] "情報技術 - セキュリティ技術 - アクセス制御のためのセキュリティ情報オブジェクト"、ISO / IEC FDISに15816：2000。
Acknowledgements
謝辞
I would like to thank Russ Housley for helping me through the process of developing this document, John Pawling for his technical assistance and guidance, and Dan Quealy for his security policy expertise. I would like to thank Ernst & Young LLP and Telenisus for supporting the development of this document while I was employed there. I would also like to thank the good people at Amoco (bp), Caterpillar and Whirlpool who allowed me to use their policies as the real examples that make this document possible.
私は彼の安全保障政策の専門知識のための彼の技術支援とご指導を、この文書、ジョンPawlingの開発プロセスを通じて、私を助けるためラスHousleyに感謝したい、とダンQuealyでしょう。私は私が採用している間に、このドキュメントの開発を支援するためにアーンスト・アンド・ヤングLLPとTelenisusに感謝したいと思います。私はまた、私は、この文書を可能にする実例としてのポリシーを使用することができアモコ（BP）、キャタピラーやワールプールで善良な人々に感謝したいと思います。
Caterpillar and Whirlpool were each asked if they would like to provide contacts in regards to their security policies, but declined the offer.
キャタピラーとワールプールは、それぞれ、彼らのセキュリティポリシーに関しての連絡先を提供したい場合尋ねたが、断りました。
Author's Address
著者のアドレス
Weston Nicolls Forsythe Solutions 7500 Frontage Rd Skokie, IL 60077
ウェストンNicollsフォーサイス・ソリューションズ7500間口Rdのスコーキー、IL 60077
Phone: (847) 763-2370 EMail: wnicolls@forsythesolutions.com
電話：（847）763-2370 Eメール：wnicolls@forsythesolutions.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。