RFC3114 日本語訳

Network Working Group                                         W. Nicolls
Request for Comments: 3114                            Forsythe Solutions
Category: Informational                                         May 2002

コメントを求めるワーキンググループW.ニコルズの要求をネットワークでつないでください: 3114年のフォーサイスソリューションカテゴリ: 情報の2002年5月

              Implementing Company Classification Policy
                     with the S/MIME Security Label

S/MIME機密保護ラベルで会社分類が方針であると実装します。

Status of this Memo

この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)インターネット協会(2002)。 All rights reserved。

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つの会社からの実際の政策は扱われた例を提供します。

1. Introduction

1. 序論

   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のための任意のセキュリティー・サービスです。 機密保護ラベルは1セットのS/MIMEカプセル化によって保護される内容の感度のセキュリティ情報です。 どんなSignedDataオブジェクトの署名している属性にも機密保護ラベルを含むことができます。 機密保護ラベル属性は内側の署名、外側の署名、または両方に含まれるかもしれません。 機密保護ラベルのための構文と処理規則はRFC2634[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'、RFC2119[MUSTSHOULD]で説明されるように本書ではNOTと、'''REQUIRED'、'SHALL'、'SHALL NOT'、'SHOULD'、'SHOULD NOT'、'RECOMMENDED'、'5月'、およびOPTIONAL'を解釈することになっていなければなりませんか?

1.1 Information Classification Policies

1.1 情報分類方針

   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

会社によって開発されて、使用された研究開発プラン、販売戦略、および製造品質規格は競争力において有利な立場を供給します。 このタイプの情報ニーズ

Nicolls                      Informational                      [Page 1]

RFC 3114       Implementing Company Classification Policy       May 2002

会社分類方針5月が2002であると実装するニコルズ情報[1ページ]のRFC3114

   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.).

企業情報分類方針は保護される情報資産がことである方法を定義します。 それはどう情報資産を分類するかの従業員に指導を提供します。 それはどのようにその分類と状態(例えば、ファクシミリ、電信振替、ストレージ、出荷など)に基づく資産をラベルして、保護するかを定義します。

1.2 Access Control and Security Labels

1.2 アクセスコントロールと機密保護ラベル

   "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.

- ベースのアクセスコントロールがalgorithmicallyに言い表すことができる方針に基づいていると裁決してください。

   - 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.

- ランクベースアクセスコントロールは組織で階層的位置の方針に基づいています。 それはあなたが社内体制のだれであるかに基づいています。 ランクベースの方針がPartnerかシニアConsultantの位置が定義できたすべての情報を定義するだろう、アクセサリー

   - 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.

- 役割に基づいているアクセスコントロールは組織における役割の方針に基づいています。 それは階層的であるかもしれません。 それはあなたが会社でだれであるかに基づいています。 役割のベースの方針がDatabase Administrator、Network Administrator、Mailroom ClerkまたはPurchaserの役割が定義できたすべての情報を定義するだろう、アクセサリー

   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を処理するとき、受取人が保護された内容にアクセスできるかどうか決定するためにメッセージの機密保護ラベルの感度情報を受取人の承認にたとえることができます。

Nicolls                      Informational                      [Page 2]

RFC 3114       Implementing Company Classification Policy       May 2002

会社分類方針5月が2002であると実装するニコルズ情報[2ページ]のRFC3114

   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機密保護ラベルは署名している属性として内側(単に)の署名か外側の署名に含まれるかもしれません。 RFC2634の定義されるとしての3倍包装されたメッセージの場合では、内側の署名は平文オリジナルコンテンツに関連するアクセス制御決定に使用されるでしょう、外側の署名が暗号化メッセージに関連するアクセス制御決定に使用されるでしょうが。

1.3 User Authorizations

1.3 ユーザ承認

   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証明書[CERTCRL]のためのX.509[X.509]とインターネットプロフィールは証明書で承認を表して、伝える手段を定義しません。

   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つの手段に注意します: Attribute CertificateとCertificate拡大分野(例えば、subjectDirectoryAttribute拡張子の中の)。

   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.

