[要約] RFC 3114は、S/MIMEセキュリティラベルを使用して企業の分類ポリシーを実装するためのガイドラインです。このRFCの目的は、電子メールのセキュリティを向上させ、情報の機密性と整合性を確保するために、企業がセキュリティラベルを使用してメッセージを分類する方法を提供することです。
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
S/MIMEセキュリティラベルを使用して会社分類ポリシーを実装する
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.
Copyright（c）The Internet Society（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セキュリティラベルにマッピングする方法について説明します。3社の実際のポリシーは、実用的な例を提供します。
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].
「必須」、「必要」、「必須」、「」、「しない」、「そうでない」、「そうではない」、「そうではない」、「勧めない」、「5月」、「オプション」は、このドキュメントの「オプション」です。RFC 2119 [必須]に記載されているように解釈される。
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.
- IDベースのアクセス制御は、個々の個人またはホストエンティティ、またはそのようなエンティティの定義されたグループに明示的に適用されるポリシーに基づいています。IDが認証されたら、IDがアクセスリストにあると確認された場合、アクセスが許可されます。
- 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).
X.501は、クリアランスを指定されたエンティティに結合するための2つの手段を指摘します。属性証明書と証明書拡張フィールド（たとえば、SubjectDirectoryAttribute Extension内）。
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.
AMOCO情報分類ポリシーの説明は、AMOCOコンピューターセキュリティガイドラインから取得されました。AMOCOは、機密性と整合性に基づいて情報資産を分類し、それぞれの3つの階層分類を定義します。機密性と整合性ポリシーは独立しているため、どちらかまたは両方が情報に適用される場合があります。Amocoは、時間の重要な情報の可用性分類も定義しています。
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.
機密 - 不正な開示が会社に財政、法的、または評判の損害を引き起こす可能性がある情報。 例：従業員担当者と給与ファイル、解釈された探索データ。
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.
一般 - 個人的、技術的、またはビジネス上の感度が会社内での使用のために制限されているため、情報。別段の分類がない限り、AMOCO内のすべての情報はこのカテゴリにあります。
MAXIMUM - Information whose unauthorized modification and destruction will cause the company severe financial, legal, or reputation damage.
最大 - 不正な変更と破壊が会社に重度の財務、法的、または評判の損害を引き起こすことを引き起こす情報。
MEDIUM - Information whose unauthorized modification and destruction may cause the company financial, legal, or reputation damage. Examples: Electronic Funds, Transfer, Payroll, and Commercial Checks.
媒体 - 不正な変更と破壊が会社に財政、法的、または評判の損害を引き起こす可能性がある情報。例：電子ファンド、譲渡、給与、商業小切手。
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.
最小 - このデータのエラーは最小限の結果になりますが、これは依然として重要な企業情報であるため、データの整合性が維持されるという最小レベルの保証を確保するために最小限の制御が必要です。これは、上記の分類のいずれかに配置されていないすべてのデータに適用されます。例：生産データ、経費データ、財務データ、および探査データのリース。
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 from the Caterpillar Information Protection Guidelines. Caterpillar classifies its information assets based on confidentiality and defines 4 hierarchical classifications.
Caterpillar情報分類ポリシーの説明は、Caterpillar情報保護ガイドラインから取得されています。Caterpillarは、機密性に基づいて情報資産を分類し、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 Red-大きな競争上の優位性を提供します。開示は、運用に深刻な損害を引き起こすでしょう。長期的な戦略または重要なビジネス計画に関連するか、説明しています。開示は、規制または契約上の責任を引き起こします。開示は、私たちの評判や公共イメージに深刻な損害を与えるでしょう。開示は、市場シェアの深刻な損失または最初に市場に出る能力を引き起こします。開示は、重要な顧客、株主、またはビジネスパートナーの損失を引き起こします。開示は、株価の長期的または深刻な低下を引き起こします。強い可能性が誰かがこの情報を取得しようとしています。
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 Yellow-競争上の優位性を提供します。開示は、会社または個人に適度な損害を引き起こす可能性があります。時間の経過とともに、会社の運用方向の重要な部分に関連するか、説明しています。製品ラインまたはビジネスユニットの重要な技術的または財政的側面。開示は、顧客または株主の信頼の損失を引き起こす可能性があります。開示は、株価の一時的な低下を引き起こす可能性があります。誰かがこの情報を取得しようとする可能性。
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 Confidential Green-同じ情報にアクセスできない人々よりもビジネス上の利点を提供する可能性があります。競合他社にとって有用かもしれません。製品の検査で簡単に識別できません。社外では一般的に知られていないか、公開源から入手できません。一般的に内部で利用可能です。競争力のない関心はほとんどありません。
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.
Caterpillar Public-ビジネスや競争上の優位性は提供されません。一般の人々の関心のあるメンバーが日常的に利用できるようにしました。競争力のある利息はほとんどまたはまったくありません。
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:
Whirlpool情報分類ポリシーの説明は、Whirlpool Information保護ポリシーから取得されます。Whirlpoolは、機密性に基づいて情報資産を分類し、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 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によって生成されるすべての情報、書面、口頭、または電子の形で、あらゆる形で、Whirlpool内部またはWhirlpoolの機密として扱われることになります。どちらのカテゴリでも、その価値、不正開示の影響、法的要件の影響に依存します。、そしてそれが会社が使用する必要がある方法。いくつかのWhirlpoolの内部情報は、公開のために許可される場合があります。」Whirlpool Confidential- Whirlpoolの内部情報のサブセット、不正な開示または妥協は、会社の競争力に悪影響を与える可能性が高い、その評判を傷つけるか、個人を恥ずかしく思うでしょう。例：顧客、財務、価格、または人事データ。合併/買収、製品、またはマーケティング計画。新製品の設計、独自のプロセス、システム。
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が発信または所有しているあらゆる形態の独自の情報、または他の人がそれに委ねられています。例：組織チャート、ポリシー、手順、電話ディレクトリ、いくつかのタイプのトレーニング資料。
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 -Wirlpoolが広範な公開開示のために公式にリリースした情報。例：プレスリリース、パブリックマーケティング資料、雇用広告、年次報告書、製品パンフレット、パブリックWebサイトなど。
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内部の場合、情報所有者の裁量で追加のマーキングまたは警告がオプションです。
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 Security-Policy-Identifierは、セキュリティラベルが関連する有効なセキュリティポリシーを特定するために使用されます。他のセキュリティラベルコンポーネントのセマンティクスを示します。
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.
セキュリティ分類値と意味は、政府の会社のポリシーによって定義されます。定義されたセキュリティ分類値は階層的であり、整数0〜5を使用しません。
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.
AMOCOポリシーはプライバシーマークを特定しませんが、可用性と整合性のために定義された分類ラベルがここに最も適切に表示されます。クリティカル、最大、メディア、および最小のラベルは、アクセス制御には使用されていない情報分類の例です。
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 ESSSECURTYLABEL（ラベル付きデータの感度を指定するため）および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.
セキュリティカテゴリの構文の1つの例は、次のようにセキュリティカテゴリバリューです。
When id-securityCategoryValues is present in the SecurityCategory type field, then the SecurityCategory value field could take the form of:
ID-SecurityCategoryValuesがSecurityCategoryタイプフィールドに存在する場合、SecurityCategory Valueフィールドは以下の形をとることができます。
SecurityCategoryValues ::= SEQUENCE OF UTF8String
An organization will define a securityCategoryType OID representing the syntax for representing a security category value within their security policy.
組織は、セキュリティポリシー内のセキュリティカテゴリ値を表すための構文を表すセキュリティCATECTORYTYPE 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クラスリスト：Amoco-General（6）、Amoco Compenfidential（7）、Amoco-HighlyConfidential（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クラスリスト：Caterpillar-Public（6）、Caterpillar-Confidential-Green（7）、Caterpillar-Confidential-Yellow（8）、Caterpillar Compidential-Red（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クラスリスト：Whirlpool-Public（6）、Whirlpool-Internal（7）、Whirlpool-Confidential（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の例のアクセス制御チェックに合格する一連の承認が含まれています。もう1つのクリアランス属性には、それぞれ、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-WHIRLPOOL OIDを使用しています。ID-TSP-Test-Whirlpoolによって特定されたセキュリティポリシーが、1つのセキュリティCATECTORYTYPE 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
ESSSECURTYLABEL：SECURITY-Policy-Identifier：ID-TSP-3セキュリティ分類：8 Privacy-Mark：Attorney-Client特権情報セキュリティカテゴリ：セキュリティカテゴリのシーケンス
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クラスリストビット文字列：ビット6、7、8はTRUEセキュリティカテゴリに設定されています：セキュリティカテゴリのシーケンス
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クラスリストビット文字列：ビット6、7、8はTRUEセキュリティカテゴリに設定されています：セキュリティカテゴリのシーケンス
SecurityCategory #1: type: id-tsp-4 value: HUMAN RESOURCES USE ONLY
SecurityCategory＃1：タイプ：ID-TSP-4値：人事の使用のみ
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] Farrell、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.、Polk、W.、Ford、W.、D。Solo、「インターネット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] Hoffman、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.
[必須] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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.
このドキュメントの開発プロセス、ジョン・ポーリングが彼の技術支援とガイダンス、そして彼のセキュリティポリシーの専門知識について、私を助けてくれたRuss Housleyに感謝したいと思います。私がそこで雇用されている間、この文書の開発をサポートしてくれたErnst＆Young LLPとTelenisusに感謝します。また、Amoco（BP）、Caterpillar、Whirlpoolの善良な人々に感謝したいと思います。
Caterpillar and Whirlpool were each asked if they would like to provide contacts in regards to their security policies, but declined the offer.
CaterpillarとWhirlpoolはそれぞれ、セキュリティポリシーに関して連絡先を提供したいかどうかを尋ねられましたが、申し出は拒否されました。
Author's Address
著者の連絡先
Weston Nicolls Forsythe Solutions 7500 Frontage Rd Skokie, IL 60077
ウェストンニコルズフォーサイスソリューション7500 Frontage RD Skokie、IL 60077
Phone: (847) 763-2370 EMail: wnicolls@forsythesolutions.com
電話：（847）763-2370メール：wnicolls@forsythesolutions.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。