RFC3281[AC509]は承認情報によってインターネットプロトコルの中で使用に適したX.509 Attribute Certificate(西暦)のプロフィールを定義します。 定義された属性の1つはClearanceです。(そのClearanceは交流所有者のクリアランス(セキュリティラベリング)情報を運びます)。 Clearanceのための構文はX.501からインポートされます。

2. Developed Examples

2. 開発された例

2.1 Classification Policies

2.1 分類方針

   The following describes the information classification policies in
   effect at 3 companies.

事実上、以下は3つの会社で情報分類方針を説明します。

2.1.1 Amoco Corporation

2.1.1 アモコ社

   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

アモココンピュータSecurity Guidelinesからアモコ情報分類方針のための記述を取りました。 アモコは、秘密性と保全に基づく情報資産を分類して、それぞれのために3つの序列的な分類を定義します。 秘密性

Nicolls                      Informational                      [Page 3]

RFC 3114       Implementing Company Classification Policy       May 2002

会社分類方針5月が2002であると実装するニコルズ情報[3ページ]のRFC3114

   and integrity polices are independent, so either or both may be
   applied to the information.  Amoco also defines an availability
   classification for time critical information.

そして、保全が取り締まる、独立しているので、どちらかかともに情報に適用されるかもしれません。 また、アモコは時間重要情報のための有用性分類を定義します。

   HIGHLY CONFIDENTIAL - Information whose unauthorized disclosure will
   cause the company severe financial, legal or reputation damage.
   Examples: Certain acquisitions, bid economics, negotiation
   strategies.

HIGHLY CONFIDENTIAL--不当開示が厳しい状態で会社を引き起こすために財政的に望んでいる情報、法的であるか評判損害。 例: ある獲得、付け値の経済学、交渉戦略。

   CONFIDENTIAL - Information whose unauthorized disclosure may cause
   the company financial, legal, or reputation damage.  Examples:
   Employee Personnel & Payroll Files, some interpreted Exploration
   Data.

CONFIDENTIAL--不当開示が財政的に会社を引き起こすかもしれない法的な情報か評判損害。 例: 従業員Personnel&Payroll Files、或るものは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.

個人的であるか、技術的であるか、またはビジネスの感度によるそれはそうです。一般--情報、使用のために、会社の中で制限されます。 別の方法で分類されない場合、アモコの中のすべての情報がこのカテゴリにあります。

   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--このデータにおける誤りは最小量の結果のものでしょうが、これは、それでも、重要な会社の情報であり、したがって、データの保全が維持されるという最小量のレベルを保証を確実にするためにいくつかの最小量のコントロールを必要とするでしょう。 これは上の分類の1つに置かれるというわけではないすべてのデータに適用されます。 例: 生産データ、費用データ、財政データ、および探検データを賃貸してください。

   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--ビジネス決定が、追加リソースを費やす前に許容できる使用不能の長さが必要である情報の有用性を確実にすることを決定するのに必要でしょう。 特別な手順が有用性を確実にするのに用いられるのが、決定しているなら、情報は「重要である」とラベルされるべきです。

2.1.2 Caterpillar, Inc.

2.1.2 イモムシ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情報Protection GuidelinesからCaterpillar情報分類方針のための記述を取ります。 イモムシは、秘密性に基づく情報資産を分類して、4つの序列的な分類を定義します。

Nicolls                      Informational                      [Page 4]

RFC 3114       Implementing Company Classification Policy       May 2002

会社分類方針5月が2002であると実装するニコルズ情報[4ページ]のRFC3114

   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.

イモムシ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.

イモムシConfidential Yellow--競争力において有利な立場を供給します。 公開は会社か個人への適度の損害をもたらすかもしれません。 時間がたつにつれて、会社の操作上の方向の重要な部分について関連するか、または説明します。 製品ラインかビジネス部の重要な技術的であるか財政的な局面。 公開はCustomerの損失かShareholder信用を引き起こす場合がありました。 公開は株式価値の一時的な低下を引き起こす場合がありました。 だれかがこの情報を取得しようとするかもしれないという見込み。

   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.

イモムシConfidentialグリーン--同じ情報に近づく手段を持っていない人よりビジネス利点を提供するかもしれません。 競争相手の役に立つかもしれなくなってください。 製品の点検は容易に身元保証可能ではありません。 一般に、社外のときに知られないか、または公共のソースから利用可能です。 一般に利用可能である、内部的に。 少ない競争の激しい関心。

   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.

イモムシPublic--ビジネスか競争力において有利な立場を供給しないでしょう。 きまりきって司令官のPublicの関心があるメンバーにとって利用可能に作られています。 ほとんど競争の激しい関心がありません。

2.1.3 Whirlpool Corporation

2.1.3 渦巻社

   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情報Protection Policyから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かいかなるフォームでのWhirlpoolのためにも生成されたすべての書かれたか、言葉であることの、または、電子である情報は、WHIRLPOOL INTERNALかWHIRLPOOL CONFIDENTIALとして扱われることです。」 どちらかのカテゴリにおける、情報の分類は値、不当開示の影響、法的必要条件、およびそれが、会社によって使用される必要がある方法に依存します。 「何らかのWHIRLPOOL INTERNAL情報が公共のリリースのために認可されるかもしれません。」

Nicolls                      Informational                      [Page 5]

RFC 3114       Implementing Company Classification Policy       May 2002

会社分類方針5月が2002であると実装するニコルズ情報[5ページ]のRFC3114

   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情報の部分集合、不当開示または感染が会社の競争力がある姿勢におそらく悪影響を持っているか、評判を曇らせるか、または個人を当惑させる。 例: 財政的で、値を付けている顧客、または人員データ。 合併/獲得、製品、またはマーケティングが計画されています。 新しい製品デザイン、独自の工程、およびシステム。

   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--広範囲のパブリックディスクロージャのためにWhirlpoolによって公式に発表された情報。 例: プレスリリース、公共のマーケティングの材料、雇用広告、年次報告、製品カタログ、公共のウェブサイトなど

   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.

WHIRLPOOL CONFIDENTIALに関しては、必要に応じて追加マークか警告を加えて、規定の、または、高められたセキュリティ要件に従ってください。 例: 弁護士クライアントがドキュメント、分配株式会社に特権を与えさせたどんな第三者秘密のコピーも作らないでください。____, 非分析協定で、カバーされます。

2.2 S/MIME Classification Label Organizational Examples

2.2秒間/MIMEの分類のラベルの組織的な例

   RFC 2634 [ESS] defines the ESSSecurityLabel syntax and processing
   rules.  This section builds upon those definitions to define detailed
   example policies.

RFC2634[ESS]はESSSecurityLabel構文と処理規則を定義します。 このセクションは、詳細な例の方針を定義するためにそれらの定義を当てにします。

2.2.1 Security Label Components

2.2.1 機密保護ラベルの部品

   The examples are detailed using the various components of the
   eSSSecurityLabel syntax.

例はeSSSecurityLabel構文の様々な成分を使用するのにおいて詳細です。

2.2.1.1 Security Policy Identifier

2.2.1.1 安全保障政策識別子

   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.

安全保障政策はセキュリティー・サービスの支給のための1セットの評価基準です。 機密保護ラベルが関係するeSSSecurityLabelセキュリティ方針識別子は大挙して安全保障政策を特定するのが使用されます。 それは他の機密保護ラベルの部品の意味論を示します。

Nicolls                      Informational                      [Page 6]

RFC 3114       Implementing Company Classification Policy       May 2002

会社分類方針5月が2002であると実装するニコルズ情報[6ページ]のRFC3114

   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作業部会Object Identifier Registryイド-smime OBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9)16をメンバーと同じくらい具体化させます。

   -- S/MIME Test Security Policy Arc
   id-tsp  OBJECT IDENTIFIER ::= { id-smime 7 }

-- MIME Test Security Policy ArcイドS/ティースプーンフルOBJECT IDENTIFIER:、:= イド-smime7

   -- 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 }

-- 安全保障政策をテストしてください、イドティースプーンフル試アモコ、オブジェクト識別子:、:= イドティースプーンフル1、イドティースプーンフルTESTイモムシOBJECT IDENTIFIER:、:= イドティースプーンフル2イドティースプーンフルTEST渦巻OBJECT IDENTIFIER:、:= イドティースプーンフル3

2.2.1.2 Security Classification

2.2.1.2 セキュリティ分類

   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) }

アモコ-SecurityClassification:、:= 整数amoco一般的な(6)、amoco秘密の(7)、amocoに非常に秘密である、(8)

   Caterpillar-SecurityClassification ::= INTEGER {
     caterpillar-public (6),
     caterpillar-green (7),
     caterpillar-yellow (8),
     caterpillar-red (9) }

イモムシ-SecurityClassification:、:= 整数イモムシ公共の(6)、イモムシ緑色の(7)、イモムシ黄色い(8)、イモムシ赤い(9)

   Whirlpool-SecurityClassification ::= INTEGER {
     whirlpool-public (6),
     whirlpool-internal (7),
     whirlpool-confidential (8) }

渦巻-SecurityClassification:、:= 整数渦巻公共の(6)、渦巻内部の(7)、渦巻秘密の(8)

2.2.1.3 Privacy Mark

2.2.1.3 プライバシーマーク

   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.

プライバシーマークは指定されます。Whirlpool方針。 方針は可能な印に関する例を提供しますが、ユーザは他のものを必要であると定義できます(指導を全く与えませんが)。 Whirlpool方針は以下の例を提供します: 弁護士クライアントがドキュメント、分配株式会社に特権を与えさせたどんな第三者秘密のコピーも作らないでください。____, そして、非分析協定で、カバーされました。

Nicolls                      Informational                      [Page 7]

RFC 3114       Implementing Company Classification Policy       May 2002

会社分類方針5月が2002であると実装するニコルズ情報[7ページ]のRFC3114

   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、およびMINIMUMラベルはアクセスコントロールに使用されない情報分類に関する例です。

   In general, the privacy marks should provide brief but clear
   direction to the user on how to handle the information.

一般に、プライバシーマークはユーザへのどう情報を扱うかに関する簡潔な、しかし、明確な方向を提供するべきです。

2.2.1.4 Security Categories

2.2.1.4 セキュリティカテゴリ

   Security categories 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つの会社に使用されます。 セキュリティカテゴリはそれらの安全保障政策では正式に定義されませんが、いったん局所的に定義されると、それらは、正式であり、実施されることになっています。 身元保証可能な知的財産情報より粒状のアクセスコントロールを提供するのに必要であるときに、セキュリティカテゴリは定義されます。 カテゴリは組織的かプロジェクト(すなわち、Legal OnlyかProject Vallor)によって基づくことができます。

2.2.1.4.1 Syntax

2.2.1.4.1 構文

   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.

セキュリティカテゴリは、RFC2634ESSSecurityLabel(ラベルされたデータの感度を指定する)とX.501 Clearance属性(実体の承認を指定する)で以下の構文を使用することで表されます。

   SecurityCategories ::= SET SIZE (1..ub-security-categories)
                          OF SecurityCategory

SecurityCategories:、:= SecurityCategoryのサイズ(1..ubセキュリティカテゴリ)を設定してください。

   ub-security-categories INTEGER ::= 64

ubセキュリティカテゴリINTEGER:、:= 64

   SecurityCategory ::= SEQUENCE {
     type  [0] OBJECT IDENTIFIER
     value [1] ANY DEFINED BY type } -- defined by type

SecurityCategory:、:= SEQUENCEは[0] OBJECT IDENTIFIER値[1]ANY DEFINED BYタイプをタイプします--タイプによって定義されます。

   One example of a SecurityCategory syntax is SecurityCategoryValues,
   as follows.

SecurityCategory構文に関する1つの例が以下のSecurityCategoryValuesです。

   When id-securityCategoryValues is present in the SecurityCategory
   type field, then the SecurityCategory value field could take the form
   of:

イド-securityCategoryValuesがSecurityCategoryタイプ分野に存在していると、SecurityCategory値の分野は以下の形を取るかもしれません。

   SecurityCategoryValues ::= SEQUENCE OF UTF8String

SecurityCategoryValues:、:= UTF8Stringの系列

Nicolls                      Informational                      [Page 8]

RFC 3114       Implementing Company Classification Policy       May 2002

会社分類方針5月が2002であると実装するニコルズ情報[8ページ]のRFC3114

2.2.1.4.2 Use

2.2.1.4.2 使用

   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 EXACTLYがClearance SecurityCategoryValueに合っているなら、アクセスは認可されています。

2.2.2 Attribute Owner Clearance

2.2.2 属性所有者クリアランス

   The security clearance and category authorizations for the user are
   defined in the clearance attribute.

ユーザのための機密取扱者の人物調査とカテゴリ承認はクリアランス属性で定義されます。

2.2.2.1 Amoco User

2.2.2.1 アモコのユーザ

   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 1classList: amoco一般的な(6)、amoco秘密の(7)、amocoに非常に秘密(8)

2.2.2.2 Caterpillar User

2.2.2.2 イモムシユーザ

   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 2classList: イモムシ公共の(6)、イモムシの秘密の緑色(7)、イモムシの秘密の黄色(8)、イモムシの秘密の赤(9)

2.2.2.3 Whirlpool User

2.2.2.3 渦巻ユーザ

   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 3classList: 渦巻内部の(7)の、そして、渦巻秘密の渦巻公共の(6)(8)

Nicolls                      Informational                      [Page 9]

RFC 3114       Implementing Company Classification Policy       May 2002

会社分類方針5月が2002であると実装するニコルズ情報[9ページ]のRFC3114

2.2.3 Security Category Example

2.2.3 セキュリティカテゴリの例

   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.

このセクションは例のSecurity Category構文を含む例RFC2634のESSSecurityLabelを含んでいます。 また、このセクションは例のX.501 Clearance属性を含んでいます。 例のClearance属性の1つは例のESSSecurityLabelのためにアクセス制御チェックを通過する1セットの承認を含んでいます。 他の例のClearance属性はそれぞれ例のESSSecurityLabelのためにアクセス制御チェックに失敗する1セットの承認を含んでいます。

   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で定義されたイドティースプーンフルTEST渦巻OID.1を使用します。 イドティースプーンフルTEST-渦巻によって特定された安全保障政策が以下の1securityCategoryType OIDsを定義すると仮定してください:

   id-tsp-TEST-Whirlpool-Categories OBJECT IDENTIFIER ::= { id-tsp 4 }

イドティースプーンフル試しに渦巻カテゴリオブジェクト識別子:、:= イドティースプーンフル4

   Example ESSSecurityLabel:
    security-policy-identifier: id-tsp-3
    security-classification: 8
    privacy-mark: ATTORNEY-CLIENT PRIVILEGED INFORMATION
    security-categories: SEQUENCE OF SecurityCategory

例のESSSecurityLabel: セキュリティ方針識別子: イドティースプーンフル3セキュリティ分類: 8プライバシーマーク: 弁護士-CLIENT PRIVILEGED INFORMATIONセキュリティカテゴリ: SecurityCategoryの系列

   SecurityCategory #1
     type:  id-tsp-4
     value:  LAW DEPARTMENT USE ONLY

SecurityCategory#1、はタイプされます: イドティースプーンフル4値: 法律部使用だけ

   Example Clearance Attribute #1 (passes access control check):

例Clearance Attribute#1(アクセス制御チェックを通過します):

   Clearance:
     policyId: id-tsp-3
     classList BIT STRING: Bits 6, 7, 8 are set to TRUE
     securityCategories: SEQUENCE OF SecurityCategory

クリアランス: policyId: イドティースプーンフル3classList BIT STRING: ビット6、7、8はTRUE securityCategoriesに設定されます: SecurityCategoryの系列

   SecurityCategory #1
     type:  id-tsp-4
     value:  LAW DEPARTMENT USE ONLY

SecurityCategory#1、はタイプされます: イドティースプーンフル4値: 法律部使用だけ

   Example Clearance Attribute #2 (fails access control check because
   SecurityCategoryValues do not match):

例Clearance Attribute#2(SecurityCategoryValuesが合っていないので、アクセス制御チェックに失敗します):

   Clearance:
     policyId: id-tsp-3
     classList BIT STRING: Bits 6, 7, 8 are set to TRUE
     securityCategories: SEQUENCE OF SecurityCategory

クリアランス: policyId: イドティースプーンフル3classList BIT STRING: ビット6、7、8はTRUE securityCategoriesに設定されます: SecurityCategoryの系列

Nicolls                      Informational                     [Page 10]

RFC 3114       Implementing Company Classification Policy       May 2002

会社分類方針5月が2002であると実装するニコルズ情報[10ページ]のRFC3114

   SecurityCategory #1:
     type:  id-tsp-4
     value:  HUMAN RESOURCES USE ONLY

SecurityCategory#1: 以下をタイプしてください。 イドティースプーンフル4値: 人的資源使用だけ

2.2.4 Additional ESSSecurityLabel Processing Guidance

2.2.4 追加ESSSecurityLabel処理指導

   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.

アプローチはSecurity Policy情報File(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.

aを送るとき受取人の証明書を入手するのが署名されて唯一であったなら、別の導入問題はそうすることができます。機密保護ラベルがあるメッセージ。 暗号化メッセージを送るときだけ、通常受取人の証明書が必要です。 アプリケーションが、受取人の証明書を検索できる必要があるので、受取人のクリアランス情報はアクセス制御チェックに利用可能です。

3. Security Considerations

3. セキュリティ問題

   All security considerations from RFC 2630 [CMS] and RFC 2634 [ESS]
   apply to applications that use procedures described in this document.

RFC2630[CMS]とRFC2634[ESS]からのすべてのセキュリティ問題が本書では説明された手順を用いるアプリケーションに適用されます。

Nicolls                      Informational                     [Page 11]

RFC 3114       Implementing Company Classification Policy       May 2002

会社分類方針5月が2002であると実装するニコルズ情報[11ページ]のRFC3114

References

参照

   [AC509]      Farrell, S. and R. Housley, "An Internet Attribute
                Certificate Profile for Authorization", RFC 3281, April
                2002.

[AC509]ファレルとS.とR.Housley、「承認のためのインターネット属性証明書プロフィール」、RFC3281、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.と一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280、2002年4月。

   [CMS]        Housley, R., "Cryptographic Message Syntax", RFC 2630,
                June 1999.

[cm] Housley、R.、「暗号のメッセージ構文」、RFC2630、1999年6月。

   [ESS]        Hoffman, P., Editor, "Enhanced Security Services for
                S/MIME", RFC 2634, June 1999.

[ESS]ホフマン、P.、エディタ、「S/MIMEのための警備の強化サービス」、RFC2634、1999年6月。

   [MUSTSHOULD] Bradner, S., "Key Words for Use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

[MUSTSHOULD] ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、BCP14、RFC2119、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(1997E):」 情報技術--オープン・システム・インターコネクション--ディレクトリ: 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.

私がこのドキュメントを開発する過程を終えるのを助けるためのラスHousley、彼の技術支援と指導のためのジョンPawling、および彼の安全保障政策専門的技術のためのダンQuealyに感謝申し上げます。 私がそこで雇われていた間、このドキュメントの開発をサポートして頂いて、アーンスト&ヤングLLPとTelenisusに感謝申し上げます。 また、私にこのドキュメントを可能にする本当の例として彼らの方針を使用させたアモコ(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.

イモムシとWhirlpoolは彼らが自分達の安全保障政策に関して接触を供給したがっているかどうかそれぞれ尋ねられましたが、申し出をお断りしました。

Nicolls                      Informational                     [Page 12]

RFC 3114       Implementing Company Classification Policy       May 2002

分類方針2002年5月に会社を実行するニコルズ情報[12ページ]のRFC3114

Author's Address

作者のアドレス

   Weston Nicolls
   Forsythe Solutions
   7500 Frontage Rd
   Skokie, IL 60077

第スコーキ、ウェストンニコルズフォーサイスSolutions7500正面イリノイ 60077

   Phone: (847) 763-2370
   EMail: wnicolls@forsythesolutions.com

以下に電話をしてください。 (847) 763-2370 メールしてください: wnicolls@forsythesolutions.com

Nicolls                      Informational                     [Page 13]

RFC 3114       Implementing Company Classification Policy       May 2002

分類方針2002年5月に会社を実行するニコルズ情報[13ページ]のRFC3114

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Copyright(C)インターネット協会(2002)。 All rights reserved。

   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.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   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機能のための基金は現在、インターネット協会によって提供されます。

Nicolls                      Informational                     [Page 14]

ニコルズInformationalです。[14ページ]