RFC3647 日本語訳
3647 Internet X.509 Public Key Infrastructure Certificate Policy andCertification Practices Framework. S. Chokhani, W. Ford, R. Sabett,C. Merrill, S. Wu. November 2003. (Format: TXT=228124 bytes) (Obsoletes RFC2527) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Chokhani
Request for Comments: 3647 Orion Security Solutions, Inc.
Obsoletes: 2527 W. Ford
Category: Informational VeriSign, Inc.
R. Sabett
Cooley Godward LLP
C. Merrill
McCarter & English, LLP
S. Wu
Infoliance, Inc.
November 2003
Chokhaniがコメントのために要求するワーキンググループS.をネットワークでつないでください: Inc.が時代遅れにする3647のオリオンセキュリティソリューション: 2527年のW.フォードカテゴリ: 情報のベリサインのInc.R.SabettクーリーGodward LLP C.メリルMcCarterと英語、LLP S.ウーInfoliance Inc.2003年11月
Internet X.509 Public Key Infrastructure
Certificate Policy and Certification Practices Framework
インターネットX.509公開鍵暗号基盤証明書方針と証明習慣枠組み
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 (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
Abstract
要約
This document presents a framework to assist the writers of certificate policies or certification practice statements for participants within public key infrastructures, such as certification authorities, policy authorities, and communities of interest that wish to rely on certificates. In particular, the framework provides a comprehensive list of topics that potentially (at the writer's discretion) need to be covered in a certificate policy or a certification practice statement. This document supersedes RFC 2527.
このドキュメントは関係者のために公開鍵認証基盤の中で証明書方針か認証実施規定の作家を補助するために枠組みを提示します、証明書を当てにしたがっている証明当局や、方針当局や、興味がある共同体などのように。 特に、枠組みは潜在的に証明書方針か認証実施規定で覆われている必要がある(作家の裁量で)話題に関する総覧を提供します。 このドキュメントはRFC2527に取って代わります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Purpose. . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Scope. . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Certificate Policy . . . . . . . . . . . . . . . . . . . 9
3.2. Certificate Policy Examples. . . . . . . . . . . . . . . 11
3.3. X.509 Certificate Fields . . . . . . . . . . . . . . . . 12
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1。 バックグラウンド. . . . . . . . . . . . . . . . . . . . . . . 4 1.2。 目的。 . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. 範囲。 . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. 定義。 . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. 概念. . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1。 方針. . . . . . . . . . . . . . . . . . . 9 3.2を証明してください。 方針の例を証明してください。 . . . . . . . . . . . . . . 11 3.3. X.509証明書分野. . . . . . . . . . . . . . . . 12
Chokhani, et al. Informational [Page 1] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [1ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
3.3.1. Certificate Policies Extension . . . . . . . . . 12
3.3.2. Policy Mappings Extension. . . . . . . . . . . . 13
3.3.3. Policy Constraints Extension . . . . . . . . . . 13
3.3.4. Policy Qualifiers. . . . . . . . . . . . . . . . 14
3.4. Certification Practice Statement . . . . . . . . . . . . 15
3.5. Relationship Between CP and CPS. . . . . . . . . . . . . 16
3.6. Relationship Among CPs, CPSs, Agreements, and
Other Documents. . . . . . . . . . . . . . . . . . . . . 17
3.7. Set of Provisions. . . . . . . . . . . . . . . . . . . . 20
4. Contents of a Set of Provisions. . . . . . . . . . . . . . . . 21
4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 22
4.1.1. Overview . . . . . . . . . . . . . . . . . . . . 22
4.1.2. Document Name and Identification . . . . . . . . 22
4.1.3. PKI Participants . . . . . . . . . . . . . . . . 23
4.1.4. Certificate Usage. . . . . . . . . . . . . . . . 24
4.1.5. Policy Administration. . . . . . . . . . . . . . 24
4.1.6. Definitions and Acronyms . . . . . . . . . . . . 24
4.2. Publication and Repository Responsibilities. . . . . . . 25
4.3. Identification and Authentication (I&A). . . . . . . . . 25
4.3.1. Naming . . . . . . . . . . . . . . . . . . . . . 25
4.3.2. Initial Identity Validation. . . . . . . . . . . 26
4.3.3. I&A for Re-key Requests. . . . . . . . . . . . . 27
4.3.4. I&A for Revocation Requests. . . . . . . . . . . 27
4.4. Certificate Life-Cycle Operational Requirements. . . . . 27
4.4.1. Certificate Application. . . . . . . . . . . . . 28
4.4.2. Certificate Application Processing . . . . . . . 28
4.4.3. Certificate Issuance . . . . . . . . . . . . . . 28
4.4.4. Certificate Acceptance . . . . . . . . . . . . . 29
4.4.5. Key Pair and Certificate Usage . . . . . . . . . 29
4.4.6. Certificate Renewal. . . . . . . . . . . . . . . 30
4.4.7. Certificate Re-key . . . . . . . . . . . . . . . 30
4.4.8. Certificate Modification . . . . . . . . . . . . 31
4.4.9. Certificate Revocation and Suspension. . . . . . 31
4.4.10. Certificate Status Services. . . . . . . . . . . 33
4.4.11. End of Subscription. . . . . . . . . . . . . . . 33
4.4.12. Key Escrow and Recovery. . . . . . . . . . . . . 33
4.5. Facility, Management, and Operational Controls . . . . . 33
4.5.1. Physical Security Controls . . . . . . . . . . . 34
4.5.2. Procedural Controls. . . . . . . . . . . . . . . 35
4.5.3. Personnel Controls . . . . . . . . . . . . . . . 35
4.5.4. Audit Logging Procedures . . . . . . . . . . . . 36
4.5.5. Records Archival . . . . . . . . . . . . . . . . 37
4.5.6. Key Changeover . . . . . . . . . . . . . . . . . 38
4.5.7. Compromise and Disaster Recovery . . . . . . . . 38
4.5.8. CA or RA Termination . . . . . . . . . . . . . . 38
4.6. Technical Security Controls. . . . . . . . . . . . . . . 39
4.6.1. Key Pair Generation and Installation . . . . . . 39
4.6.2. Private Key Protection and Cryptographic
3.3.1. 方針拡大. . . . . . . . . 12 3.3.2を証明してください。 方針マッピング拡張子。 . . . . . . . . . . . 13 3.3.3. 方針規制拡大. . . . . . . . . . 13 3.3.4。 方針資格を与える人。 . . . . . . . . . . . . . . . 14 3.4. 認証実施規定. . . . . . . . . . . . 15 3.5。 CPとCPSとの関係… 16 3.6。 CPs、CPSs、協定、および他のドキュメントの中の関係。 . . . . . . . . . . . . . . . . . . . . 17 3.7. 条項のセット。 . . . . . . . . . . . . . . . . . . . 20 4. 1セットの条項のコンテンツ。 . . . . . . . . . . . . . . . 21 4.1. 序論. . . . . . . . . . . . . . . . . . . . . . 22 4.1.1。 概観. . . . . . . . . . . . . . . . . . . . 22 4.1.2。 名前と識別. . . . . . . . 22 4.1.3を記録してください。 PKI関係者. . . . . . . . . . . . . . . . 23 4.1.4。 用法を証明してください。 . . . . . . . . . . . . . . . 24 4.1.5. 方針政権。 . . . . . . . . . . . . . 24 4.1.6. 定義と頭文字語. . . . . . . . . . . . 24 4.2。 公表と倉庫責任。 . . . . . . 25 4.3. 識別と認証、(私とa)。 . . . . . . . . 25 4.3.1. 命名. . . . . . . . . . . . . . . . . . . . . 25 4.3.2。 アイデンティティ合法化に頭文字をつけてください。 . . . . . . . . . . 26 4.3.3. 再主要な要求のための私とA。 . . . . . . . . . . . . 27 4.3.4. 取消し要求のための私とA。 . . . . . . . . . . 27 4.4. ライフサイクルの操作上の要件を証明してください。 . . . . 27 4.4.1. アプリケーションを証明してください。 . . . . . . . . . . . . 28 4.4.2. 手続きの経緯. . . . . . . 28 4.4.3を証明してください。 発行. . . . . . . . . . . . . . 28 4.4.4を証明してください。 承認. . . . . . . . . . . . . 29 4.4.5を証明してください。 主要な組と証明書用法. . . . . . . . . 29 4.4.6。 更新を証明してください。 . . . . . . . . . . . . . . 30 4.4.7. 証明書再主要な. . . . . . . . . . . . . . . 30 4.4.8。 変更. . . . . . . . . . . . 31 4.4.9を証明してください。 取消しとサスペンションを証明してください。 . . . . . 31 4.4.10. 状態サービスを証明してください。 . . . . . . . . . . 33 4.4.11. 購読の終わり。 . . . . . . . . . . . . . . 33 4.4.12. キーエスクローと回復。 . . . . . . . . . . . . 33 4.5. 施設、管理、および運用統制. . . . . 33 4.5.1。 物理的な機密管理. . . . . . . . . . . 34 4.5.2。 手続き上のコントロール。 . . . . . . . . . . . . . . 35 4.5.3. 人員コントロール. . . . . . . . . . . . . . . 35 4.5.4。 伐採手順. . . . . . . . . . . . 36 4.5.5を監査してください。 記録記録保管所の. . . . . . . . . . . . . . . . 37 4.5.6。 主要な転換. . . . . . . . . . . . . . . . . 38 4.5.7。 妥協と災害復旧. . . . . . . . 38 4.5.8。 カリフォルニアかRA終了. . . . . . . . . . . . . . 38 4.6。 技術的なセキュリティは制御されます。 . . . . . . . . . . . . . . 39 4.6.1. 主要な組世代とインストール. . . . . . 39 4.6.2。 秘密鍵保護で暗号です。
Chokhani, et al. Informational [Page 2] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [2ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
Module Engineering Controls. . . . . . . . . . . 40
4.6.3. Other Aspects of Key Pair Management . . . . . . 42
4.6.4. Activation Data. . . . . . . . . . . . . . . . . 42
4.6.5. Computer Security Controls . . . . . . . . . . . 42
4.6.6. Life Cycle Security Controls . . . . . . . . . . 43
4.6.7. Network Security Controls. . . . . . . . . . . . 43
4.6.8. Timestamping . . . . . . . . . . . . . . . . . . 43
4.7. Certificate, CRL, and OCSP Profiles. . . . . . . . . . . 44
4.7.1. Certificate Profile. . . . . . . . . . . . . . . 44
4.7.2. CRL Profile. . . . . . . . . . . . . . . . . . . 44
4.7.3. OCSP Profile . . . . . . . . . . . . . . . . . . 44
4.8. Compliance Audit and Other Assessment. . . . . . . . . . 45
4.9. Other Business and Legal Matters . . . . . . . . . . . . 45
4.9.1. Fees . . . . . . . . . . . . . . . . . . . . . . 46
4.9.2. Financial Responsibility . . . . . . . . . . . . 47
4.9.3. Confidentiality of Business Information. . . . . 47
4.9.4. Privacy of Personal Information. . . . . . . . . 48
4.9.5. Intellectual Property Rights . . . . . . . . . . 48
4.9.6. Representations and Warranties . . . . . . . . . 48
4.9.7. Disclaimers of Warranties. . . . . . . . . . . . 49
4.9.8. Limitations of Liability . . . . . . . . . . . . 49
4.9.9. Indemnities. . . . . . . . . . . . . . . . . . . 49
4.9.10. Term and Termination . . . . . . . . . . . . . . 50
4.9.11. Individual notices and communications
with participants. . . . . . . . . . . . . . . . 50
4.9.12. Amendments . . . . . . . . . . . . . . . . . . . 50
4.9.13. Dispute Resolution Procedures. . . . . . . . . . 51
4.9.14. Governing Law. . . . . . . . . . . . . . . . . . 51
4.9.15. Compliance with Applicable Law . . . . . . . . . 51
4.9.16. Miscellaneous Provisions . . . . . . . . . . . . 51
4.9.17. Other Provisions . . . . . . . . . . . . . . . . 53
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 53
6. Outline of a Set of Provisions . . . . . . . . . . . . . . . . 53
7. Comparison to RFC 2527 . . . . . . . . . . . . . . . . . . . . 60
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 88
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 88
10. Notes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
12. List of Acronyms . . . . . . . . . . . . . . . . . . . . . . . 91
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 92
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 94
モジュール工学は制御されます。 . . . . . . . . . . 40 4.6.3. キーの他の局面は管理. . . . . . 42 4.6.4を対にします。 起動データ。 . . . . . . . . . . . . . . . . 42 4.6.5. コンピュータセキュリティコントロール. . . . . . . . . . . 42 4.6.6。 ライフサイクル機密管理. . . . . . . . . . 43 4.6.7。 ネットワークセキュリティは制御されます。 . . . . . . . . . . . 43 4.6.8. Timestamping. . . . . . . . . . . . . . . . . . 43 4.7。 証明書、CRL、およびOCSPプロフィール。 . . . . . . . . . . 44 4.7.1. プロフィールを証明してください。 . . . . . . . . . . . . . . 44 4.7.2. CRLプロフィール。 . . . . . . . . . . . . . . . . . . 44 4.7.3. OCSPは.444.8の輪郭を描きます。 承諾監査と他の査定。 . . . . . . . . . 45 4.9. 他のビジネスと法的な件. . . . . . . . . . . . 45 4.9の.1。 料金. . . . . . . . . . . . . . . . . . . . . . 46 4.9.2。 金融責任. . . . . . . . . . . . 47 4.9.3。 企業情報の秘密性。 . . . . 47 4.9.4. 個人情報の秘密。 . . . . . . . . 48 4.9.5. 知的所有権. . . . . . . . . . 48 4.9.6。 表明保証条項. . . . . . . . . 48 4.9.7。 保証に関する注意書き。 . . . . . . . . . . . 49 4.9.8. 責任. . . . . . . . . . . . 49 4.9.9の制限。 保障。 . . . . . . . . . . . . . . . . . . 49 4.9.10. 用語と終了. . . . . . . . . . . . . . 50 4.9.11。 関係者との個々の通知とコミュニケーション。 . . . . . . . . . . . . . . . 50 4.9.12. 米国憲法の修正条項. . . . . . . . . . . . . . . . . . . 50 4.9.13。 解決手順について議論してください。 . . . . . . . . . 51 4.9.14. 法を支配します。 . . . . . . . . . . . . . . . . . 51 4.9.15. 準拠法. . . . . . . . . 51 4.9.16への承諾。 種々雑多な条項. . . . . . . . . . . . 51 4.9.17。 他の条項. . . . . . . . . . . . . . . . 53 5。 セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 53 6. 1セットの条項. . . . . . . . . . . . . . . . 53 7のアウトライン。 RFC2527.608との比較。 承認. . . . . . . . . . . . . . . . . . . . . . . 88 9。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 88 10。 注意。 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 12. 頭文字語. . . . . . . . . . . . . . . . . . . . . . . 91 13のリスト。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 92 14。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 94
Chokhani, et al. Informational [Page 3] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [3ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
1. Introduction
1. 序論
1.1. Background
1.1. バックグラウンド
In general, a public-key certificate (hereinafter "certificate") binds a public key held by an entity (such as person, organization, account, device, or site) to a set of information that identifies the entity associated with use of the corresponding private key. In most cases involving identity certificates, this entity is known as the "subject" or "subscriber" of the certificate. Two exceptions, however, include devices (in which the subscriber is usually the individual or organization controlling the device) and anonymous certificates (in which the identity of the individual or organization is not available from the certificate itself). Other types of certificates bind public keys to attributes of an entity other than the entity's identity, such as a role, a title, or creditworthiness information.
一般に、公開カギが証明する、(以下に、「証明書」) 実体(人、組織、アカウント、装置、またはサイトなどの)で公開鍵が実体を特定する1セットの情報に保ったひもは対応する秘密鍵の使用と交際しました。 多くの場合、アイデンティティ証明書にかかわって、この実体は「対象」か「加入者」として証明書を知られています。 しかしながら、2つの例外が装置(通常、加入者は、そこでの装置を制御する個人か組織である)と匿名の証明書(個人か組織のアイデンティティはそこで証明書自体から利用可能でない)を含んでいます。 他のタイプの証明書は実体のアイデンティティ以外の実体の属性に公開鍵を縛ります、役割、タイトル、または取引信用度情報などのように。
A certificate is used by a "certificate user" or "relying party" that needs to use, and rely upon the accuracy of, the binding between the subject public key distributed via that certificate and the identity and/or other attributes of the subject contained in that certificate. A relying party is frequently an entity that verifies a digital signature from the certificate's subject where the digital signature is associated with an email, web form, electronic document, or other data. Other examples of relying parties can include a sender of encrypted email to the subscriber, a user of a web browser relying on a server certificate during a secure sockets layer (SSL) session, and an entity operating a server that controls access to online information using client certificates as an access control mechanism. In summary, a relying party is an entity that uses a public key in a certificate (for signature verification and/or encryption). The degree to which a relying party can trust the binding embodied in a certificate depends on several factors. These factors can include the practices followed by the certification authority (CA) in authenticating the subject; the CA's operating policy, procedures, and security controls; the scope of the subscriber's responsibilities (for example, in protecting the private key); and the stated responsibilities and liability terms and conditions of the CA (for example, warranties, disclaimers of warranties, and limitations of liability).
証明書は精度を使用して、当てにされる必要性、その証明書で分配された対象の公開鍵とアイデンティティの間の結合、そして/または、対象の他の属性がその証明書に含んだ「証明書ユーザ」か「信用パーティー」によって使用されます。 信用パーティーは、頻繁のデジタル署名がメールに関連している証明書の対象からデジタル署名について確かめる実体、ウェブフォーム、電子化文書、または他のデータです。 信用パーティーに関する他の例は加入者、安全なソケット層(SSL)のセッションの間にサーバ証明書を当てにするウェブブラウザのユーザ、およびアクセス管理機構としてクライアント証明書を使用することでオンライン情報へのアクセスを制御するサーバを操作する実体にコード化されたメールの送付者を含むことができます。 概要、信用党には、証明書(署名照合、そして/または、暗号化のための)で公開鍵を使用する実体があります。 信用パーティーが証明書に表現された結合を信じることができる程度はいくつかの要素に依存します。 これらの要素は習慣を含むことができて、対象を認証する際に続いて、証明権威(カリフォルニア)を含んでいます。 CAの運営方針、手順、および機密管理。 加入者の責任(例えば秘密鍵を保護する際に)の範囲。 そして、カリフォルニア(例えば、保証、保証、および責任の制限に関する注意書き)に関する述べられた責任と責任条件。
A Version 3 X.509 certificate may contain a field declaring that one or more specific certificate policies apply to that certificate [ISO1]. According to X.509, a certificate policy (CP) is "a named set of rules that indicates the applicability of a certificate to a particular community and/or class of applications with common security requirements." A CP may be used by a relying party to help
バージョン3X.509証明書は1つ以上の特定の証明書方針がその証明書[ISO1]に適用されると宣言する分野を含むかもしれません。 X.509によると、証明書方針(CP)は「共通の安全保障要件で特定の共同体、そして/または、クラスのアプリケーションへの証明書の適用性を示す命名されたセットの規則」です。 CPは、助けるのに信用パーティーによって使用されるかもしれません。
Chokhani, et al. Informational [Page 4] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [4ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
in deciding whether a certificate, and the binding therein, are sufficiently trustworthy and otherwise appropriate for a particular application. The CP concept is an outgrowth of the policy statement concept developed for Internet Privacy Enhanced Mail [PEM1] and expanded upon in [BAU1]. The legal and liability aspects presented in Section 4.9 are outcomes of a collaborative effort between IETF PKIX working group and the American Bar Association (ABA) members who have worked on legal acceptance of digital signature and role of PKI in that acceptance.
特定用途に、証明書、およびそこに結合が十分信頼できてそうでなければ、適切であるかどうか決める際に。 CP概念はインターネットPrivacy Enhancedメール[PEM1]のために開発されて、[BAU1]で広げられた施政方針概念の派生物です。 セクション4.9に提示された法的、そして、責任局面はIETF PKIXワーキンググループとその承認にデジタル署名の法的な承認とPKIの役割に取り組んだアメリカ法曹協会(ABA)のメンバーの間の共同努力の結果です。
A more detailed description of the practices followed by a CA in issuing and otherwise managing certificates may be contained in a certification practice statement (CPS) published by or referenced by the CA. According to the American Bar Association Information Security Committee's Digital Signature Guidelines (hereinafter "DSG")(1) and the Information Security Committee's PKI Assessment Guidelines (hereinafter "PAG")(2), "a CPS is a statement of the practices which a certification authority employs in issuing certificates." [ABA1, ABA2] In general, CPSs also describe practices relating to all certificate lifecycle services (e.g., issuance, management, revocation, and renewal or re-keying), and CPSs provide details concerning other business, legal, and technical matters. The terms contained in a CP or CPS may or may not be binding upon a PKI's participants as a contract. A CP or CPS may itself purport to be a contract. More commonly, however, an agreement may incorporate a CP or CPS by reference and therefore attempt to bind the parties of the agreement to some or all of its terms. For example, some PKIs may utilize a CP or (more commonly) a CPS that is incorporated by reference in the agreement between a subscriber and a CA or RA (called a "subscriber agreement") or the agreement between a relying party and a CA (called a "relying party agreement" or "RPA"). In other cases, however, a CP or CPS has no contractual significance at all. A PKI may intend these CPs and CPSs to be strictly informational or disclosure documents.
発行して、そうでなければ、証明書を管理する際にカリフォルニアによって続かれた習慣の、より詳細な記述は(CPS)が発行されたか、またはカリフォルニアで参照をつけた認証実施規定に含まれるかもしれません。 アメリカ法曹協会情報Security CommitteeのDigital Signature Guidelines、(以下に、"DSG") (1)と情報セキュリティ委員会のPKI査定ガイドライン、(以下に、「パグ島」) (2) 「CPSは証明書を発行する証明権威が中で使う習慣の声明です」。 [ABA1、ABA2]また、一般に、CPSsはすべての証明書lifecycleサービス(例えば、発行か、管理か、取消しと、更新か再の合わせる)に関連する習慣について説明して、CPSsは他のビジネス(法的で、技術的な件)に関して詳細を明らかにします。 CPかCPSに含まれた用語は契約としてPKIの関係者を拘束しているかもしれません。 CPかCPSがそうするかもしれない、それ自体、契約であることを意味してください。 より一般的に、しかしながら、協定は、参照でCPかCPSを組み込んで、したがって、用語のいくつかかすべてへの協定のパーティーを縛るのを試みるかもしれません。例えば、いくつかのPKIsがCPか加入者とカリフォルニアかRAとの協定(「加入者協定」と呼ばれる)か信用パーティーとカリフォルニアとの協定(「当てにしているパーティー協定かRPA」と呼ばれる)における参照で組み込まれる(より一般的に)CPSを利用するかもしれません。 しかしながら、他の場合では、CPかCPSが契約上の意味を全く持っていません。 PKIはこれらのCPsと厳密に情報であるCPSsか開示書類を意図するかもしれません。
1.2. Purpose
1.2. 目的
The purpose of this document is twofold. First, the document aims to explain the concepts of a CP and a CPS, describe the differences between these two concepts, and describe their relationship to subscriber and relying party agreements. Second, this document aims to present a framework to assist the writers and users of certificate policies or CPSs in drafting and understanding these documents. In particular, the framework identifies the elements that may need to be considered in formulating a CP or a CPS. The purpose is not to define particular certificate policies or CPSs, per se. Moreover, this document does not aim to provide legal advice or recommendations
このドキュメントの目的は二つです。 まず最初に、ドキュメントは、CPとCPSの概念について説明して、これらの2つの概念の違いについて説明して、加入者と信用パーティー協定とのそれらの関係について説明することを目指します。 2番目に、このドキュメントは、これらのドキュメントを作成して、理解しているのを証明書方針かCPSsの作家とユーザを補助するために枠組みを提示することを目指します。 特に、枠組みはCPかCPSを定式化する際に考えられる必要があるかもしれない要素を特定します。目的は特定の証明書方針かそういうもののCPSsを定義しないことです。 そのうえ、このドキュメントは、弁護士の意見か推薦を提供することを目指しません。
Chokhani, et al. Informational [Page 5] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [5ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
as to particular requirements or practices that should be contained within CPs or CPSs. (Such recommendations, however, appear in [ABA2].)
特定の要件か習慣に関して、それはCPsかCPSsの中に含まれるべきです。 (しかしながら、そのような推薦は[ABA2]に現れます。)
1.3. Scope
1.3. 範囲
The scope of this document is limited to discussion of the topics that can be covered in a CP (as defined in X.509) or CPS (as defined in the DSG and PAG). In particular, this document describes the types of information that should be considered for inclusion in a CP or a CPS. While the framework as presented generally assumes use of the X.509 version 3 certificate format for the purpose of providing assurances of identity, it is not intended that the material be restricted to use of that certificate format or identity certificates. Rather, it is intended that this framework be adaptable to other certificate formats and to certificates providing assurances other than identity that may come into use.
このドキュメントの範囲はCP(X.509で定義されるように)かCPSでカバーできる話題の議論に制限されます(DSGとPAGで定義されるように)。 特に、このドキュメントはCPかCPSでの包含のために考えられるべきである情報のタイプについて説明します。一般に、提示される枠組みがX.509バージョン3証明書形式のアイデンティティの保証を提供する目的の使用を仮定している間、材料がその証明書形式かアイデンティティ証明書の使用に制限されることを意図しません。 むしろ、使用に入るかもしれないアイデンティティを除いて、この枠組みが他の証明書形式と、そして、保証を提供する証明書に適合できることを意図します。
The scope does not extend to defining security policies generally (such as organization security policy, system security policy, or data labeling policy). Further, this document does not define a specific CP or CPS. Moreover, in presenting a framework, this document should be viewed and used as a flexible tool presenting topics that should be considered of particular relevance to CPs or CPSs, and not as a rigid formula for producing CPs or CPSs.
範囲は一般に、安全保障政策を定義するのに(組織安全保障政策、システム安全保障政策、または方針をラベルするデータなどの)広がっていません。 さらに、このドキュメントは特定のCPかCPSを定義しません。そのうえ、枠組みを提示する際に、話題にそれを提示するフレキシブルなツールが特定の関連性についてCPsかCPSsを生産するための堅い公式ではなく、CPsかCPSsと考えられるべきであるとき、このドキュメントは、見られて、使用されるべきです。
This document assumes that the reader is familiar with the general concepts of digital signatures, certificates, and public-key infrastructure (PKI), as used in X.509, the DSG, and the PAG.
このドキュメントは、読者がデジタル署名、証明書、および公開カギインフラストラクチャ(PKI)に関する一般概念に詳しいと仮定します、X.509、DSG、およびPAGで使用されるように。
2. Definitions
2. 定義
This document makes use of the following defined terms:
このドキュメントは次の定義された用語を利用します:
Activation data - Data values, other than keys, that are required to operate cryptographic modules and that need to be protected (e.g., a PIN, a passphrase, or a manually-held key share).
起動データ--キー以外の暗号のモジュールを操作するのが必要であり、保護される必要があるデータ値(例えば、暗証番号、パスフレーズ、または手動で保持されたキーが共有されます)。
Authentication - The process of establishing that individuals, organizations, or things are who or what they claim to be. In the context of a PKI, authentication can be the process of establishing that an individual or organization applying for or seeking access to something under a certain name is, in fact, the proper individual or organization. This corresponds to the second process involved with identification, as shown in the definition of "identification" below. Authentication can also refer to a security service that provides assurances that individuals, organizations, or things are who or what
認証--個人、組織、またはものがそれらが主張するだれか者であることを確証する過程。 PKIの文脈では、認証は事実上、ある名前の下で何かへのアクセスを申し込むか、または求める個人か組織が適切な個人か組織であることを確証する過程であるかもしれません。 これは以下の「識別」の定義で示されるように識別にかかわる2番目の過程に対応しています。 また、認証が個人、組織、またはものが保証ですが、提供されるセキュリティー・サービスについて言及できる、だれか何
Chokhani, et al. Informational [Page 6] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [6ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
they claim to be or that a message or other data originated from a specific individual, organization, or device. Thus, it is said that a digital signature of a message authenticates the message's sender.
彼らが、主張するか、またはそのメッセージの、または、他のデータは特定の個人、組織、または装置から発しました。 したがって、メッセージのデジタル署名がメッセージの送付者を認証すると言われています。
CA-certificate - A certificate for one CA's public key issued by another CA.
カリフォルニア-証明書--CAの公開鍵が別のカリフォルニアで発行した1つのための証明書。
Certificate policy (CP) - A named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements. For example, a particular CP might indicate applicability of a type of certificate to the authentication of parties engaging in business-to-business transactions for the trading of goods or services within a given price range.
方針(CP)を証明してください--共通の安全保障要件で特定の共同体、そして/または、クラスの適用への証明書の適用性を示す命名されたセットの規則。 例えば、特定のCPは与えられた値幅の中で商品かサービスの取り引きのための企業間取引に従事しているパーティーの認証に一種の証明書の適用性を示すかもしれません。
Certification path - An ordered sequence of certificates that, together with the public key of the initial object in the path, can be processed to obtain that of the final object in the path.
証明経路--経路で最終的な物のものを得るために経路の初期の物の公開鍵と共に処理できる証明書の規則正しい系列。
Certification Practice Statement (CPS) - A statement of the practices that a certification authority employs in issuing, managing, revoking, and renewing or re-keying certificates.
証明Practice Statement(CPS)--証明権威が証明書を発行するか、管理するか、取り消して、更新するか、または再合わせる際に使う習慣の声明。
CPS Summary (or CPS Abstract) - A subset of the provisions of a complete CPS that is made public by a CA.
CPS Summary(または、CPS要約)--カリフォルニアによって公表される完全なCPSに関する条項の部分集合。
Identification - The process of establishing the identity of an individual or organization, i.e., to show that an individual or organization is a specific individual or organization. In the context of a PKI, identification refers to two processes:
識別--個人か組織のアイデンティティを確立する過程、すなわち、それを示しているために、個人か組織が、特定の個人か組織です。 PKIの文脈では、識別は2つの過程を示します:
(1) establishing that a given name of an individual or organization
corresponds to a real-world identity of an individual or
organization, and
そして(1) 個人か組織の名が個人か組織の本当の世界のアイデンティティに対応するのを確証する。
(2) establishing that an individual or organization applying for or
seeking access to something under that name is, in fact, the
named individual or organization. A person seeking
identification may be a certificate applicant, an applicant for
employment in a trusted position within a PKI participant, or a
person seeking access to a network or software application, such
as a CA administrator seeking access to CA systems.
(2) 事実上、その名前の下で何かへのアクセスを申し込むか、または求める個人か組織が命名された個人か組織であることを確証すること。 識別を求めている人は、証明書応募者、PKI関係者の中の信じられた位置の求職者、またはネットワークかソフトウェアアプリケーションへのアクセスを求めている人であるかもしれません、カリフォルニアシステムへのアクセスを求めているカリフォルニアの管理者のように。
Issuing certification authority (issuing CA) - In the context of a particular certificate, the issuing CA is the CA that issued the certificate (see also Subject certification authority).
特定の証明書の文脈で証明権威を発行して(カリフォルニアを発行します)、発行カリフォルニアは証明書を発行したカリフォルニア(また、Subject証明権威を見る)です。
Chokhani, et al. Informational [Page 7] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [7ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
Participant - An individual or organization that plays a role within a given PKI as a subscriber, relying party, CA, RA, certificate manufacturing authority, repository service provider, or similar entity.
関係者--加入者、当てにしているパーティー、カリフォルニア、RA、証明書製造権威、倉庫サービスプロバイダー、または同様の実体として与えられたPKIの中で役割を果たす個人か組織。
PKI Disclosure Statement (PDS) - An instrument that supplements a CP or CPS by disclosing critical information about the policies and practices of a CA/PKI. A PDS is a vehicle for disclosing and emphasizing information normally covered in detail by associated CP and/or CPS documents. Consequently, a PDS is not intended to replace a CP or CPS.
PKI Disclosure Statement(PDS)--カリフォルニア/PKIの方針と習慣に関する重要情報を明らかにすることによってCPかCPSを補う器具。 PDSは、関連CP、そして/または、CPSドキュメントで詳細に通常、カバーされた情報を明らかにして、強調するための乗り物です。 その結果、PDSがCPかCPSを取り替えることを意図しません。
Policy qualifier - Policy-dependent information that may accompany a CP identifier in an X.509 certificate. Such information can include a pointer to the URL of the applicable CPS or relying party agreement. It may also include text (or number causing the appearance of text) that contains terms of the use of the certificate or other legal information.
方針資格を与える人--X.509証明書のCP識別子に伴うかもしれない方針依存する情報。 そのような情報は適切なCPSか信用パーティー協定のURLにポインタを含むことができます。 また、それは証明書の使用に関する諸条件を含むテキスト(または、テキストの外観を引き起こす数)か他の法的な情報を含むかもしれません。
Registration authority (RA) - An entity that is responsible for one or more of the following functions: the identification and authentication of certificate applicants, the approval or rejection of certificate applications, initiating certificate revocations or suspensions under certain circumstances, processing subscriber requests to revoke or suspend their certificates, and approving or rejecting requests by subscribers to renew or re-key their certificates. RAs, however, do not sign or issue certificates (i.e., an RA is delegated certain tasks on behalf of a CA). [Note: The term Local Registration Authority (LRA) is sometimes used in other documents for the same concept.]
登録局(RA)--以下の1つ以上に原因となる実体は機能します: 証明書アプリケーションの証明書応募者の識別と認証、承認または拒絶、ある事情か、それらの証明書を取り消すか、または吊すという処理加入者要求と、承認か拒絶での証明書取消しかサスペンションを開始すると、取り替える加入者か再キーで、彼らの証明書は要求されます。 しかしながら、RAsは証明書をサインもしませんし、発行もしません(すなわち、RAはカリフォルニアを代表した代表として派遣されたあるタスクです)。 [注意: 用語Local Registration Authority(LRA)は同じ概念に他のドキュメントで時々使用されます。]
Relying party - A recipient of a certificate who acts in reliance on that certificate and/or any digital signatures verified using that certificate. In this document, the terms "certificate user" and "relying party" are used interchangeably.
信用パーティー--その証明書を使用することで確かめられたその証明書、そして/または、どんなデジタル化した署名への信用でも行動する証明書の受取人。 本書では、用語「証明書ユーザ」と「信用パーティー」は互換性を持って使用されます。
Relying party agreement (RPA) - An agreement between a certification authority and relying party that typically establishes the rights and responsibilities between those parties regarding the verification of digital signatures or other uses of certificates.
当てにしているパーティー協定(RPA)--証明権威と信用パーティーとのデジタル署名の検証か証明書の他の用途に関してそれらのパーティーの間の権利と責任を通常確立する協定。
Set of provisions - A collection of practice and/or policy statements, spanning a range of standard topics, for use in expressing a CP or CPS employing the approach described in this framework.
条項のセット--習慣、そして/または、施政方針の収集、CPを急送することにおける使用のためにさまざまな標準の話題にかかるか、またはこの枠組みで説明されたアプローチを使うCPS。
Chokhani, et al. Informational [Page 8] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [8ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
Subject certification authority (subject CA) - In the context of a particular CA-certificate, the subject CA is the CA whose public key is certified in the certificate (see also Issuing certification authority).
特定のカリフォルニア-証明書の文脈の対象の証明権威(対象のカリフォルニア)、対象のカリフォルニアは公開鍵が証明書で公認されるカリフォルニア(また、Issuing証明権威を見る)です。
Subscriber - A subject of a certificate who is issued a certificate.
加入者--そうする証明書の対象は証明書を下付しました。
Subscriber Agreement - An agreement between a CA and a subscriber that establishes the right and responsibilities of the parties regarding the issuance and management of certificates.
加入者Agreement--カリフォルニアと加入者との証明書の発行と管理に関してパーティーの権利と責任を確立する協定。
Validation - The process of identification of certificate applicants. "Validation" is a subset of "identification" and refers to identification in the context of establishing the identity of certificate applicants.
合法化--証明書応募者の識別の過程。 「合法化」は、「識別」の部分集合であり、証明書応募者のアイデンティティを確立することの文脈における識別を示します。
3. Concepts
3. 概念
This section explains the concepts of CP and CPS, and describes their relationship with other PKI documents, such as subscriber agreements and relying party agreements. Other related concepts are also described. Some of the material covered in this section and in some other sections is specific to certificate policies extensions as defined X.509 version 3. Except for those sections, this framework is intended to be adaptable to other certificate formats that may come into use.
このセクションは、CPとCPSの概念について説明して、他のPKIドキュメントとの彼らの関係について説明します、加入者協定と信用パーティー協定などのように。 また、他の関連する概念は説明されます。 このセクションとある他のセクションでカバーされた材料のいくつかが、定義されたX.509バージョン3として方針拡大を証明するために特定です。 それらのセクションを除いて、この枠組みが使用に入るかもしれない他の証明書形式に融通がきくことを意図します。
3.1. Certificate Policy
3.1. 証明書方針
When a certification authority issues a certificate, it is providing a statement to a certificate user (i.e., a relying party) that a particular public key is bound to the identity and/or other attributes of a particular entity (the certificate subject, which is usually also the subscriber). The extent to which the relying party should rely on that statement by the CA, however, needs to be assessed by the relying party or entity controlling or coordinating the way relying parties or relying party applications use certificates. Different certificates are issued following different practices and procedures, and may be suitable for different applications and/or purposes.
証明権威が証明書を下付するとき、それは特定の公開鍵がアイデンティティに縛られるという証明書ユーザ(すなわち、信用パーティー)への声明、そして/または、特定の実体(通常また、加入者である証明書対象)の他の属性を提供しています。 しかしながら、信用パーティーがカリフォルニアによるその声明を当てにするべきである範囲が、信用パーティーか実体制御で評価される必要があるか、または信用がパーティーへ行く方法か信用を調整して、パーティーアプリケーションは証明書を使用します。 異なった証明書は、異なった習慣と手順に従って、発行されて、異なったアプリケーション、そして/または、目的に適しているかもしれません。
The X.509 standard defines a CP as "a named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements" [ISO1]. An X.509 Version 3 certificate may identify a specific applicable CP, which may be used by a relying party to
X.509規格は「共通の安全保障要件で特定の共同体、そして/または、クラスの適用への証明書の適用性を示す命名されたセットの規則」[ISO1]とCPを定義します。 3証明書が信用パーティーによって使用されるかもしれない特定の適切なCPを特定するかもしれないX.509バージョン
Chokhani, et al. Informational [Page 9] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [9ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
decide whether or not to trust a certificate, associated public key, or any digital signatures verified using the public key for a particular purpose.
特定の目的に公開鍵を使用することで確かめられた証明書、関連公開鍵、または何かデジタル署名を信じるかどうか決めてください。
CPs typically fall into two major categories. First, some CPs "indicate the applicability of a certificate to a particular community" [ISO1]. These CPs set forth requirements for certificate usage and requirements on members of a community. For instance, a CP may focus on the needs of a geographical community, such as the ETSI policy requirements for CAs issuing qualified certificates [ETS]. Also, a CP of this kind may focus on the needs of a specific vertical-market community, such as financial services [IDT].
CPsは2つの大範疇に通常なります。 まず最初に、いくつかのCPsが「証明書の適用性を特定の共同体に示す」[ISO1]。 これらのCPsは証明書用法のための要件と共同体のメンバーに関する要件について詳しく説明します。 例えば、CPは地理的な共同体の必要性に焦点を合わせるかもしれません、限定事項付き証明[ETS]を発行するCAsのためのETSI方針要件などのように。 また、この種類のCPは特定の垂直的市場共同体の必要性に焦点を合わせるかもしれません、金融サービス[IDT]などのように。
The second category of typical CPs "indicate the applicability of a certificate to a . . . class of application with common security requirements." These CPs identify a set of applications or uses for certificates and say that these applications or uses require a certain level of security. They then set forth PKI requirements that are appropriate for these applications or uses. A CP within this category often makes sets requirements appropriate for a certain "level of assurance" provided by certificates, relative to certificates issued pursuant to related CPs. These levels of assurance may correspond to "classes" or "types" of certificates.
典型的なCPsの2番目のカテゴリは「共通の安全保障要件でアプリケーションについて証明書の適用性を…のクラスに示します」。 これらのCPsは、1セットの証明書へのアプリケーションか用途を特定して、これらのアプリケーションか用途が、あるレベルのセキュリティを必要とすると言います。 そして、彼らはこれらのアプリケーションか用途に、適切なPKI要件について詳しく説明します。 このカテゴリの中のCPはしばしばセットを証明書によって提供されたある「保証のレベル」に、適切な要件にします、関連するCPsによると、発行された証明書に比例して。 これらのレベルを保証は証明書の「クラス」か「タイプ」に対応するかもしれません。
For instance, the Government of Canada PKI Policy Management Authority (GOC PMA) has established eight certificate policies in a single document [GOC], four policies for certificates used for digital signatures and four policies for certificates used for confidentiality encryption. For each of these applications, the document establishes four levels of assurances: rudimentary, basic, medium, and high. The GOC PMA described certain types of digital signature and confidentiality uses in the document, each with a certain set of security requirements, and grouped them into eight categories. The GOC PMA then established PKI requirements for each of these categories, thereby creating eight types of certificates, each providing rudimentary, basic, medium, or high levels of assurance. The progression from rudimentary to high levels corresponds to increasing security requirements and corresponding increasing levels of assurance.
例えば、カナダPKI Policy Management Authority(GOC PMA)政府はただ一つのドキュメント[GOC](秘密性暗号化に使用される証明書のためのデジタル署名と4つの方針に使用される証明書のための4つの方針)の8つの証明書方針を確立しました。 それぞれのこれらのアプリケーションのために、ドキュメントは4つのレベルを保証を確立します: 初歩的で、基本的で、中型で、高いです。 GOC PMAはドキュメントと、それぞれあるセットのセキュリティ要件で、あるタイプのデジタル署名と秘密性用途について説明して、それらを8つのカテゴリに分類しました。 次に、GOC PMAはそれぞれのこれらのカテゴリのためのPKI要件を確立しました、その結果、8つのタイプの証明書を作成します、それぞれ初歩的であるか、基本的であるか、中型の、または、高いレベルを保証を提供して。 初歩的なレベルから高いレベルまでの進行は増加するセキュリティ要件と対応する増加するレベルを保証に対応しています。
A CP is represented in a certificate by a unique number called an "Object Identifier" (OID). That OID, or at least an "arc", can be registered. An "arc" is the beginning of the numerical sequence of an OID and is assigned to a particular organization. The registration process follows the procedures specified in ISO/IEC and ITU standards. The party that registers the OID or arc also can publish the text of the CP, for examination by relying parties. Any one certificate will typically declare a single CP or, possibly, be
CPは証明書に「オブジェクト識別子」(OID)と呼ばれるユニークな数によって表されます。 そのOID、または少なくとも「アーク」を登録できます。 「アーク」は、OIDの数字の系列の始まりであり、特定の組織に配属されます。 登録手続はISO/IECとITU規格で指定された手順に従います。 OIDかアークを示すパーティーもCPのテキストを発行できます、当てにするのによる試験がパーティーへ行くので。 どんな証明書も、独身のCPを通常申告するか、またはことによるとあるでしょう。
Chokhani, et al. Informational [Page 10] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [10ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
issued consistent with a small number of different policies. Such declaration appears in the Certificate Policies extension of a X.509 Version 3 certificate. When a CA places multiple CPs within a certificate's Certificate Policies extension, the CA is asserting that the certificate is appropriate for use in accordance with any of the listed CPs.
少ない数の異なった方針と一致していた状態で、発行されます。 そのような宣言はX.509バージョン3証明書のCertificate Policies拡張子に現れます。 カリフォルニアが証明書のCertificate Policies拡張子の中に複数のCPsを置くとき、カリフォルニアは、使用に、記載されたCPsのどれかに従って証明書が適切であると断言しています。
CPs also constitute a basis for an audit, accreditation, or another assessment of a CA. Each CA can be assessed against one or more certificate policies or CPSs that it is recognized as implementing. When one CA issues a CA-certificate for another CA, the issuing CA must assess the set of certificate policies for which it trusts the subject CA (such assessment may be based upon an assessment with respect to the certificate policies involved). The assessed set of certificate policies is then indicated by the issuing CA in the CA- certificate. The X.509 certification path processing logic employs these CP indications in its well-defined trust model.
また、CPsはカリフォルニアの監査、認可、または別の査定の基礎を構成します。 それが実装しながら認められる1証明書方針かCPSsに対して各カリフォルニアを評価できます。 1カリフォルニアが別のカリフォルニアのためのカリフォルニア-証明書を発行するとき、発行カリフォルニアはそれが対象のカリフォルニアを信じる証明書方針のセットを評価しなければなりません(そのような査定は方針が伴った証明書に関して査定に基づくかもしれません)。 そして、評価されたセットの証明書方針はカリフォルニア証明書の発行カリフォルニアによって示されます。 明確な信頼におけるこれらのCP指摘がモデル化するX.509証明経路処理論理雇用。
3.2. Certificate Policy Examples
3.2. 証明書方針の例
For example purposes, suppose that the International Air Transport Association (IATA) undertakes to define some certificate policies for use throughout the airline industry, in a PKI operated by IATA in combination with PKIs operated by individual airlines. Two CPs might be defined - the IATA General-Purpose CP, and the IATA Commercial- Grade CP.
例えば、目的国際航空運送協会(IATA)が、航空産業中で使用のためのいくつかの証明書方針を定義するのを引き受けると思って、個々の航空会社によって操作されたPKIsと組み合わせてPKIでIATAによって操作されて。 2CPsが定義されるかもしれません--IATAの一般目的CP、およびIATA CommercialグレードCP。
The IATA General-Purpose CP could be used by industry personnel for protecting routine information (e.g., casual electronic mail) and for authenticating connections from World Wide Web browsers to servers for general information retrieval purposes. The key pairs may be generated, stored, and managed using low-cost, software-based systems, such as commercial browsers. Under this policy, a certificate may be automatically issued to anybody listed as an employee in the corporate directory of IATA or any member airline who submits a signed certificate request form to a network administrator in his or her organization.
産業の人員は、通常の情報(例えば、カジュアルな電子メール)を保護して、一般情報検索目的のためにウェブ・ブラウザーからサーバまでの接続を認証するのにIATA一般目的CPを使用できました。 主要な組は、市販のブラウザなどの安価の、そして、ソフトウェアベースのシステムを使用することで生成されて、保存されて、経営されるかもしれません。 この方針の下では、その人の組織でネットワーク管理者に署名入りの証書依頼状用紙を提出するIATAの法人のディレクトリかどんなメンバー航空会社でも自動的に従業員として記載された人はだれにも証明書を発行するかもしれません。
The IATA Commercial-Grade CP could be used to protect financial transactions or binding contractual exchanges between airlines. Under this policy, IATA could require that certified key pairs be generated and stored in approved cryptographic hardware tokens. Certificates and tokens could be provided to airline employees with disbursement authority. These authorized individuals might then be required to present themselves to the corporate security office, show a valid identification badge, and sign a subscriber agreement requiring them to protect the token and use it only for authorized purposes, as a condition of being issued a token and a certificate.
航空会社の間の金融取引か拘束力がある契約上の交換を保護するのにIATA Commercial-グレードCPを使用できました。 この方針の下では、IATAは、公認された主要な組が承認された暗号のハードウェアトークンで生成されて、保存されるのを必要とすることができました。 支出権威と共に証明書とトークンをエアライン従業員に提供できました。 これらの認可された個人は、企業の機密保持オフィスに出向いて、有効な認識票を見せていて、彼らがトークンを保護するのを必要とする加入者協定に調印して、次に、認可された目的にだけそれを使用しなければならないかもしれません、トークンと証明書を発行するという条件として。
Chokhani, et al. Informational [Page 11] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [11ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
3.3. X.509 Certificate Fields
3.3. X.509証明書分野
The following extension fields in an X.509 certificate are used to support CPs:
X.509証明書の以下の拡大分野はCPsをサポートするのに使用されます:
* Certificate Policies extension; * Policy Mappings extension; and * Policy Constraints extension.
* Policies拡張子を証明してください。 * 方針Mappings拡張子。 そして、*方針Constraints拡張子。
3.3.1. Certificate Policies Extension
3.3.1. 証明書方針拡張子
A Certificate Policies field lists CPs that the certification authority declares are applicable. Using the example of the IATA General-Purpose and Commercial-Grade policies defined in Section 3.2, the certificates issued to regular airline employees would contain the object identifier for General-Purpose policy. The certificates issued to the employees with disbursement authority would contain the object identifiers for both the General-Purpose policy and the Commercial-Grade policy. The inclusion of both object identifiers in the certificates means that they would be appropriate for either the General-Purpose or Commercial-Grade policies. The Certificate Policies field may also optionally convey qualifier values for each identified policy; the use of qualifiers is discussed in Section 3.4.
証明権威が申告するCertificate Policies分野リストCPsは適切です。 セクション3.2で定義されたIATAの一般目的とCommercial-グレード方針に関する例を使用して、レギュラーのエアライン従業員に発行された証明書は一般目的方針のためのオブジェクト識別子を含んでいるでしょう。 支出権威で従業員に発行された証明書は一般目的方針とCommercial-グレード方針の両方のためのオブジェクト識別子を含んでいるでしょう。 証明書での両方のオブジェクト識別子の包含は、一般目的かCommercial-グレード方針に、それらが適切であることを意味します。 また、Certificate Policies分野はそれぞれの特定された方針のために任意に資格を与える人値を伝えるかもしれません。 セクション3.4で資格を与える人の使用について議論します。
When processing a certification path, a CP that is acceptable to the relying party application must be present in every certificate in the path, i.e., in CA-certificates as well as end entity certificates.
証明経路を処理するとき、当てにしているパーティーアプリケーションに許容できるCPは経路のあらゆる証明書に存在していなければなりません、すなわち、終わりの実体証明書と同様にカリフォルニア-証明書で。
If the Certificate Policies field is flagged critical, it serves the same purpose as described above but also has an additional role. Specifically, it indicates that the use of the certificate is restricted to one of the identified policies, i.e., the certification authority is declaring that the certificate must only be used in accordance with the provisions of at least one of the listed CPs. This field is intended to protect the certification authority against claims for damages asserted by a relying party who has used the certificate for an inappropriate purpose or in an inappropriate manner, as stipulated in the applicable CP.
分野はCertificate Policiesであるなら旗を揚げられます。重要です、それには、上で説明されるのと同じ目的に役立ちますが、追加役割がまたあります。 明確に、証明書の使用が特定された方針の1つに制限されるのを示します、すなわち、証明権威は少なくとも記載されたCPsの1つに関する条項によると、証明書を使用するだけでよいと宣言しています。 この分野が不適当な目的に証明書を使用した当てにしているパーティーか不適当な方法で断言された損害賠償でクレームに対して証明権威を保護することを意図します、適切なCPで規定されているように。
For example, the Internal Revenue Service might issue certificates to taxpayers for the purpose of protecting tax filings. The Internal Revenue Service understands and can accommodate the risks of erroneously issuing a bad certificate, e.g., to an imposter. Suppose, however, that someone used an Internal Revenue Service tax- filing certificate as the basis for encrypting multi-million-dollar- value proprietary trade secrets, which subsequently fell into the wrong hands because of a cryptanalytic attack by an attacker who is able to decrypt the message. The Internal Revenue Service may want
例えば、国税庁は納税申告を保護する目的のために納税者に証明書を発行するかもしれません。 国税庁は、分かって、誤って例えば、詐欺師に悪い証明書を発行する危険を収容できます。 しかしながら、だれかが何100万ドルの値を暗号化する基礎として証明書をファイルする国税庁税の独占企業秘密を使用したと仮定してください。(企業秘密は次に、メッセージを解読することができる攻撃者によるcryptanalytic攻撃で間違った手になりました)。 国税庁は欲しいかもしれません。
Chokhani, et al. Informational [Page 12] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [12ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
to defend itself against claims for damages in such circumstances by pointing to the criticality of the Certificate Policies extension to show that the subscriber and relying party misused the certificate. The critical-flagged Certificate Policies extension is intended to mitigate the risk to the CA in such situations.
そのような事情における損害賠償で加入者と信用がパーティーへ行くのを示すためにCertificate Policies拡張子の臨界を示すことによってクレームに対して自らを守るのは証明書を誤用しました。 重要に旗を揚げさせられたCertificate Policies拡張子がそのような状況におけるカリフォルニアに危険を緩和することを意図します。
3.3.2. Policy Mappings Extension
3.3.2. 方針マッピング拡張子
The Policy Mappings extension may only be used in CA-certificates. This field allows a certification authority to indicate that certain policies in its own domain can be considered equivalent to certain other policies in the subject certification authority's domain.
Policy Mappings拡張子はカリフォルニア-証明書で使用されるだけであるかもしれません。 この分野は対象の証明権威のドメインの他のある方針に同等であるとそれ自身のドメインのある方針を考えることができるのを示す証明権威を許容します。
For example, suppose that for purposes of facilitating interoperability, the ACE Corporation establishes an agreement with the ABC Corporation to cross-certify the public keys of each others' certification authorities for the purposes of mutually securing their respective business-to-business exchanges. Further, suppose that both companies have pre-existing financial transaction protection policies called ace-e-commerce and abc-e-commerce, respectively. One can see that simply generating cross-certificates between the two domains will not provide the necessary interoperability, as the two companies' applications are configured with, and employee certificates are populated with, their respective certificate policies. One possible solution is to reconfigure all of the financial applications to require either policy and to reissue all the certificates with both policies appearing in their Certificate Policies extensions. Another solution, which may be easier to administer, uses the Policy Mapping field. If this field is included in a cross-certificate for the ABC Corporation certification authority issued by the ACE Corporation certification authority, it can provide a statement that the ABC's financial transaction protection policy (i.e., abc-e-commerce) can be considered equivalent to that of the ACE Corporation (i.e., ace-e-commerce). With such a statement included in the cross-certificate issued to ABC, relying party applications in the ACE domain requiring the presence of the object identifier for the ace-e-commerce CP can also accept, process, and rely upon certificates issued within the ABC domain containing the object identifier for the abc-e-commerce CP.
例えば、相互運用性を容易にする目的のために、ACE社がABC社との協定を確立すると仮定して、それぞれの公開鍵がそれらのそれぞれの企業間電子商取引が交換であると互いに機密保護する目的のための他のものの証明当局であることを十字で公認してください。 さらに、それぞれ両社にはエース電子商取引と呼ばれる金融取引保護方針を先在させて、abc-電子商取引があると仮定してください。 人は、2つの会社のアプリケーションが構成されるとそんなに単に2つのドメインの間の交差している証明書を作るのが必要な相互運用性を提供しないで、従業員証明書が居住されるのを見ることができます、それらのそれぞれの証明書方針。 1つの可能なソリューションはどちらの方針も必要として、両方の方針がそれらのCertificate Policies拡張子に現れていてすべての証明書を再発行するために金融アプリケーションのすべてを再構成することです。 他の解決法(管理するのは、より簡単であるかもしれない)はPolicy Mapping分野を使用します。 この分野がACE社の証明権威によって発行されたABC社の証明権威のための交差している証明書に含まれているなら、それはACE社(すなわち、エース電子商取引)のものに同等であるとABCの金融取引保護方針(すなわち、abc-電子商取引)を考えることができるという声明を提供できます。 ABC、信用に発行された交差している証明書にそのような声明を含んでいるのに、エース電子商取引CPのためのオブジェクト識別子を存在に要求するACEドメインのパーティーアプリケーションは、abc-電子商取引CPのためのオブジェクト識別子を含んでいて、ABCドメインの中で発行された証明書を、また、受け入れて、処理して、当てにされることができます。
3.3.3. Policy Constraints Extension
3.3.3. 方針規制拡大
The Policy Constraints extension supports two optional features. The first is the ability for a certification authority to require that explicit CP indications be present in all subsequent certificates in a certification path. Certificates at the start of a certification path may be considered by a relying party to be part of a trusted domain, i.e., certification authorities are trusted for all purposes
Policy Constraints拡張子は2つのオプション機能をサポートします。 1番目は明白なCP指摘が証明経路のすべてのその後の証明書に存在しているのが必要である証明権威のための能力です。 証明経路の始めの証明書は信じられたドメインの一部であると信用パーティーによって考えられるかもしれません、すなわち、証明当局はすべての目的のために信じられます。
Chokhani, et al. Informational [Page 13] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [13ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
so no particular CP is needed in the Certificate Policies extension. Such certificates need not contain explicit indications of CP. When a certification authority in the trusted domain, however, certifies outside the domain, it can activate the requirement that a specific CP's object identifier appear in subsequent certificates in the certification path.
それで、どんな特定のCPもCertificate Policies拡張子で必要ではありません。 そのような証明書はCPの明白なしるしを含む必要はありません。 しかしながら、信じられたドメインの証明権威が外でドメインを公認するとき、それは特定のCPのオブジェクト識別子が証明経路のその後の証明書に現れるという要件を活性化できます。
The other optional feature in the Policy Constraints field is the ability for a certification authority to disable policy mapping by subsequent certification authorities in a certification path. It may be prudent to disable policy mapping when certifying outside the domain. This can assist in controlling risks due to transitive trust, e.g., a domain A trusts domain B, domain B trusts domain C, but domain A does not want to be forced to trust domain C.
Policy Constraints分野におけるもう片方のオプション機能は証明経路でその後の証明当局で方針マッピングを無効にする証明権威のための能力です。 ドメインの外で公認するとき、方針マッピングを無効にするのは慎重であるかもしれません。 これは、遷移的な信頼による危険を制御するのを助けることができます、例えば、ドメインA受託ドメインB、ドメインB受託ドメインC、しかし、ドメインAはドメインCを信じさせるのを必要がありません。
3.3.4. Policy Qualifiers
3.3.4. 方針資格を与える人
The Certificate Policies extension field has a provision for conveying, along with each CP identifier, additional policy-dependent information in a qualifier field. The X.509 standard does not mandate the purpose for which this field is to be used, nor does it prescribe the syntax for this field. Policy qualifier types can be registered by any organization.
Certificate Policies拡大分野には、それぞれのCP識別子と共に資格を与える人分野で追加方針依存する情報を伝えることへの支給があります。 X.509規格は使用されているこの分野がことである目的を強制しません、そして、それはこの分野に構文を定めません。 どんな組織も方針資格を与える人タイプを示すことができます。
The following policy qualifier types are defined in PKIX RFC 3280 [PKI1]:
以下の方針資格を与える人タイプはPKIX RFC3280[PKI1]で定義されます:
(a) The CPS Pointer qualifier contains a pointer to a CPS, CPS
Summary, RPA, or PDS published by the CA. The pointer is in the
form of a uniform resource identifier (URI).
(a) CPS Pointer資格を与える人はカリフォルニアによって発行されたCPS、CPS Summary、RPA、またはPDSに指針を含みます。 指針が一定のリソース識別子(URI)の形にあります。
(b) The User Notice qualifier contains a text string that is to be
displayed to subscribers and relying parties prior to the use of
the certificate. The text string may be an IA5String or a
BMPString - a subset of the ISO 100646-1 multiple octet coded
character set. A CA may invoke a procedure that requires that
the relying party acknowledge that the applicable terms and
conditions have been disclosed and/or accepted.
(b) User Notice資格を与える人は加入者に表示されることになっているテキスト文字列を含みます、そして、信用は証明書の使用の前にパーティーへ行きます。 テキスト文字列は、IA5StringかBMPStringであるかもしれません--ISO100646-1倍数八重奏コード化文字集合の部分集合。 カリフォルニアは信用パーティーが、適切な条件が明らかにされる、そして/または、受け入れられたと認めるのを必要とする手順を呼び出すかもしれません。
Policy qualifiers can be used to support the definition of generic, or parameterized, CPs. Provided the base CP so provides, policy qualifier types can be defined to convey, on a per-certificate basis, additional specific policy details that fill in the generic definition.
CPs、方針資格を与える人をジェネリックの定義をサポートするのに使用するか、またはparameterizedすることができます。 したがって、ベースCPが提供するなら、1証明書あたり1個のベースでジェネリック定義に記入する追加特定保険証券の詳細を伝えるために方針資格を与える人タイプを定義できます。
Chokhani, et al. Informational [Page 14] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [14ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
3.4. Certification Practice Statement
3.4. 認証実施規定
The term certification practice statement (CPS) is defined by the DSG and PAG as: "A statement of the practices which a certification authority employs in issuing certificates." [ABA1, ABA2] As stated above, a CPS establishes practices concerning lifecycle services in addition to issuance, such as certificate management (including publication and archiving), revocation, and renewal or re-keying. In the DSG, the ABA expands this definition with the following comments:
用語認証実施規定(CPS)はDSGとPAGによって以下と定義されます。 「証明権威が証明書を発行する際に使う習慣の声明。」 上に述べられている[ABA1、ABA2]、CPSはlifecycleサービスに関して発行に加えて習慣を設立します、証明書管理(公表と格納を含んでいる)や、取消しや、更新や再の合わせるのなどように。 DSGでは、以下のコメントに従って、ABAはこの定義を広げます:
"A certification practice statement may take the form of a declaration by the certification authority of the details of its trustworthy system and the practices it employs in its operations and in support of issuance of a certificate . . . ." This form of CPS is the most common type, and can vary in length and level of detail.
「認証実施規定は信頼できるシステムの細部とそれが稼働中であり使う習慣の証明権威と証明書の…発行を支持して宣言の形を取るかもしれません」。CPSのThisフォームは、最も一般的なタイプであり、詳細の長さとレベルにおいて異なることができます。
Some PKIs may not have the need to create a thorough and detailed statement of practices. For example, the CA may itself be the relying party and would already be aware of the nature and trustworthiness of its services. In other cases, a PKI may provide certificates providing only a very low level of assurances where the applications being secured may pose only marginal risks if compromised. In these cases, an organization establishing a PKI may only want to write or have CAs use a subscriber agreement, relying party agreement, or agreement combining subscriber and relying party terms, depending on the role of the different PKI participants. In such a PKI, that agreement may serve as the only "statement of practices" used by one or more CAs within that PKI. Consequently, that agreement may also be considered a CPS and can be entitled or subtitled as such.
いくつかのPKIsには、習慣の徹底的で詳細な声明を作成する必要がないかもしれません。 例えば、カリフォルニアがそうするかもしれない、それ自体、信用パーティーであり、既にサービスの自然と信頼できることを意識しているでしょう。 他の場合では、PKIは、感染されるなら保証されるアプリケーションがマージンの危険だけを引き起こすかもしれないところに非常に低いレベルを保証だけを提供しながら、証明書を提供するかもしれません。 PKIを設立する組織は、書きたいか、またはこれらの場合に、CAsに加入者協定、当てにしているパーティー協定か、協定の結合した加入者と信用パーティー用語を使用させるだけでありたいかもしれません、異なったPKI関係者の役割によって。 そのようなPKIでは、その協定はそのPKIの中の1CAsによって使用された「習慣の声明」だけとして機能するかもしれません。 その結果、そういうものとしてその協定を、また、CPSであると考えるかもしれなくて、題するか、または字幕をつけることができます。
Likewise, since a detailed CPS may contain sensitive details of its system, a CA may elect not to publish its entire CPS. It may instead opt to publish a CPS Summary (or CPS Abstract). The CPS Summary would contain only those provisions from the CPS that the CA considers to be relevant to the participants in the PKI (such as the responsibilities of the parties or the stages of the certificate lifecycle). A CPS Summary, however, would not contain those sensitive provisions of the full CPS that might provide an attacker with useful information about the CA's operations. Throughout this document, the use of "CPS" includes both a detailed CPS and a CPS Summary (unless otherwise specified).
同様に、詳細なCPSがシステムの機密の細部を含むかもしれないので、カリフォルニアは、全体のCPSを発行しないのを選ぶかもしれません。それは、CPS Summary(または、CPS要約)を発行するために代わりに選ばれるかもしれません。 CPS SummaryはカリフォルニアがPKI(パーティーの責任か証明書lifecycleの台などの)の関係者に関連していると考えるCPSからのそれらの条項だけを含んでいるでしょう。 しかしながら、CPS SummaryはCAの操作に関する役に立つ情報を攻撃者に提供するかもしれない完全なCPSのそれらの機密の条項を含んでいないでしょう。 このドキュメント中では、「CPS」の使用は詳細なCPSとCPS概要の両方を含んでいます(別の方法で指定されない場合)。
CPSs do not automatically constitute contracts and do not automatically bind PKI participants as a contract would. Where a document serves the dual purpose of being a subscriber or relying party agreement and CPS, the document is intended to be a contract and constitutes a binding contract to the extent that a subscriber or
CPSsは契約を自動的に成立させないで、また契約が縛るように自動的にPKI関係者を縛りません。 またはドキュメントが信用パーティーの加入者か協定とCPS、ドキュメントが契約であることを意図して、拘束力がある契約を範囲に成立させるということである二元的な目的にそのa加入者を取り扱う。
Chokhani, et al. Informational [Page 15] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [15ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
relying party agreement would ordinarily be considered as such. Most CPSs, however, do not serve such a dual purpose. Therefore, in most cases, a CPS's terms have a binding effect as contract terms only if a separate document creates a contractual relationship between the parties and that document incorporates part or all of the CPS by reference. Further, if a particular PKI employs a CPS Summary (as opposed to the entire CPS), the CPS Summary could be incorporated into any applicable subscriber or relying party agreement.
当てにして、通常、パーティー協定はそういうものとして考えられるでしょう。 しかしながら、ほとんどのCPSsはそのような二元的な目的に役立ちません。 したがって、CPSの用語には、別々のドキュメントがパーティーの間の契約上の関係を作成する場合にだけ、多くの場合、契約条件として拘束力があります、そして、そのドキュメントは参照でCPSの部分かすべてを取り入れます。 さらに、特定のPKIがCPS Summary(全体のCPSと対照的に)を使うなら、CPS Summaryはどんな適切な加入者か信用パーティー協定にも組み入れられるかもしれません。
In the future, a court or applicable statutory or regulatory law may declare that a certificate itself is a document that is capable of creating a contractual relationship, to the extent its mechanisms designed for incorporation by reference (such as the Certificate Policies extension and its qualifiers) indicate that terms of its use appear in certain documents. In the meantime, however, some subscriber agreements and relying party agreements may incorporate a CPS by reference and therefore make its terms binding on the parties to such agreements.
将来、法廷か適切な法定の、または、規定の法が、証明書自体が契約上の関係を作成できるドキュメントであると宣言するかもしれません、参照(Certificate Policies拡張子やその資格を与える人などの)で編入のために設計されたメカニズムが、使用に関する諸条件が、あるドキュメントに現れるのを示すという範囲に。 差し当たり、しかしながら、いくつかの加入者協定と信用パーティー協定は、参照でCPSを組み込んで、したがって、用語はそのような協定への当事者に拘束力があるようになるかもしれません。
3.5. Relationship Between Certificate Policy and Certification
Practice Statement
3.5. 証明書方針と認証実施規定との関係
The CP and CPS address the same set of topics that are of interest to the relying party in terms of the degree to and purpose for which a public key certificate should be trusted. Their primary difference is in the focus of their provisions. A CP sets forth the requirements and standards imposed by the PKI with respect to the various topics. In other words, the purpose of the CP is to establish what participants must do. A CPS, by contrast, states how a CA and other participants in a given domain implement procedures and controls to meet the requirements stated in the CP. In other words, the purpose of the CPS is to disclose how the participants perform their functions and implement controls.
CPとCPSは同じセットのそれが度合いに関する信用パーティーにおもしろい話題と公開鍵証明書が信じられるべきである目的を扱います。 それらのプライマリ違いがそれらの条項の焦点にあります。 CPは様々な話題に関してPKIによって課された要件と規格について詳しく説明します。 言い換えれば、CPの目的は関係者がしなければならないことを確立することです。 対照的に、CPSは与えられたドメインのカリフォルニアと他の関係者がCPに述べられた必要条件を満たすためにどう手順とコントロールを実装するかを述べます。 言い換えれば、CPSの目的は関係者がどう彼らの機能を実行して、コントロールを実装するかを明らかにすることです。
An additional difference between a CP and CPS relates the scope of coverage of the two kinds of documents. Since a CP is a statement of requirements, it best serves as the vehicle for communicating minimum operating guidelines that must be met by interoperating PKIs. Thus, a CP generally applies to multiple CAs, multiple organizations, or multiple domains. By contrast, a CPS applies only to a single CA or single organization and is not generally a vehicle to facilitate interoperation.
CPとCPSの追加違いは2種類のドキュメントの普及率の範囲を関係づけます。 CPが要件の声明であるので、それはPKIsを共同利用することによって満たさなければならない最小の操作ガイドラインを伝えるための乗り物として最もよく機能します。 したがって、一般に、CPは複数のCAs、複数の組織、または複数のドメインに適用します。 対照的に、CPSは単一のカリフォルニアか単純組織だけに適用して、一般に、interoperationを容易にする乗り物ではありません。
A CA with a single CPS may support multiple CPs (used for different application purposes and/or by different relying party communities). Also, multiple CAs, with non-identical CPSs, may support the same CP.
独身のCPSがあるカリフォルニアは複数のCPs(異なったアプリケーション目的異なった当てにしているパーティー社会によって使用される)をサポートするかもしれません。 また、複数のCAsが非同じCPSsと共に同じCPをサポートするかもしれません。
Chokhani, et al. Informational [Page 16] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [16ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
For example, the Federal Government might define a government-wide CP for handling confidential human resources information. The CP will be a broad statement of the general requirements for participants within the Government's PKI, and an indication of the types of applications for which it is suitable for use. Each department or agency wishing to operate a certification authority in this PKI may be required to write its own certification practice statement to support this CP by explaining how it meets the requirements of the CP. At the same time, a department's or agency's CPS may support other certificate policies.
例えば、連邦政府は、秘密の人的資源情報を扱うために政府全体のCPを定義するかもしれません。 CPは政府のPKIの中の関係者のための一般的な要件の広い声明と、それが使用に適しているアプリケーションのタイプのしるしになるでしょう。 各部かこのPKIの証明権威を操作したがっている政府機関が、それがどうCPに関する必要条件を満たすかを説明することによってこのCPをサポートするためにそれ自身の認証実施規定を書かなければならないかもしれません。 同時に、部か政府機関のCPSは、他の証明書が方針であるとサポートするかもしれません。
An additional difference between a CP and CPS concerns the level of detail of the provisions in each. Although the level of detail may vary among CPSs, a CPS will generally be more detailed than a CP. A CPS provides a detailed description of procedures and controls in place to meet the CP requirements, while a CP is more general.
CPとCPSの追加違いはそれぞれの条項の詳細のレベルに関係があります。 詳細のレベルがCPSsの中で異なるかもしれませんが、一般に、CPSはCPよりさらに詳細になるでしょう。 CPSはCP必要条件を満たすために手順とコントロールの詳述を適所に提供します、CPは、より一般的ですが。
The main differences between CPs and CPSs can therefore be summarized as follows:
したがって、以下の通りCPsとCPSsの主な違いをまとめることができます:
(a) A PKI uses a CP to establish requirements that state what
participants within it must do. A single CA or organization can
use a CPS to disclose how it meets the requirements of a CP or
how it implements its practices and controls.
(a) PKIは、それの中の関係者がしなければならないことを述べる要件を証明するのにCPを使用します。 単一のカリフォルニアか組織が、どのようにCPに関する必要条件を満たすか、そして、またはそれがどのようにその習慣とコントロールを実装するかを明らかにするのにCPSを使用できます。
(b) A CP facilitates interoperation through cross-certification,
unilateral certification, or other means. Therefore, it is
intended to cover multiple CAs. By contrast, a CPS is a
statement of a single CA or organization. Its purpose is not to
facilitate interoperation (since doing so is the function of a
CP).
(b) CPは相互認証、一方的な証明、または他の手段でinteroperationを容易にします。 したがって、複数のCAsをカバーするのは意図しています。 対照的に、CPSは単一のカリフォルニアか組織の声明です。 目的はinteroperationを容易にしない(そうするのが、CPの機能であるので)ことです。
(c) A CPS is generally more detailed than a CP and specifies how the
CA meets the requirements specified in the one or more CPs under
which it issues certificates.
(c) CPSは一般に、CPより詳細であり、カリフォルニアがどうそれが証明書を発行する1CPsで指定された必要条件を満たすかを指定します。
In addition to populating the certificate policies extension with the applicable CP object identifier, a certification authority may include, in certificates it issues, a reference to its certification practice statement. A standard way to do this, using a CP qualifier, is described in Section 3.4.
適切なCPオブジェクト識別子で証明書方針拡張子に居住することに加えて、証明権威はそれが発行する証明書に認証実施規定の指示するものを含むかもしれません。 CP資格を与える人を使用して、これをする標準の方法はセクション3.4に述べられます。
3.6. Relationship Among CPs, CPSs, Agreements, and Other Documents
3.6. CPs、CPSs、協定、および他のドキュメントの中の関係
CPs and CPSs play a central role in documenting the requirements and practices of a PKI. Nonetheless, they are not the only documents relevant to a PKI. For instance, subscriber agreements and relying party agreements play a critical role in allocating responsibilities
CPsとCPSsはPKIの要件と習慣を記録する際に中心的役割を果たします。 それにもかかわらず、それらはPKIに関連している唯一のドキュメントではありません。 例えば、加入者協定と信用パーティー協定は責任を割り当てることにおける重要な役割を果たします。
Chokhani, et al. Informational [Page 17] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [17ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
to subscribers and relying parties relating to the use of certificates and key pairs. They establish the terms and conditions under which certificates are issued, managed, and used. The term subscriber agreement is defined by the PAG as: "An agreement between a CA and a subscriber that establishes the right and obligations of the parties regarding the issuance and management of certificates." [ABA2] The PAG defines a relying party agreement as: "An agreement between a certification authority and relying party that typically establishes the rights and obligations between those parties regarding the verification of digital signatures or other uses of certificates." [ABA2]
加入者と信用パーティーと、証明書とキーの使用に関連するのは対にされます。 彼らは証明書が発行されて、管理されて、使用される条件を確立します。 用語加入者協定はPAGによって以下と定義されます。 「カリフォルニアと加入者との証明書の発行と管理に関してパーティーの権利と義務を確立する協定。」 [ABA2] PAGは当てにしているパーティー協定を以下と定義します。 「証明権威と信用パーティーとのデジタル署名の検証か証明書の他の用途に関してそれらのパーティーの間の権利と義務を通常確立する協定。」 [ABA2]
As mentioned in Section 3.5, a subscriber agreement, relying party agreement, or an agreement that combines subscriber and relying party terms may also serve as a CPS. In other PKIs, however, a subscriber or relying party agreement may incorporate some or all of the terms of a CP or CPS by reference. Yet other PKIs may distill from a CP and/or CPS the terms that are applicable to a subscriber and place such terms in a self-contained subscriber agreement, without incorporating a CP or CPS by reference. They may use the same method to distill relying party terms from a CP and/or CPS and place such terms in a self-contained relying party agreement. Creating such self-contained agreements has the advantage of creating documents that are easier for consumers to review. In some cases, subscribers or relying parties may be deemed to be "consumers" under applicable law, who are subject to certain statutory or regulatory protections. Under the legal systems of civil law countries, incorporating a CP or CPS by reference may not be effective to bind consumers to the terms of an incorporated CP or CPS.
また、言及されるように、セクション3.5、加入者協定、パーティー協定、または加入者と信用パーティー用語を結合する協定がそうする信用ではCPSとして機能してください。しかしながら、他のPKIsに、加入者か信用パーティー協定は参照でCPかCPSの用語のいくつかかすべてを組み込んでもよいです。 しかし、他のPKIsはCP、そして/または、CPSから加入者に適切な用語を蒸留して、自己充足的な加入者合意にそのような用語を置くかもしれません、参照でCPかCPSを組み込まないで。 彼らは自己充足的な当てにしているパーティー合意にCP、そして/または、CPSからの当てにしているパーティー用語を蒸留して、そのような用語を置く同じ方法を使用するかもしれません。 そのような自己充足的な協定を作成するのにおいて、消費者が論評するより簡単なドキュメントを作成する利点があります。 いくつかの場合、加入者か信用パーティーが準拠法の下における「消費者」であると考えられるかもしれません。(」はある法定の、または、規定の保護を受けることがあります)。 民法国の法的なシステムの下では、参照でCPかCPSを組み込むのは、法人組織のCPかCPSの用語まで消費者を縛るのに有効でないかもしれません。
CPs and CPSs may be incorporated by reference in other documents, including:
CPsとCPSsは他のドキュメント、包含における参照で組み込まれるかもしれません:
* Interoperability agreements (including agreements between CAs for
cross-certification, unilateral certification, or other forms of
interoperation),
* 相互運用性協定(interoperationの相互認証、一方的な証明、または他のフォームのためのCAsの間の協定を含んでいます)
* Vendor agreements (under which a PKI vendor agrees to meet
standards set forth in a CP or CPS), or
* または業者協定(PKI業者はそこでCPかCPSに詳しく説明された規格を満たすのに同意する)。
* A PDS. See [ABA2]
* PDS。 見てください。[ABA2]
A PDS serves a similar function to a CPS Summary. It is a relatively short document containing only a subset of critical details about a PKI or CA. It may differ from a CPS Summary, however, in that its purpose is to act as a summary of information about the overall nature of the PKI, as opposed to simply a condensed form of the CPS.
PDSは同様の機能をCPS Summaryに果たします。 それはPKIかカリフォルニアに関する批判的な詳細の部分集合だけを含む比較的短いドキュメントです。 と対照的に、しかしながら、それが目的がPKIの総合的な自然の情報の概要として機能することであるという点においてCPS Summaryと異なるかもしれない、単にCPSの要約したフォーム。
Chokhani, et al. Informational [Page 18] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [18ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
Moreover, its purpose is to distill information about the PKI, as opposed to protecting security sensitive information contained in an unpublished CPS, although a PDS could also serve that function.
そのうえ、目的はPKIの情報を蒸留することです、未発表のCPSに含まれたセキュリティ機密情報を保護することと対照的に、また、PDSがその機能を果たすかもしれませんが。
Just as writers may wish to refer to a CP or CPS or incorporate it by reference in an agreement or PDS, a CP or CPS may refer to other documents when establishing requirements or making disclosures. For instance, a CP may set requirements for certificate content by referring to an external document setting forth a standard certificate profile. Referencing external documents permits a CP or CPS to impose detailed requirements or make detailed disclosures without having to reprint lengthy provisions from other documents within the CP or CPS. Moreover, referencing a document in a CP or CPS is another useful way of dividing disclosures between public information and security sensitive confidential information (in addition to or as an alternative to publishing a CPS Summary). For example, a PKI may want to publish a CP or CPS, but maintain site construction parameters for CA high security zones as confidential information. In that case, the CP or CPS could reference an external manual or document containing the detailed site construction parameters.
要件を確立するか、または公開をするとき、作家がCPかCPSについて言及したいか、またはちょうど協定かPDSでの参照でそれを取り入れたがっているかもしれないように、CPかCPSが他のドキュメントを参照するかもしれません。 例えば、CPは、証明書内容のために標準の証明書プロフィールについて詳しく説明しながら外部のドキュメントを参照することによって、必要条件を定めるかもしれません。 外部のドキュメントに参照をつけるのは、CPかCPSがCPかCPSの中で他のドキュメントから長い条項を増刷する必要はなくて詳細な要件を課すか、または詳細な公開をすることを許可します。そのうえ、CPかCPSのドキュメントに参照をつけるのは、公開情報とセキュリティの機密の秘密情報(発行かCPS Summaryを発行することに代わる手段として)の間の公開を分割する別の役に立つ方法です。 例えば、PKIはCPかCPSを発行したがっているかもしれませんが、秘密情報としてカリフォルニアの高いセキュリティーゾーンのためのサイト工事パラメタを維持してください。 その場合、CPかCPSが詳細なサイト工事パラメタを含む外部のマニュアルかドキュメントに参照をつけるかもしれません。
Documents that a PKI may wish to refer to in a CP or CPS include:
PKIがCPかCPSで参照したがっているかもしれないドキュメントは:
* A security policy,
* 安全保障政策
* Training, operational, installation, and user manuals (which may
contain operational requirements),
* 訓練していて、操作上のインストール、および利用者マニュアル(操作上の要件を含むかもしれません)
* Standards documents that apply to particular aspects of the PKI
(such as standards specifying the level of protection offered by
any hardware tokens used in the PKI or standards applicable to the
site construction),
* PKI(PKIで使用されるどんなハードウェア象徴かサイト工事に適切な規格によっても提供された保護のレベルを指定する規格などの)の特定の局面に適用される規格文書
* Key management plans,
* かぎ管理は計画されています。
* Human resource guides and employment manuals (which may describe
some aspects of personnel security practices), and
* そして人的資源ガイドと雇用マニュアル(人的安全保護習慣のいくつかの局面について説明するかもしれない)。
* E-mail policies (which may discuss subscriber and relying party
responsibilities, as well as the implications of key management,
if applicable). See [ABA2]
* 方針(適切であるなら、かぎ管理の含意と同様に加入者と信用パーティー責任について議論するかもしれない)をメールしてください。 見てください。[ABA2]
Chokhani, et al. Informational [Page 19] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [19ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
3.7. Set of Provisions
3.7. 条項のセット
A set of provisions is a collection of practice and/or policy statements, spanning a range of standard topics for use in expressing a CP or CPS employing the approach described in this framework by covering the topic appearing in Section 5 below. They are also described in detail in Section 4 below.
CPかこの枠組みでセクション5に以下に現れる話題をカバーすることによって説明されたアプローチを使うCPSを急送することにおける使用のためにさまざまな標準の話題にかかっていて、1セットの条項は習慣、そして/または、施政方針の収集です。 また、それらは以下のセクション4で詳細に説明されます。
A CP can be expressed as a single set of provisions.
1セットの条項としてCPを急送できます。
A CPS can be expressed as a single set of provisions with each component addressing the requirements of one or more certificate policies, or, alternatively, as an organized collection of sets of provisions. For example, a CPS could be expressed as a combination of the following:
各コンポーネントが1つ以上の証明書方針の要件を記述している1セットの条項として、または、代わりに条項のセットの組織化された収集としてCPSを急送できます。 例えば、以下の組み合わせとしてCPSを急送できました:
(a) a list of certificate policies supported by the CPS;
(a) CPSによって支持された証明書方針のリスト。
(b) for each CP in (a), a set of provisions that contains statements
responding to that CP by filling in details not stipulated in
that policy or expressly left to the discretion of the CA (in its
CPS) ; such statements serve to state how this particular CPS
implements the requirements of the particular CP; or
(b) (a)の各CPのために、その方針か明白に規定されなかった詳細に記入することによってそのCPに応じる声明を含む1セットの条項はカリフォルニア(CPSの)にいなくなりました。 そのような声明は、この特定のCPSがどう特定のCPの要件を実行するかを述べるのに役立ちます。 または
(c) a set of provisions that contains statements regarding the
certification practices on the CA, regardless of CP.
(c) 証明に関する声明を含む1セットの条項がCPにかかわらずカリフォルニアを練習します。
The statements provided in (b) and (c) may augment or refine the stipulations of the applicable CP, but generally must not conflict with any of the stipulations of such CP. In certain cases, however, a policy authority may permit exceptions to the requirements in a CP, because certain compensating controls of the CA are disclosed in its CPS that allow the CA to provide assurances that are equivalent to the assurances provided by CAs that are in full compliance with the CP.
(b)と(c)に提供された声明は、適切なCPの約款を増大するか、または洗練するかもしれませんが、一般に、そのようなCPの約款のいずれも衝突してはいけません。 ある場合には、しかしながら、方針権威はCPの要件への例外を可能にするかもしれません、カリフォルニアのある代償コントロールがカリフォルニアにCPに応えてあるCAsによって提供された保証に同等な保証を提供させるCPSで明らかにされるので。
This framework outlines the contents of a set of provisions, in terms of nine primary components, as follows:
この枠組みは以下の通り9つの第一の構成要素に関して1セットの条項のコンテンツについて概説します:
1. Introduction 2. Publication and Repository 3. Identification and Authentication 4. Certificate Life-Cycle Operational Requirements 5. Facilities, Management, and Operational Controls 6. Technical Security Controls 7. Certificate, CRL, and OCSP Profile 8. Compliance audit 9. Other Business and Legal Matters
1. 序論2。 公表と倉庫3。 識別と認証4。 ライフサイクルの操作上の要件5を証明してください。 施設、管理、および運用統制6。 技術的なセキュリティは7を制御します。 証明書、CRL、およびOCSPプロフィール8。 承諾監査9。 他のビジネスと法的な件
Chokhani, et al. Informational [Page 20] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [20ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
PKIs can use this simple framework of nine primary components to write a simple CP or CPS. Moreover, a CA can use this same framework to write a subscriber agreement, relying party agreement, or agreement containing subscriber and relying party terms. If a CA uses this simple framework to construct an agreement, it can use paragraph 1 as an introduction or recitals, it can set forth the responsibilities of the parties in paragraphs 2-8, and it can use paragraph 9 to cover the business and legal issues described in more detail, using the ordering of Section 4.9 below (such as representations and warranties, disclaimers, and liability limitations). The ordering of topics in this simple framework and the business and legal matters Section 4.9 is the same as (or similar to) the ordering of topics in a typical software or other technology agreement. Therefore, a PKI can establish a set of core documents (with a CP, CPS, subscriber agreement, and relying party agreement) all having the same structure and ordering of topics, thereby facilitating comparisons and mappings among these documents and among the corresponding documents of other PKIs.
PKIsは、簡単なCPかCPSに書くのに9つの第一の構成要素のこの簡単な枠組みを使用できます。そのうえ、カリフォルニアは、パーティー協定か、加入者を含む協定と当てにしているパーティー用語を加入者協定、信用に書くのにこの同じ枠組みを使用できます; カリフォルニアが協定を構成するのにこの簡単な枠組みを使用するなら、序論かリサイタルとしてパラグラフ1を使用できます、そして、パラグラフ2-8におけるパーティーの責任について詳しく説明できます、そして、さらに詳細に説明されたビジネスと法律問題を含むのにパラグラフ9を使用できます、以下のセクション4.9(表明保証条項や、注意書きや、責任制限などの)の注文を使用して。 この簡単な枠組み、ビジネス、および法的では、4.9が同じ、そして、(同様)であるセクションは重要です。話題の注文、典型的なソフトウェアか他の技術合意における、話題の注文。 したがって、PKIは同じ構造をすべて持って、話題を注文しながら、1セットのコアドキュメント(CPとのCPS、加入者協定、および信用パーティー協定)を確立できます、その結果、これらのドキュメントの中と、そして、他のPKIsの対応するドキュメントの中で比較とマッピングを容易にします。
This simple framework may also be useful for agreements other than subscriber agreements and relying party agreements. For instance, a CA wishing to outsource certain services to an RA or certificate manufacturing authority (CMA) may find it useful to use this framework as a checklist to write a registration authority agreement or outsourcing agreement. Similarly, two CAs may wish to use this simple framework for the purpose of drafting a cross-certification, unilateral certification, or other interoperability agreement.
また、この簡単な枠組みも加入者協定と信用パーティー協定以外の協定の役に立つかもしれません。 例えば、RAに対する、あるサービスを社外調達したがっているカリフォルニアか証明書製造権威(CMA)によって、登録局協定かアウトソーシング協定を書くのにチェックリストとしてこの枠組みを使用するのが役に立つのがわかるかもしれません。 同様に、2CAsが相互認証、一方的な証明、または他の相互運用性協定を作成する目的にこの簡単な枠組みを使用したがっているかもしれません。
In short, the primary components of the simple framework (specified above) may meet the needs of drafters of short CPs, CPSs, subscriber agreements, and relying party agreements. Nonetheless, this framework is extensible, and its coverage of the nine components is flexible enough to meet the needs of drafters of comprehensive CPs and CPSs. Specifically, components appearing above can be further divided into subcomponents, and a subcomponent may comprise multiple elements. Section 4 provides a more detailed description of the contents of the above components, and their subcomponents. Drafters of CPs and CPSs are permitted to add additional levels of subcomponents below the subcomponents described in Section 4 for the purpose of meeting the needs of the drafter's particular PKI.
要するに、簡単な枠組み(上では、指定される)の第一の構成要素は短いCPs(CPSs、加入者協定、および信用パーティー協定)のドラフターの需要を満たすかもしれません。 それにもかかわらず、この枠組みは広げることができます、そして、9つのコンポーネントの適用範囲は包括的なCPsとCPSsのドラフターの需要を満たすほどフレキシブルです。 明確に、さらに上に現れるコンポーネントはサブコンポーネントに分割できます、そして、サブコンポーネントは複数の要素を包括するかもしれません。 セクション4は上のコンポーネントのコンテンツの、より詳細な記述、およびそれらのサブコンポーネントを提供します。 CPsとCPSsのドラフターがドラフターの特定のPKIの需要を満たす目的のためにセクション4で説明されたサブコンポーネントの下で追加レベルのサブコンポーネントを加えることが許可されています。
4. Contents of a Set of Provisions
4. 1セットの条項のコンテンツ
This section expands upon the contents of the simple framework of provisions, as introduced in Section 3.7. The topics identified in this section are, consequently, candidate topics for inclusion in a detailed CP or CPS.
このセクションはセクション3.7で導入するように条項の簡単な枠組みのコンテンツで膨張します。 その結果、このセクションで特定された話題は詳細なCPかCPSでの包含のための候補話題です。
Chokhani, et al. Informational [Page 21] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [21ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
While many topics are identified, it is not necessary for a CP or a CPS to include a concrete statement for every such topic. Rather, a particular CP or CPS may state "no stipulation" for a component, subcomponent, or element on which the particular CP or CPS imposes no requirements or makes no disclosure. In this sense, the list of topics can be considered a checklist of topics for consideration by the CP or CPS writer.
多くの話題が特定されますが、CPかCPSがそのようなあらゆる話題のための具体的な声明を含むのは必要ではありません。 むしろ、特定のCPかCPSがコンポーネント、サブコンポーネント、または要素のための特定のCPかCPSが要件を全く課さないか、または公開を全くしない「約款がありません」を述べるかもしれません。 この意味で、CPかCPS作家が、考慮のための話題に関するチェックリストであると話題のリストを考えることができます。
It is recommended that each and every component and subcomponent be included in a CP or CPS, even if there is "no stipulation"; this will indicate to the reader that a conscious decision was made to include or exclude a provision concerning that topic. This drafting style protects against inadvertent omission of a topic, while facilitating comparison of different certificate policies or CPSs, e.g., when making policy mapping decisions.
それぞれとあらゆるコンポーネントとサブコンポーネントがCPかCPSに含まれているのは、お勧めです、「約款がありません」があっても。 これは、その話題に関して支給を含んでいるか、または除くのを意識的な決断をしたのを読者に示すでしょう。 この草稿スタイルは例えば、決定を写像しながら方針を打ち出すとき、異なった証明書方針かCPSsの比較を容易にしている間、話題の不注意な省略から守ります。
In a CP, it is possible to leave certain components, subcomponents, and/or elements unspecified, and to stipulate that the required information will be indicated in a policy qualifier, or the document to which a policy qualifier points. Such CPs can be considered parameterized definitions. The set of provisions should reference or define the required policy qualifier types and should specify any applicable default values.
CPでは、あるコンポーネント、サブコンポーネント、そして/または、要素を不特定のままにし、必須情報が方針資格を与える人、または方針資格を与える人が指すドキュメントで示されるのを規定するのは可能です。 parameterized定義であるとそのようなCPsを考えることができます。 条項のセットは、必要な方針資格を与える人タイプを参照をつけるべきであるか、または定義するべきです、そして、どんな適切なデフォルト値も指定するべきです。
4.1. Introductions
4.1. 序論
This component identifies and introduces the set of provisions, and indicates the types of entities and applications for which the document (either the CP or the CPS being written) is targeted.
このコンポーネントは、条項のセットを特定して、導入して、ドキュメント(書かれているCPかCPSのどちらか)が狙う実体とアプリケーションのタイプを示します。
4.1.1. Overview
4.1.1. 概観
This subcomponent provides a general introduction to the document being written. This subcomponent can also be used to provide a synopsis of the PKI to which the CP or CPS applies. For example, it may set out different levels of assurance provided by certificates within the PKI. Depending on the complexity and scope of the particular PKI, a diagrammatic representation of the PKI might be useful here.
書かれていて、このサブコンポーネントは一般的な序論をドキュメントに供給します。 また、CPかCPSが適用するPKIの構文を提供するのにこのサブコンポーネントを使用できます。 例えば、それはPKIの中を証明書によって提供された異なったレベルを保証を始めるかもしれません。 特定のPKIの複雑さと範囲によって、PKIの図の表現はここで役に立つかもしれません。
4.1.2. Document Name and Identification
4.1.2. ドキュメント名と識別
This subcomponent provides any applicable names or other identifiers, including ASN.1 object identifiers, for the document. An example of such a document name would be the US Federal Government Policy for Secure E-mail.
このサブコンポーネントはドキュメントのためのASN.1物の識別子を含むどんな適切な名前や他の識別子も提供します。 そのようなドキュメント名に関する例はSecureメールのための米国連邦政府Policyでしょう。
Chokhani, et al. Informational [Page 22] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [22ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
4.1.3. PKI Participants
4.1.3. PKI関係者
This subcomponent describes the identity or types of entities that fill the roles of participants within a PKI, namely:
このサブコンポーネントがPKIの中に関係者の役割をいっぱいにする実体のアイデンティティかタイプについて説明する、すなわち:
* Certification authorities, i.e., the entities that issue
certificates. A CA is the issuing CA with respect to the
certificates it issues and is the subject CA with respect to the
CA certificate issued to it. CAs may be organized in a hierarchy
in which an organization's CA issues certificates to CAs operated
by subordinate organizations, such as a branch, division, or
department within a larger organization.
* すなわち、証明当局、証明書を発行する実体。 カリフォルニアは、それが発行する証明書に関する発行カリフォルニアであり、カリフォルニア証明書に関するカリフォルニアがそれに発行した対象です。 CAsは組織のカリフォルニアが下位の組織によって運用されたCAsに証明書を発行する階層構造で組織化されるかもしれません、より大きい組織の中のブランチ、分割、または部などのように。
* Registration authorities, i.e., the entities that establish
enrollment procedures for end-user certificate applicants, perform
identification and authentication of certificate applicants,
initiate or pass along revocation requests for certificates, and
approve applications for renewal or re-keying certificates on
behalf of a CA. Subordinate organizations within a larger
organization can act as RAs for the CA serving the entire
organization, but RAs may also be external to the CA.
* 登録局(すなわち、エンドユーザ証明書応募者のために登録手順を確立する実体)は、証明書応募者の識別と認証を実行して、証明書のために取消し要求を開始するか、または伝えて、更新かカリフォルニアを代表して証明書を再合わせるためにアプリケーションを承認します。 より大きい組織の中の下位の組織は全体の組織に役立つカリフォルニアへのRAsとして機能できますが、また、RAsもカリフォルニアに外部であるかもしれません。
* Subscribers. Examples of subscribers who receive certificates
from a CA include employees of an organization with its own CA,
banking or brokerage customers, organizations hosting e-commerce
sites, organizations participating in a business-to-business
exchange, and members of the public receiving certificates from a
CA issuing certificates to the public at large.
* 加入者。 カリフォルニアから証明書を受け取る加入者の例は証明書を発行するカリフォルニアから社会全般までそれ自身のカリフォルニア、銀行業または仲買業の顧客との組織の電子商取引サイトをホスティングする組織、企業間電子商取引交換、および証明書を受け取る公衆のメンバーに参加する組織の従業員を含んでいます。
* Relying parties. Examples of relying parties include employees of
an organization having its own CA who receive digitally signed e-
mails from other employees, persons buying goods and services from
e-commerce sites, organizations participating in a business-to-
business exchange who receive bids or orders from other
participating organizations, and individuals and organizations
doing business with subscribers who have received their
certificates from a CA issuing certificates to the public.
Relying parties may or may not also be subscribers within a given
PKI.
* 信用はパーティーへ行きます。 信用パーティーに関する例は他の従業員、商品を買う人々、およびサービスから電子商取引サイトからデジタルにサインされた電子メールを受け取る組織にはそれ自身のカリフォルニアがある従業員を含んでいます、組織は他の参加組織からビジネスからビジネス・エクスチェンジにだれが付け値を受け取るか、そして、命令を参加させて、公衆に証明書を発行するカリフォルニアから彼らの証明書を受け取った加入者とビジネスをする個人と組織を参加させて。 また、信用パーティーは与えられたPKIの中の加入者であるかもしれません。
* Other participants, such as certificate manufacturing authorities,
providers of repository services, and other entities providing
PKI-related services.
* 証明書製造当局や、倉庫サービスのプロバイダーや、PKI関連のサービスを提供する他の実体などの他の関係者。
Chokhani, et al. Informational [Page 23] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [23ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
4.1.4. Certificate Usage
4.1.4. 証明書用法
This subcomponent contains:
このサブコンポーネントは以下を含んでいます。
* A list or the types of applications for which the issued
certificates are suitable, such as electronic mail, retail
transactions, contracts, and a travel order, and/or
* そして/または発行された証明書が電子メールや、小売の取引や、契約や、旅行命令などのように適しているアプリケーションのリストかタイプ。
* A list or the types of applications for which use of the issued
certificates is prohibited.
* 発行された証明書の使用が禁止されているアプリケーションのリストかタイプ。
In the case of a CP or CPS describing different levels of assurance, this subcomponent can describe applications or types of applications that are appropriate or inappropriate for the different levels of assurance.
異なったレベルを保証について説明するCPかCPSの場合では、このサブコンポーネントは異なったレベルを保証で適切であるか、または不適当なアプリケーションのアプリケーションかタイプについて説明できます。
4.1.5. Policy Administration
4.1.5. 方針政権
This subcomponent includes the name and mailing address of the organization that is responsible for the drafting, registering, maintaining, and updating of this CP or CPS. It also includes the name, electronic mail address, telephone number, and fax number of a contact person. As an alternative to naming an actual person, the document may name a title or role, an e-mail alias, and other generalized contact information. In some cases, the organization may state that its contact person, alone or in combination with others, is available to answer questions about the document.
このサブコンポーネントはこのCPかCPSの名前、草稿に責任がある組織の郵送先住所、登録、維持、およびアップデートを含んでいます。また、それは連絡窓口の名前、電子メールアドレス、電話番号、およびファックス番号を含んでいます。 実在の人物を命名することに代わる手段として、ドキュメントはタイトルか役割(メール別名の、そして、他の一般化された問い合わせ先)を命名するかもしれません。 いくつかの場合、組織は、連絡窓口が単独か他のものと組み合わせてドキュメントに関する質問に答えることができると述べるかもしれません。
Moreover, when a formal or informal policy authority is responsible for determining whether a CA should be allowed to operate within or interoperate with a PKI, it may wish to approve the CPS of the CA as being suitable for the policy authority's CP. If so, this subcomponent can include the name or title, electronic mail address (or alias), telephone number, fax number, and other generalized information of the entity in charge of making such a determination. Finally, in this case, this subcomponent also includes the procedures by which this determination is made.
PKIと共に中で作動するべきであるか、またはカリフォルニアが共同利用できるべきであるかどうか決定するのに正式であるか非公式の方針権威が原因となるとき、そのうえ、それは方針権威のCPに適当であるとしてカリフォルニアのCPSを承認したがっているかもしれません。 そうだとすれば、そのような決断をすることを担当してこのサブコンポーネントは実体の名前かタイトルと、電子メールアドレス(通称)と、電話番号と、ファックス番号と、他の一般化された情報を含むことができます。 また、最終的に、この場合、このサブコンポーネントはこの決断がされる手順を含んでいます。
4.1.6. Definitions and Acronyms
4.1.6. 定義と頭文字語
This subcomponent contains a list of definitions for defined terms used within the document, as well as a list of acronyms in the document and their meanings.
このサブコンポーネントはドキュメントの中に使用された定義された用語のときに定義のリストを含みます、ドキュメントの頭文字語のリストとそれらの意味と同様に。
Chokhani, et al. Informational [Page 24] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [24ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
4.2. Publication and Repository Responsibilities
4.2. 公表と倉庫責任
This component contains any applicable provisions regarding:
このコンポーネントは以下に関してどんな適切な条項も含んでいます。
* An identification of the entity or entities that operate
repositories within the PKI, such as a CA, certificate
manufacturing authority, or independent repository service
provider;
* 実体の識別かPKIの中で倉庫を操作するカリフォルニア、証明書製造権威、または独立している倉庫サービスプロバイダーなどの実体。
* The responsibility of a PKI participant to publish information
regarding its practices, certificates, and the current status of
such certificates, which may include the responsibilities of
making the CP or CPS publicly available using various mechanisms
and of identifying components, subcomponents, and elements of such
documents that exist but are not made publicly available, for
instance, security controls, clearance procedures, or trade secret
information due to their sensitivity;
* PKI関係者がそれらの感度のため例えば、習慣、証明書、および様々なメカニズムを使用することでCPかCPSを公的に利用可能にして、存在するそのようなドキュメントのコンポーネント、サブコンポーネント、および要素を特定する責任を含むかもしれませんが、公的に利用可能にされないそのような証明書の現在の状態の情報、機密管理、クリアランス手順、または企業秘密に属する情報を発表する責任。
* When information must be published and the frequency of
publication; and
* いつ情報を発表しなければなりませんか、そして、公表の頻度。 そして
* Access control on published information objects including CPs,
CPS, certificates, certificate status, and CRLs.
* CPs、CPS、証明書、証明書状態、およびCRLsを含んでいて、発行された情報物の上にコントロールにアクセスしてください。
4.3. Identification and Authentication
4.3. 識別と認証
This component describes the procedures used to authenticate the identity and/or other attributes of an end-user certificate applicant to a CA or RA prior to certificate issuance. In addition, the component sets forth the procedures for authenticating the identity and the criteria for accepting applicants of entities seeking to become CAs, RAs, or other entities operating in or interoperating with a PKI. It also describes how parties requesting re-key or revocation are authenticated. This component also addresses naming practices, including the recognition of trademark rights in certain names.
このコンポーネントは証明書発行の前にエンドユーザ証明書応募者のアイデンティティ、そして/または、他の属性をカリフォルニアかRAに認証するのに用いられた手順について説明します。 さらに、コンポーネントは、実体の応募者を受け入れるアイデンティティを認証して、評価基準のためにPKIと共に作動するか、または共同利用するCAs、RAs、または他の実体になろうとしながら、手順について詳しく説明します。 また、それは再キーを要求するパーティーか取消しがどう認証されるかを説明します。 また、このコンポーネントはある名前における、商標権の認識を含む命名練習を記述します。
4.3.1. Naming
4.3.1. 命名
This subcomponent includes the following elements regarding naming and identification of the subscribers:
このサブコンポーネントは加入者の命名と識別に関する以下の要素を含んでいます:
* Types of names assigned to the subject, such as X.500
distinguished names; RFC-822 names; and X.400 names;
* 対象に割り当てられたX.500分類名などの名前のタイプ。 RFC-822名。 X.400名。
* Whether names have to be meaningful or not;(3)
* 名前が重要でなければならないか否かに関係なく。(3)
Chokhani, et al. Informational [Page 25] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [25ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
* Whether or not subscribers can be anonymous or pseudonymous, and
if they can, what names are assigned to or can be used by
anonymous subscribers;
* 彼らがそうすることができるか、そして、加入者が匿名である、または偽名である場合があるか、そして、名前が割り当てられる何か缶、匿名の加入者によって使用されてください。
* Rules for interpreting various name forms, such as the X.500
standard and RFC-822;
* X.500規格やRFC-822などの様々な名前フォームを解釈するための規則。
* Whether names have to be unique; and
* 名前が特有でなければならないか否かに関係なく。 そして
* Recognition, authentication, and the role of trademarks.
* 商標の認識、認証、および役割。
4.3.2. Initial Identity Validation
4.3.2. 初期のアイデンティティ合法化
This subcomponent contains the following elements for the identification and authentication procedures for the initial registration for each subject type (CA, RA, subscriber, or other participant):
このサブコンポーネントは識別のための以下の要素を含んでいます、そして、各対象のための新規登録のための認証手順は(カリフォルニア、RA、加入者、または他の関係者)をタイプします:
* If and how the subject must prove possession of the companion
private key for the public key being registered, for example, a
digital signature in the certificate request message;(4)
* そして、登録されていて、対象が公開鍵のためにどう仲間秘密鍵の所有物を立証しなければならないか例えば、証明書要求メッセージにおけるaデジタル署名。(4)
* Identification and authentication requirements for organizational
identity of subscriber or participant (CA; RA; subscriber (in the
case of certificates issued to organizations or devices controlled
by an organization), or other participant), for example,
consulting the database of a service that identifies organizations
or inspecting an organization's articles of incorporation;
* 例えば、組織を特定するサービスのデータベースに相談するか、または組織の定款を点検する加入者か関係者(カリフォルニア; RA; 加入者(組織に発行された証明書か組織によって制御された装置の場合における)、または他の関係者)の組織的なアイデンティティのための識別と認証要件。
* Identification and authentication requirements for an individual
subscriber or a person acting on behalf of an organizational
subscriber or participant (CA, RA, in the case of certificates
issued to organizations or devices controlled by an organization,
the subscriber, or other participant),(5) including:
* 識別と個々の加入者か人のための組織的な加入者か関係者(カリフォルニア、組織に発行された証明書に関するケースか組織、加入者によって制御された装置のRA、または他の関係者)を代表して行動する認証要件、(5)の含み:
* Type of documentation and/or number of identification
credentials required;
* ドキュメンテーションのタイプ、そして/または、識別信任状の数が必要です。
* How a CA or RA authenticates the identity of the organization
or individual based on the documentation or credentials
provided;
* カリフォルニアかRAがどうドキュメンテーションか信任状に基づく組織か個人のアイデンティティを認証するかは提供されました。
* If the individual must personally present to the authenticating
CA or RA;
* 個人は個人的に認証カリフォルニアに存在していた状態でそうしなければならないか、そして、RA。
* How an individual as an organizational person is authenticated,
such as by reference to duly signed authorization documents or
a corporate identification badge.
* 組織的な人としての個人は正しくサインされた認可ドキュメントか法人の認識票の参照などについてどう認証されるか。
Chokhani, et al. Informational [Page 26] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [26ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
* List of subscriber information that is not verified (called "non-
verified subscriber information") during the initial registration;
* 新規登録の間に確かめられない(「非確かめられた加入者情報」と呼ばれます)加入者情報のリスト。
* Validation of authority involves a determination of whether a
person has specific rights, entitlements, or permissions,
including the permission to act on behalf of an organization to
obtain a certificate; and
* 権威の合法化は人には特定の権利、資格があること、または許容があるかどうかに関する決断にかかわります、証明書を入手するために組織を代表して行動する許可を含んでいて。 そして
* In the case of applications by a CA wishing to operate within, or
interoperate with, a PKI, this subcomponent contains the criteria
by which a PKI, CA, or policy authority determines whether or not
the CA is suitable for such operations or interoperation. Such
interoperation may include cross-certification, unilateral
certification, or other forms of interoperation.
* PKIと共に中で作動したいか、または共同利用したがっているカリフォルニアによるアプリケーションの場合では、このサブコンポーネントはPKI、カリフォルニアか方針権威がカリフォルニアがそのような操作かinteroperationに適しているかどうか決定する評価基準を含んでいます。 そのようなinteroperationはinteroperationの相互認証、一方的な証明、または他のフォームを含むかもしれません。
4.3.3. Identification and Authentication for Re-key Requests
4.3.3. 再主要な要求のための識別と認証
This subcomponent addresses the following elements for the identification and authentication procedures for re-key for each subject type (CA, RA, subscriber, and other participants):
このサブコンポーネントは識別のための以下の要素と各対象に、再主要なタイプ(カリフォルニア、RA、加入者、および他の関係者)のための認証手順を記述します:
* Identification and authentication requirements for routine re-key,
such as a re-key request that contains the new key and is signed
using the current valid key; and
* 再キーのように再主要なルーチンのための識別と認証要件は、それが新しいキーを含んでいて、現在の有効なキーを使用することでサインされるよう要求します。 そして
* Identification and authentication requirements for re-key after
certificate revocation. One example is the use of the same
process as the initial identity validation.
* 証明書の後再主要な取消しのための識別と認証要件。 1つの例は初期のアイデンティティ合法化と同じ過程の使用です。
4.3.4. Identification and Authentication for Revocation Requests
4.3.4. 取消し要求のための識別と認証
This subcomponent describes the identification and authentication procedures for a revocation request by each subject type (CA, RA, subscriber, and other participant). Examples include a revocation request digitally signed with the private key whose companion public key needs to be revoked, and a digitally signed request by the RA.
このサブコンポーネントは識別について説明します、そして、各対象による取消し要求のための認証手順は(カリフォルニア、RA、加入者、および他の関係者)をタイプします。 例は仲間公開鍵が取り消される必要がある秘密鍵をデジタルに契約された取消し要求、およびRAによるデジタルにサインされた要求を含んでいます。
4.4. Certificate Life-Cycle Operational Requirements
4.4. ライフサイクルの操作上の要件を証明してください。
This component is used to specify requirements imposed upon issuing CA, subject CAs, RAs, subscribers, or other participants with respect to the life-cycle of a certificate.
このコンポーネントは、証明書のライフサイクルに関してカリフォルニア、対象のCAs、RAs、加入者、または他の関係者を発行するのに課された要件を指定するのに使用されます。
Within each subcomponent, separate consideration may need to be given to subject CAs, RAs, subscribers, and other participants.
各サブコンポーネントの中では、別々の考慮は、CAs、RAs、加入者、および他の関係者をかけるために与えられている必要があるかもしれません。
Chokhani, et al. Informational [Page 27] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [27ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
4.4.1. Certificate Application
4.4.1. 証明書アプリケーション
This subcomponent is used to address the following requirements regarding subject certificate application:
このサブコンポーネントは対象の証明書アプリケーションに関する以下の要件を記述するのに使用されます:
* Who can submit a certificate application, such as a certificate
subject or the RA; and
* だれが証明書対象などの証明書塗布を提出できるか、そして、RA。 そして
* Enrollment process used by subjects to submit certificate
applications and responsibilities in connection with this process.
An example of this process is where the subject generates the key
pair and sends a certificate request to the RA. The RA validates
and signs the request and sends it to the CA. A CA or RA may have
the responsibility of establishing an enrollment process in order
to receive certificate applications. Likewise, certificate
applicants may have the responsibility of providing accurate
information on their certificate applications.
* これに関する対象によって使用される、証明書アプリケーションを提出する登録の過程と責任は処理されます。 この過程に関する例は対象が主要な組を発生させて、証明書要求をRAに送るところです。 RAは要求を有効にして、サインして、それをカリフォルニアに送ります。 カリフォルニアかRAには、証明書アプリケーションを受け取るために登録の過程を確立する責任があるかもしれません。 同様に、証明書応募者には、彼らの証明書アプリケーションに関する的確な情報を提供する責任があるかもしれません。
4.4.2. Certificate Application Processing
4.4.2. 証明書手続きの経緯
This subcomponent is used to describe the procedure for processing certificate applications. For example, the issuing CA and RA may perform identification and authentication procedures to validate the certificate application. Following such steps, the CA or RA will either approve or reject the certificate application, perhaps upon the application of certain criteria. Finally, this subcomponent sets a time limit during which a CA and/or RA must act on and process a certificate application.
このサブコンポーネントは、処理証明書アプリケーションのための手順について説明するのに使用されます。 例えば、発行カリフォルニアとRAは、証明書アプリケーションを有効にするために識別と認証手順を実行するかもしれません。 そのようなステップ、カリフォルニアまたはRAに従うのは、証明書申し込みを承認するか、または拒絶するでしょう、恐らくある評価基準の適用に関して。 最終的に、このサブコンポーネントはカリフォルニア、そして/または、RAが証明書アプリケーションに影響して、処理しなければならないタイムリミットを設定します。
4.4.3. Certificate Issuance
4.4.3. 証明書発行
This subcomponent is used to describe the following certificate issuance related elements:
このサブコンポーネントは以下の証明書発行関連する要素について説明するのに使用されます:
* Actions performed by the CA during the issuance of the
certificate, for example a procedure whereby the CA validates the
RA signature and RA authority and generates a certificate; and
* 動作は証明書の発行の間、カリフォルニアのそばで働きました、例えば、カリフォルニアがRA署名とRA権威を有効にして、証明書を作る手順。 そして
* Notification mechanisms, if any, used by the CA to notify the
subscriber of the issuance of the certificate; an example is a
procedure under which the CA e-mails the certificate to the
subscriber or the RA or e-mails information permitting the
subscriber to download the certificate from a web site.
* もしあれば証明書の発行について加入者に通知するのにカリフォルニアによって使用された通知メカニズム。 例はカリフォルニアが加入者かRAに証明書をメールするか、またはウェブサイトから加入者が証明書をダウンロードすることを許可する情報をメールする手順です。
Chokhani, et al. Informational [Page 28] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [28ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
4.4.4. Certificate Acceptance
4.4.4. 証明書承認
This subcomponent addresses the following:
このサブコンポーネントは以下を扱います:
* The conduct of an applicant that will be deemed to constitute
acceptance of the certificate. Such conduct may include
affirmative steps to indicate acceptance, actions implying
acceptance, or a failure to object to the certificate or its
content. For instance, acceptance may be deemed to occur if the
CA does not receive any notice from the subscriber within a
certain time period; a subscriber may send a signed message
accepting the certificate; or a subscriber may send a signed
message rejecting the certificate where the message includes the
reason for rejection and identifies the fields in the certificate
that are incorrect or incomplete.
* 証明書の承認を成立させると考えられる応募者の行為。 そのような行為は、承認、承認を含意する動作、または証明書かその内容に反対しないことを示すために肯定的なステップを含むかもしれません。 例えば、カリフォルニアが、ある期間以内に加入者から少しの通知も受け取らないなら、承認が起こると考えられるかもしれません。 加入者は署名しているメッセージに証明書を受け入れさせるかもしれません。 または、加入者は、署名しているメッセージにメッセージが不合格理由を含んでいる証明書を拒絶させるかもしれなくて、証明書の不正確であるか、または不完全な野原を特定します。
* Publication of the certificate by the CA. For example, the CA may
post the certificate to an X.500 or LDAP repository.
* カリフォルニアのそばの証明書の公表。 例えば、カリフォルニアはX.500かLDAP倉庫に証明書を掲示するかもしれません。
* Notification of certificate issuance by the CA to other entities.
As an example, the CA may send the certificate to the RA.
* 他の実体へのカリフォルニアによる証明書発行の通知。 例として、カリフォルニアは証明書をRAに送るかもしれません。
4.4.5. Key Pair and Certificate Usage
4.4.5. 主要な組と証明書用法
This subcomponent is used to describe the responsibilities relating to the use of keys and certificates, including:
このサブコンポーネントはキーと証明書、包含の使用に関連する責任について説明するのに使用されます:
* Subscriber responsibilities relating to use of the subscriber's
private key and certificate. For example, the subscriber may be
required to use a private key and certificate only for appropriate
applications as set forth in the CP and in consistency with
applicable certificate content (e.g., key usage field). Use of a
private key and certificate are subject to the terms of the
subscriber agreement, the use of a private key is permitted only
after the subscriber has accepted the corresponding certificate,
or the subscriber must discontinue use of the private key
following the expiration or revocation of the certificate.
* 加入者の秘密鍵と証明書の使用に関連する加入者責任。 例えば、加入者は適切なアプリケーションにだけCPと一貫性で詳しく説明されるように適切な証明書内容(例えば、主要な用法分野)で秘密鍵と証明書を使用しなければならないかもしれません。 秘密鍵と証明書の使用は加入者協定の期間を受けることがある、加入者が対応する証明書を受け入れた後にだけ秘密鍵の使用が受入れられるか、または証明書の満了か取消しに続いて、加入者が秘密鍵の使用を中止しなければなりません。
* Relying party responsibilities relating to the use of a
subscriber's public key and certificate. For instance, a relying
party may be obligated to rely on certificates only for
appropriate applications as set forth in the CP and in consistency
with applicable certificate content (e.g., key usage field),
successfully perform public key operations as a condition of
relying on a certificate, assume responsibility to check the
status of a certificate using one of the required or permitted
* 加入者の公開鍵と証明書の使用に関連する当てにしているパーティー責任。 例えば、パーティーがそうする信用がCPと一貫性で詳しく説明されるように適切な証明書内容(例えば、主要な用法分野)で適切なアプリケーションのためだけの証明書を当てにするのが義務付けられて、証明書を当てにするという条件として首尾よく公開鍵操作を実行してください、そして、必要であるか受入れにされるのの1つを使用することで証明書の状態をチェックする責任を負ってください。
Chokhani, et al. Informational [Page 29] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [29ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
mechanisms set forth in the CP/CPS (see Section 4.4.9 below), and
assent to the terms of the applicable relying party agreement as a
condition of relying on the certificate.
メカニズムは、CP/CPS(セクション4.4.9未満を見る)で旅に出て、証明書を当てにするという条件として適切な信用に関する諸条件にパーティー協定に同意します。
4.4.6. Certificate Renewal
4.4.6. 証明書更新
This subcomponent is used to describe the following elements related to certificate renewal. Certificate renewal means the issuance of a new certificate to the subscriber without changing the subscriber or other participant's public key or any other information in the certificate:
このサブコンポーネントは、証明書更新に関連する以下の要素について説明するのに使用されます。 加入者、他の関係者の公開鍵または証明書のいかなる他の情報も変えないで、証明書更新は新しい証明書の発行を加入者に意味します:
* Circumstances under which certificate renewal takes place, such as
where the certificate life has expired, but the policy permits the
same key pair to be reused;
* 証明書更新が証明書の寿命が期限が切れましたが、方針が同じキーを可能にするところのように行われる事情は再利用されるために対にされます。
* Who may request certificate renewal, for instance, the subscriber,
RA, or the CA may automatically renew an end-user subscriber
certificate;
* 例えば、だれが証明書更新を要求するかもしれないか、そして、加入者、RA、またはカリフォルニアが自動的にエンドユーザ加入者証明書を更新するかもしれません。
* A CA or RA's procedures to process renewal requests to issue the
new certificate, for example, the use of a token, such as a
password, to re-authenticate the subscriber, or procedures that
are the same as the initial certificate issuance;
* 例えば、新しい証明書にパスワードなどのトークンの使用を発行するという加入者を再認証するというプロセス更新要求か初期の証明書発行と同じ手順へのカリフォルニアかRAの手順。
* Notification of the new certificate to the subscriber;
* 加入者への新しい証明書の通知。
* Conduct constituting acceptance of the certificate;
* 証明書の承認を成立させて、伝導してください。
* Publication of the certificate by the CA; and
* カリフォルニアのそばの証明書の公表。 そして
* Notification of certificate issuance by the CA to other entities.
* 他の実体へのカリフォルニアによる証明書発行の通知。
4.4.7. Certificate Re-key
4.4.7. 証明書再キー
This subcomponent is used to describe the following elements related to a subscriber or other participant generating a new key pair and applying for the issuance of a new certificate that certifies the new public key:
このサブコンポーネントは新しい主要な組を生成して、新しい公開鍵を公認する新しい証明書の発行に申し込む加入者か他の関係者と関係がある以下の要素について説明するのに使用されます:
* Circumstances under which certificate re-key can or must take
place, such as after a certificate is revoked for reasons of key
compromise or after a certificate has expired and the usage period
of the key pair has also expired;
* 証明書再キーが行われることができなければならないか、または証明書が主要な感染の理由で取り消された後や証明書などの後のように行われなければならない事情は期限が切れました、そして、また、主要な組の用法の期間は期限が切れました。
* Who may request certificate re-key, for example, the subscriber;
* だれが要求証明書再キー、例えば、加入者がそうするかもしれないか。
Chokhani, et al. Informational [Page 30] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [30ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
* A CA or RA's procedures to process re-keying requests to issue the
new certificate, such as procedures that are the same as the
initial certificate issuance;
* 新しい証明書を発行するという初期の証明書発行と同じ手順などの要求を再合わせるカリフォルニアか処理するRAの手順。
* Notification of the new certificate to the subscriber;
* 加入者への新しい証明書の通知。
* Conduct constituting acceptance of the certificate;
* 証明書の承認を成立させて、伝導してください。
* Publication of the certificate by the CA; and
* カリフォルニアのそばの証明書の公表。 そして
* Notification of certificate issuance by the CA to other entities.
* 他の実体へのカリフォルニアによる証明書発行の通知。
4.4.8. Certificate Modification
4.4.8. 証明書変更
This subcomponent is used to describe the following elements related to the issuance of a new certificate (6) due to changes in the information in the certificate other than the subscriber public key:
このサブコンポーネントは加入者公開鍵以外の変化による証明書の情報の新しい証明書(6)の発行に関連する以下の要素について説明するのに使用されます:
* Circumstances under which certificate modification can take place,
such as name change, role change, reorganization resulting in a
change in the DN;
* 証明書変更が取ることができる事情は改名、役割の変化などのようにDNにおける変化をもたらす再編成を置きます。
* Who may request certificate modification, for instance,
subscribers, human resources personnel, or the RA;
* 例えば、だれが証明書変更を要求するかもしれないか、そして、加入者、人的資源人員、またはRA。
* A CA or RA's procedures to process modification requests to issue
the new certificate, such as procedures that are the same as the
initial certificate issuance;
* 新しい証明書を発行するという初期の証明書発行と同じ手順などの工程変更要求へのカリフォルニアかRAの手順。
* Notification of the new certificate to the subscriber;
* 加入者への新しい証明書の通知。
* Conduct constituting acceptance of the certificate;
* 証明書の承認を成立させて、伝導してください。
* Publication of the certificate by the CA; and
* カリフォルニアのそばの証明書の公表。 そして
* Notification of certificate issuance by the CA to other entities.
* 他の実体へのカリフォルニアによる証明書発行の通知。
4.4.9. Certificate Revocation and Suspension
4.4.9. 証明書取消しとサスペンション
This subcomponent addresses the following:
このサブコンポーネントは以下を扱います:
* Circumstances under which a certificate may be suspended and
circumstances under which it must be revoked, for instance, in
cases of subscriber employment termination, loss of cryptographic
token, or suspected compromise of the private key;
* 証明書が吊されるかもしれない事情と例えば加入者雇用終了の場合、暗号のトークンの損失、または秘密鍵の疑われた感染でそれを取り消さなければならない事情。
Chokhani, et al. Informational [Page 31] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [31ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
* Who can request the revocation of the participant's certificate,
for example, the subscriber, RA, or CA in the case of an end-user
subscriber certificate.
* エンドユーザ加入者証明書の場合で例えば、関係者の証明書、加入者、RA、またはカリフォルニアの取消しを要求できます。
* Procedures used for certificate revocation request, such as a
digitally signed message from the RA, a digitally signed message
from the subscriber, or a phone call from the RA;
* 証明書取消しに用いられた手順は、RAからのデジタルに署名しているメッセージのように加入者からデジタルに署名しているメッセージを要求するか、またはRAから電話を要求します。
* The grace period available to the subscriber, within which the
subscriber must make a revocation request;
* 加入者にとって、利用可能な据置期間そこでは、加入者が取消し要求をしなければなりません。
* The time within which CA must process the revocation request;
* カリフォルニアが取消し要求を処理しなければならない時。
* The mechanisms, if any, that a relying party may use or must use
in order to check the status of certificates on which they wish to
rely;
* もしあれば信用パーティーが彼らが当てにしたがっている証明書の状態をチェックするのに使用しなければならないかもしれないか、または使用しなければならないメカニズム。
* If a CRL mechanism is used, the issuance frequency;
* CRLメカニズムが使用されているなら、発行頻度です。
* If a CRL mechanism is used, maximum latency between the generation
of CRLs and posting of the CRLs to the repository (in other words,
the maximum amount of processing- and communication-related delays
in posting CRLs to the repository after the CRLs are generated);
* CRLメカニズムがCRLsの世代と倉庫へのCRLsの任命の間の中古の、そして、最大の潜在(言い換えれば、CRLsの後に倉庫にCRLsを掲示する最大の量の処理とコミュニケーション関連の遅れは発生している)であるなら。
* On-line revocation/status checking availability, for instance,
OCSP and a web site to which status inquiries can be submitted;
* 例えば有用性、OCSP、およびウェブサイトをどの資産調査にチェックするオンライン取消し/状態は提出できます。
* Requirements on relying parties to perform on-line
revocation/status checks;
* オンライン取消し/状態チェックを実行するという信用パーティーに関する要件。
* Other forms of revocation advertisements available;
* 他の形式の利用可能な取消し広告。
* Any variations of the above stipulations for which suspension or
revocation is the result of private key compromise (as opposed to
other reasons for suspension or revocation).
* どのサスペンションか取消しが秘密鍵の結果であるかのための上の約款のどんな変化も妥協します(サスペンションか取消しの他の理由と対照的に)。
* Circumstances under which a certificate may be suspended;
* 証明書が吊されるかもしれない事情。
* Who can request the suspension of a certificate, for example, the
subscriber, human resources personnel, a supervisor of the
subscriber, or the RA in the case of an end-user subscriber
certificate;
* 例えば、加入者、人的資源人員、加入者の監督、またはエンドユーザ加入者の場合におけるRAが、だれが証明書のサスペンションを要求できるかと証明します。
* Procedures to request certificate suspension, such as a digitally
signed message from the subscriber or RA, or a phone call from the
RA; and
* 要求する手順はサスペンションを証明します、加入者、RA、またはRAからの電話からのデジタルに署名しているメッセージのように。 そして
* How long the suspension may last.
* どれくらい長い間、サスペンションはもつかもしれませんか?
Chokhani, et al. Informational [Page 32] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [32ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
4.4.10. Certificate Status Services
4.4.10. 証明書状態サービス
This subcomponent addresses the certificate status checking services available to the relying parties, including:
このサブコンポーネントは、証明書が信用パーティー、包含に利用可能なサービスをチェックする状態であると扱います:
* The operational characteristics of certificate status checking
services;
* サービスをチェックする証明書状態の操作上の特性。
* The availability of such services, and any applicable policies on
unavailability; and
* そのようなサービスの有用性、および使用不能に関するどんな適切な方針も。 そして
* Any optional features of such services.
* そのようなサービスに関するどんなオプション機能。
4.4.11. End of Subscription
4.4.11. 購読の終わり
This subcomponent addresses procedures used by the subscriber to end subscription to the CA services, including:
このサブコンポーネントはカリフォルニアのサービス、包含の購読を終わらせるのに加入者によって用いられた手順を扱います:
* The revocation of certificates at the end of subscription (which
may differ, depending on whether the end of subscription was due
to the expiration of the certificate or termination of the
service).
* 購読(購読の終わりが証明書の満了かサービスの終了のためであったかによって、異なるかもしれない)の終わりの証明書の取消し。
4.4.12. Key Escrow and Recovery
4.4.12. キーエスクローと回復
This subcomponent contains the following elements to identify the policies and practices relating to the escrowing, and/or recovery of private keys where private key escrow services are available (through the CA or other trusted third parties):
秘密鍵エスクローサービスが利用可能であるところに(カリフォルニアか他の信頼できる第三者機関による)このサブコンポーネントは方針を特定する以下の要素とescrowingに関連する習慣、そして/または、秘密鍵の回復を含んでいます:
* Identification of the document containing private key escrow and
recovery policies and practices or a listing of such policies and
practices; and
* 秘密鍵エスクロー、回復方針、および習慣を含むドキュメントかそのような方針と習慣のリストの識別。 そして
* Identification of the document containing session key
encapsulation and recovery policies and practices or a listing of
such policies and practices.
* セッションの主要なカプセル化、回復方針、および習慣を含むドキュメントかそのような方針と習慣のリストの識別。
4.5. Management, Operational, and Physical Controls
4.5. 管理、操作上的、そして、物理的なコントロール
This component describes non-technical security controls (that is, physical, procedural, and personnel controls) used by the issuing CA to securely perform the functions of key generation, subject authentication, certificate issuance, certificate revocation, auditing, and archiving.
このコンポーネントはしっかりとキー生成、対象の認証、証明書発行、証明書取消し、監査、および格納の機能を実行するのに発行カリフォルニアによって使用された非技術系のセキュリティコントロール(それはそうです、物理的です、手続き上であり、人員はコントロールである)について説明します。
Chokhani, et al. Informational [Page 33] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [33ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
This component can also be used to define non-technical security controls on repositories, subject CAs, RAs, subscribers, and other participants. The non-technical security controls for the subject CAs, RAs, subscribers, and other participants could be the same, similar, or very different.
また、倉庫、対象のCAs、RAs、加入者、および他の関係者の上で非技術系のセキュリティコントロールを定義するのにこのコンポーネントを使用できます。 対象のCAs、RAs、加入者、および他の関係者のための非技術系のセキュリティコントロールは、同じであるか、同様であるか、または非常に異なっているかもしれません。
These non-technical security controls are critical to trusting the certificates since lack of security may compromise CA operations resulting for example, in the creation of certificates or CRLs with erroneous information or compromising the CA private key.
これらの非技術系のセキュリティコントロールはセキュリティの不足が、カリフォルニアが例えば結果として生じる操作であると感染するかもしれなくて、証明書を信じるのに重要です、間違った情報かカリフォルニア秘密鍵に感染する証明書かCRLsの作成で。
Within each subcomponent, separate consideration will, in general, need to be given to each entity type, that is, the issuing CA, repository, subject CAs, RAs, subscribers, and other participants.
一般に、各サブコンポーネントの中では、別々の考慮は、それぞれの実体タイプ、すなわち、発行カリフォルニア、倉庫、対象のCAs、RAs、加入者、および他の関係者に与えられている必要があるでしょう。
4.5.1. Physical Security Controls
4.5.1. 物理的なセキュリティコントロール
In this subcomponent, the physical controls on the facility housing the entity systems are described. Topics addressed may include:
このサブコンポーネントでは、実体システムを収容する施設における物的管理は説明されます。 扱われた話題は以下を含むかもしれません。
* Site location and construction, such as the construction
requirements for high-security zones and the use of locked rooms,
cages, safes, and cabinets;
* 位置と工事が高いセキュリティーゾーンのための工事要件や固定部屋の使用のようにかごに入れるサイト、金庫、およびキャビネット。
* Physical access, i.e., mechanisms to control access from one area
of the facility to another or access into high-security zones,
such as locating CA operations in a secure computer room monitored
by guards or security alarms and requiring movement from zone to
zone to be accomplished using a token, biometric readers, and/or
access control lists;
* 物理的なアクセス、すなわち、制御するメカニズムは別のものへの施設か安全なコンピュータでカリフォルニアの操作の場所を見つけなどなどの高いセキュリティーゾーンへのアクセスの1つの領域からトークン、バイオメトリックな読者、そして/または、アクセスコントロールリストを使用することで番人か警報機によってモニターされて、ゾーンからゾーンまでの動きが実行されるのを必要とする余地にアクセスします。
* Power and air conditioning;
* パワーと空調。
* Water exposures;
* 暴露に水をまいてください。
* Fire prevention and protection;
* 防火と保護。
* Media storage, for example, requiring the storage of backup media
in a separate location that is physically secure and protected
from fire and water damage;
* 炎と水害から例えば、肉体的に安全な別々の位置でのバックアップメディアのストレージを必要として、保護されたメディアストレージ。
* Waste disposal; and
* 処分を浪費してください。 そして
* Off-site backup.
* オフサイトバックアップ。
Chokhani, et al. Informational [Page 34] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [34ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
4.5.2. Procedural Controls
4.5.2. 手続き上のコントロール
In this subcomponent, requirements for recognizing trusted roles are described, together with the responsibilities for each role. Examples of trusted roles include system administrators, security officers, and system auditors.
このサブコンポーネントでは、信じられた役割を認識するための要件は各役割への責任と共に説明されます。 信じられた役割に関する例はシステム管理者、セキュリティ担当責任者、およびシステム監査役を含んでいます。
For each task identified, the number of individuals required to perform the task (n out m rule) should be stated for each role. Identification and authentication requirements for each role may also be defined.
特定された各タスクに関しては、タスク(n出ているm規則)を実行するのに必要である個体数は各役割のために述べられているべきです。 また、各役割のための識別と認証要件は定義されるかもしれません。
This component also includes the separation of duties in terms of the roles that cannot be performed by the same individuals.
また、このコンポーネントは同じ個人が実行できない役割に関して義務の分離を含んでいます。
4.5.3. Personnel Security Controls
4.5.3. 人的安全保護コントロール
This subcomponent addresses the following:
このサブコンポーネントは以下を扱います:
* Qualifications, experience, and clearances that personnel must
have as a condition of filling trusted roles or other important
roles. Examples include credentials, job experiences, and
official government clearances that candidates for these positions
must have before being hired;
* 人員が信じられた役割か他の重要な役割をいっぱいにするという条件として持たなければならない資格、経験、およびクリアランス。 例は雇われる前にこれらの位置の候補が持たなければならない資格証明書、職務経験、および公式の政府の許可を含んでいます。
* Background checks and clearance procedures that are required in
connection with the hiring of personnel filling trusted roles or
perhaps other important roles; such roles may require a check of
their criminal records, references, and additional clearances that
a participant undertakes after a decision has been made to hire a
particular person;
* 素性調査とクリアランス手順が信じられた役割か恐らく他の重要な役割をいっぱいにしている人員の雇用に関して必要です。 特定の人を雇うのを決定をした後にそのような役割は関係者が引き受けるそれらの前科、参照、および追加クリアランスのチェックを必要とするかもしれません。
* Training requirements and training procedures for each role
following the hiring of personnel;
* 人員の雇用に続く各役割のためのトレーニング要件と訓練方法。
* Any retraining period and retraining procedures for each role
after completion of initial training;
* 初歩的な訓練の完成の後の各役割のためのどんな再教育の期間と再教育手順も。
* Frequency and sequence for job rotation among various roles;
* 様々な役割の中のジョブローテーションのための頻度と系列。
* Sanctions against personnel for unauthorized actions, unauthorized
use of authority, and unauthorized use of entity systems for the
purpose of imposing accountability on a participant's personnel;
* 関係者の人員に責任を課す目的の権限のない動作のための人員に対する制裁、権威の無断使用、および実体システムの権限のない使用。
* Controls on personnel that are independent contractors rather than
employees of the entity; examples include:
* 実体の従業員よりむしろ請負人である人員におけるコントロール。 例は:
- Bonding requirements on contract personnel;
- 契約人員に要件を接着します。
Chokhani, et al. Informational [Page 35] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [35ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
- Contractual requirements including indemnification for damages
due to the actions of the contractor personnel;
- 契約者人員の動作による損害賠償のための保障を含む契約要求事項。
- Auditing and monitoring of contractor personnel; and
- 契約者に人員を監査して、モニターします。 そして
- Other controls on contracting personnel.
- 契約人員における他のコントロール。
* Documentation to be supplied to personnel during initial training,
retraining, or otherwise.
* 初歩的な訓練、再教育の間、人員に提供しているか、またはそうでないドキュメンテーション。
4.5.4. Audit Logging Procedures
4.5.4. 監査伐採手順
This subcomponent is used to describe event logging and audit systems, implemented for the purpose of maintaining a secure environment. Elements include the following:
このサブコンポーネントは、安全な環境を維持する目的のために実装されたイベント伐採と監査制度について説明するのに使用されます。 要素は以下を含んでいます:
* Types of events recorded, such as certificate lifecycle
operations, attempts to access the system, and requests made to
the system;
* イベントのタイプは証明書lifecycle操作などのようにシステムにアクセスする試み、およびシステムにされた要求を記録しました。
* Frequency with which audit logs are processed or archived, for
example, weekly, following an alarm or anomalous event, or when
ever the audit log is n% full;
* 監査ログがn%完全であるいったいいつにアラームか変則的なイベントに従うか例えば、監査ログが毎週処理されるか、または格納される頻度
* Period for which audit logs are kept;
* どの監査ログが保たれるかために以上。
* Protection of audit logs:
* 監査ログの保護:
- Who can view audit logs, for example only the audit
administrator;
- だれが視点監査ログ、例えば、監査管理者しかそうすることができないか。
- Protection against modification of audit logs, for instance a
requirement that no one may modify or delete the audit records
or that only an audit administrator may delete an audit file as
part of rotating the audit file; and
- 監査ログの変更に対する保護、例えば、だれも監査記録を変更しないか、削除しないかもしれないか、または監査管理者だけが監査ファイルを回転させる一部として監査ファイルを削除するかもしれないという要件。 そして
- Protection against deletion of audit logs.
- 監査ログの削除に対する保護。
* Audit log back up procedures;
* ログ後部を手順に監査してください。
* Whether the audit log accumulation system is internal or external
to the entity;
* 監査ログアキュミュレーション方式が実体に内部である、または外部であることにかかわらず。
* Whether the subject who caused an audit event to occur is notified
of the audit action; and
* 監査イベントが起こることを引き起こした対象が監査動作について通知されるか否かに関係なく。 そして
Chokhani, et al. Informational [Page 36] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [36ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
* Vulnerability assessments, for example, where audit data is run
through a tool that identifies potential attempts to breach the
security of the system.
* 弱点査定、例えば、監査データがざっと調べられるところでは、可能性を特定するツールはシステムのセキュリティを破るのを試みます。
4.5.5. Records Archival
4.5.5. 記録保管所で、記録します。
This subcomponent is used to describe general records archival (or records retention) policies, including the following:
このサブコンポーネントは使用されて、一般について説明するのが記録保管所(または、記録保有)の方針を記録して、包含が以下であるということです:
* Types of records that are archived, for example, all audit data,
certificate application information, and documentation supporting
certificate applications;
* 例えば格納される記録のタイプは皆、データ、証明書アプリケーション情報、および証明書アプリケーションをサポートするドキュメンテーションを監査します。
* Retention period for an archive;
* アーカイブのための保有の期間。
* Protection of an archive:
* アーカイブの保護:
- Who can view the archive, for example, a requirement that only
the audit administrator may view the archive;
- だれがアーカイブ、監査管理者だけがアーカイブを見るかもしれないという例えば要件を見ることができるか。
- Protection against modification of the archive, such as
securely storing the data on a write once medium;
- いったん中型であると、アーカイブのしっかりとaに関するデータを保存などなどの変更に対する保護は書きます。
- Protection against deletion of the archive;
- アーカイブの削除に対する保護。
- Protection against the deterioration of the media on which the
archive is stored, such as a requirement for data to be
migrated periodically to fresh media; and
- 保護、データが定期的にわたられるという要件のようにアーカイブがどれであるかに関して新たにメディアの劣化に対して保存されたメディア、。 そして
- Protection against obsolescence of hardware, operating systems,
and other software, by, for example, retaining as part of the
archive the hardware, operating systems, and/or other software
in order to permit access to and use of archived records over
time.
- ハードウェア、オペレーティングシステム、および他のソフトウェアの老廃、例えば、時間がたつにつれて格納された記録のアクセスと使用を可能にするためにアーカイブの一部としてハードウェア、オペレーティングシステム、そして/または、他のソフトウェアを保有するのによる保護。
* Archive backup procedures;
* バックアップ手順を格納してください。
* Requirements for time-stamping of records;
* 記録の時間の刻印のための要件。
* Whether the archive collection system is internal or external; and
* アーカイブ収集システムが内部である、または外部であることにかかわらず。 そして
* Procedures to obtain and verify archive information, such as a
requirement that two separate copies of the archive data be kept
under the control of two persons, and that the two copies be
compared in order to ensure that the archive information is
accurate.
* 得て、確かめる手順は情報を格納します、アーカイブデータの別々の写し2部が2人の人々のコントロールの下で取っておかれて、コピー2部がアーカイブ情報が確実に正確になるようにするために比較されるという要件のように。
Chokhani, et al. Informational [Page 37] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [37ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
4.5.6. Key Changeover
4.5.6. 主要な転換
This subcomponent describes the procedures to provide a new public key to a CA's users following a re-key by the CA. These procedures may be the same as the procedure for providing the current key. Also, the new key may be certified in a certificate signed using the old key.
このサブコンポーネントは、カリフォルニアのそばで再キーに続いて、新しい公開鍵をCAのユーザに提供するために手順について説明します。 これらの手順は現在のキーを提供するための手順と同じであるかもしれません。 また、新しいキーは古いキーを使用することで署名される証明書で公認されるかもしれません。
4.5.7. Compromise and Disaster Recovery
4.5.7. 感染と災害復旧
This subcomponent describes requirements relating to notification and recovery procedures in the event of compromise or disaster. Each of the following may need to be addressed separately:
このサブコンポーネントは感染か災害の場合、通知とリカバリ手順に関連する要件について説明します。 それぞれの以下は、別々に扱われる必要があるかもしれません:
* Identification or listing of the applicable incident and
compromise reporting and handling procedures.
* 適切なインシデント、感染報告、および取り扱い手順の識別かリスト。
* The recovery procedures used if computing resources, software,
and/or data are corrupted or suspected to be corrupted. These
procedures describe how a secure environment is re-established,
which certificates are revoked, whether the entity key is revoked,
how the new entity public key is provided to the users, and how
the subjects are re-certified.
* リソース、ソフトウェア、そして/または、データを計算するなら使用されるリカバリ手順は、崩壊するように崩壊するか、または疑われます。 これらの手順は、安全な環境をどのように復職させるか、そして、実体キーが取り消されるか否かに関係なく、どの証明書を取り消すか、そして、どのように新しい実体公開鍵をユーザに提供するか、そして、対象がどのように再公認しているかを説明します。
* The recovery procedures used if the entity key is compromised.
These procedures describe how a secure environment is re-
established, how the new entity public key is provided to the
users, and how the subjects are re-certified.
* 実体キーが感染されるなら使用されるリカバリ手順。 これらの手順は、どのように安全な環境を再確立するか、そして、どのように新しい実体公開鍵をユーザに提供するか、そして、対象がどのように再公認しているかを説明します。
* The entity's capabilities to ensure business continuity following
a natural or other disaster. Such capabilities may include the
availability of a remote hot-site at which operations may be
recovered. They may also include procedures for securing its
facility during the period of time following a natural or other
disaster and before a secure environment is re-established, either
at the original site or at a remote site. For example, procedures
to protect against theft of sensitive materials from an
earthquake-damaged site.
* 自然であるか他の災害に続いて、ビジネス継続性を確実にする実体の能力。 そのような能力は操作が回復されるかもしれない遠く離れた熱いサイトの有用性を含むかもしれません。 また、彼らは自然であるか他の災害に続く期間、安全な環境が元のサイトにおいて、または、リモートサイトで復職する前に施設を保証するための手順を含むかもしれません。 例えば、地震で破損しているサイトから感光材料の窃盗から守る手順。
4.5.8. CA or RA Termination
4.5.8. カリフォルニアかRA終了
This subcomponent describes requirements relating to procedures for termination and termination notification of a CA or RA, including the identity of the custodian of CA and RA archival records.
このサブコンポーネントはカリフォルニアかRAの終了と終了通知のための手順に関連する要件について説明します、カリフォルニアとRA履歴の管理人のアイデンティティを含んでいて。
Chokhani, et al. Informational [Page 38] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [38ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
4.6. Technical Security Controls
4.6. 技術的なセキュリティコントロール
This component is used to define the security measures taken by the issuing CA to protect its cryptographic keys and activation data (e.g., PINs, passwords, or manually-held key shares). This component may also be used to impose constraints on repositories, subject CAs, subscribers, and other participants to protect their private keys, activation data for their private keys, and critical security parameters. Secure key management is critical to ensure that all secret and private keys and activation data are protected and used only by authorized personnel.
このコンポーネントは、その暗号化キーと起動データ(例えば、暗証番号、パスワード、または手動で保持された主要なシェア)を保護するために発行カリフォルニアによって取られた安全策を定義するのに使用されます。 また、このコンポーネントは、それらの秘密鍵のために彼らの秘密鍵、起動データを保護するという倉庫、対象のCAs、加入者、および他の関係者における規制、およびきわどいセキュリティパラメタを課すのに使用されるかもしれません。 安全なかぎ管理は、すべての秘密、秘密鍵、および起動データが単に任命された者によって保護されて、使用されるのを保証するために重要です。
This component also describes other technical security controls used by the issuing CA to perform securely the functions of key generation, user authentication, certificate registration, certificate revocation, auditing, and archiving. Technical controls include life-cycle security controls (including software development environment security, trusted software development methodology) and operational security controls.
また、このコンポーネントはしっかりとキー生成、ユーザー認証、証明書登録、証明書取消し、監査、および格納の機能を実行するのに発行カリフォルニアによって使用された他の技術的なセキュリティコントロールについて説明します。 技術制御はライフサイクルセキュリティコントロール(ソフトウェア開発環境セキュリティ、信じられたソフトウェア開発方法論を含んでいる)と操作上のセキュリティコントロールを含んでいます。
This component can also be used to define other technical security controls on repositories, subject CAs, RAs, subscribers, and other participants.
また、倉庫、対象のCAs、RAs、加入者、および他の関係者の上で他の技術的なセキュリティコントロールを定義するのにこのコンポーネントを使用できます。
4.6.1. Key Pair Generation and Installation
4.6.1. 主要な組世代とインストール
Key pair generation and installation need to be considered for the issuing CA, repositories, subject CAs, RAs, and subscribers. For each of these types of entities, the following questions potentially need to be answered:
主要な組世代とインストールは、発行カリフォルニア、倉庫、対象のCAs、RAs、および加入者のために考えられる必要があります。 それぞれのこれらのタイプの実体のために、以下の質問は、潜在的に答えられる必要があります:
1. Who generates the entity public, private key pair? Possibilities
include the subscriber, RA, or CA. Also, how is the key
generation performed? Is the key generation performed by hardware
or software?
1. だれが公立の実体秘密鍵組を生成しますか? ポシビリティーズは加入者、RA、またはカリフォルニアを含んでいます。 また、キー生成はどのように実行されますか? キーは、ハードウェア的に実行された世代かそれともソフトウェアですか?
2. How is the private key provided securely to the entity?
Possibilities include a situation where the entity has generated
it and therefore already has it, handing the entity the private
key physically, mailing a token containing the private key
securely, or delivering it in an SSL session.
2. どのようにしっかりと秘密鍵を実体に提供しますか? ポシビリティーズは実体がそれを生成して、したがって既にそれを持っている状況を含んでいます、物理的に実体に秘密鍵を手渡して、しっかりと秘密鍵を含んでいるか、またはSSLセッションにそれを提供しながらトークンを郵送して。
3. How is the entity's public key provided securely to the
certification authority? Some possibilities are in an online SSL
session or in a message signed by the RA.
3. どのようにしっかりと実体の公開鍵を証明権威に提供しますか? いくつかの可能性がオンラインSSLセッションかRAによって署名されたメッセージにあります。
Chokhani, et al. Informational [Page 39] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [39ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
4. In the case of issuing CAs, how is the CA's public key provided
securely to potential relying parties? Possibilities include
handing the public key to the relying party securely in person,
physically mailing a copy securely to the relying party, or
delivering it in a SSL session.
4. CAsを発行する場合では、しっかりと潜在的信用に提供されたCAの公開鍵はどのようにパーティーですか? ポシビリティーズは、しっかりと自分で信用パーティーに公開鍵を手渡すのを含んでいます、物理的にしっかりと信用パーティーにコピーを郵送するか、またはSSLセッションにそれを提供して。
5. What are the key sizes? Examples include a 1,024 bit RSA modulus
and a 1,024 bit DSA large prime.
5. 主要なサイズはどのくらいですか? 例は1,024ビットのRSA係数と1,024ビットのDSAの大きい第1を含んでいます。
6. Who generates the public key parameters, and is the quality of the
parameters checked during key generation?
6. だれが、公開鍵がパラメタであると生成するか、そして、パラメタの品質はキー生成の間、チェックされますか?
7. For what purposes may the key be used, or for what purposes should
usage of the key be restricted? For X.509 certificates, these
purposes should map to the key usage flags in X.509 Version 3
certificates.
7. どんな目的のために、キーが使用されるかもしれないか、そして、またはキーの使用法はどんな目的のために制限されるべきですか? X.509証明書に関しては、これらの目的はX.509バージョン3証明書の旗を主要な用法に配置するべきです。
4.6.2. Private Key Protection and Cryptographic Module Engineering
Controls
4.6.2. 秘密鍵保護と暗号のモジュール工学コントロール
Requirements for private key protection and cryptographic modules need to be considered for the issuing CA, repositories, subject CAs, RAs, and subscribers. For each of these types of entities, the following questions potentially need to be answered:
秘密鍵保護のための要件と暗号のモジュールは、発行カリフォルニア、倉庫、対象のCAs、RAs、および加入者のために考えられる必要があります。 それぞれのこれらのタイプの実体のために、以下の質問は、潜在的に答えられる必要があります:
1. What standards, if any, are required for the cryptographic module
used to generate the keys? A cryptographic module can be
composed of hardware, software, firmware, or any combination of
them. For example, are the keys certified by the infrastructure
required to be generated using modules compliant with the US FIPS
140-1? If so, what is the required FIPS 140-1 level of the
module? Are there any other engineering or other controls
relating to a cryptographic module, such as the identification of
the cryptographic module boundary, input/output, roles and
services, finite state machine, physical security, software
security, operating system security, algorithm compliance,
electromagnetic compatibility, and self tests.
1. もしあればどんな規格がキーを生成するのにおいて中古の暗号のモジュールに必要ですか? それらのハードウェア、ソフトウェア、ファームウェア、またはどんな組み合わせでも暗号のモジュールを構成できます。 例えば、キーはUS FIPS140-1に伴う対応することのモジュールを使用することで生成されるのに必要であるインフラストラクチャによって公認されますか? そうだとすれば、モジュールの必要なFIPS140-1レベルは何ですか? 暗号のモジュール限界、入力/出力、役割、サービス、有限状態機械、物理的なセキュリティ、ソフトウェアセキュリティ、オペレーティングシステムセキュリティ、アルゴリズムコンプライアンス、電磁環境適合性、および自己診断の識別などの暗号のモジュールに関連する工学かいかなる他のも他のコントロールがありますか?
2. Is the private key under n out of m multi-person control?(7) If
yes, provide n and m (two person control is a special case of n
out of m, where n = m = 2)?
2. mからのnの下の秘密鍵はマルチ人のコントロールですか?(7) はいなら、nとmを提供してください(2人のコントロールはmからのnがmと等しいnの特別なケース=2です)--
3. Is the private key escrowed?(8) If so, who is the escrow agent,
what form is the key escrowed in (examples include plaintext,
encrypted, split key), and what are the security controls on the
escrow system?
3. 秘密鍵はescrowedされますか?(8) そうだとすれば、条件付き証書受託者はだれです、そして、キーはどんなフォームでescrowedされるか、そして、(例が平文を含んでいます、暗号化された分裂キー)第三者預託システムの上のセキュリティコントロールは何ですか?
Chokhani, et al. Informational [Page 40] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [40ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
4. Is the private key backed up? If so, who is the backup agent,
what form is the key backed up in (examples include plaintext,
encrypted, split key), and what are the security controls on the
backup system?
4. 秘密鍵は支援されますか? そうだとすれば、バックアップエージェントはだれです、そして、(平文を含んで、暗号化された例、分裂キー)で支援されたキーはどんなフォームであるか、そして、バックアップ・システムの上のセキュリティコントロールは何ですか?
5. Is the private key archived? If so, who is the archival agent,
what form is the key archived in (examples include plaintext,
encrypted, split key), and what are the security controls on the
archival system?
5. 秘密鍵は格納されますか? そうだとすれば、記録保管所のエージェントはだれです、そして、キーはどんなフォームで格納されるか、そして、(例が平文を含んでいます、暗号化された分裂キー)記録保管所のシステムの上のセキュリティコントロールは何ですか?
6. Under what circumstances, if any, can a private key be
transferred into or from a cryptographic module? Who is
permitted to perform such a transfer operation? In what form is
the private key during the transfer (i.e., plaintext, encrypted,
or split key)?
6. もしあればどんな状況で、モジュールの中、または、暗号のモジュールから秘密鍵を移すことができますか? だれがそのような転送操作を実行することが許可されていますか? どんなフォームで、秘密鍵が転送(すなわち、暗号化された平文か分裂キー)の間、ありますか?
7. How is the private key stored in the module (i.e., plaintext,
encrypted, or split key)?
7. モジュール(すなわち、暗号化された平文か分裂キー)で秘密鍵はどのように保存されますか?
8. Who can activate (use) the private key? What actions must be
performed to activate the private key (e.g., login, power on,
supply PIN, insert token/key, automatic, etc.)? Once the key is
activated, is the key active for an indefinite period, active for
one time, or active for a defined time period?
8. だれが秘密鍵を活性化できますか?(使用します) 秘密鍵を活性化するためにどんな動作を実行しなければなりませんか?(例えば、ログインしてください、そして、電源を入れてください、そして、差し込みトークン/主要で、自動である暗証番号などを供給してください) キーがいったん活性になると、キーは、アクティブですか無期限の間、アクティブですかあるとき、または定義された期間、アクティブですか?
9. Who can deactivate the private key and how? Examples of methods
of deactivating private keys include logging out, turning the
power off, removing the token/key, automatic deactivation, and
time expiration.
9. だれが秘密鍵を非活性化できるか、そして、どのようにですか? 秘密鍵を非活性化するメソッドに関する例は、ログアウトするのを含んでいます、電源を切って、トークン/主要で、自動である非活性化、および時間満了を取り除いて。
10. Who can destroy the private key and how? Examples of methods of
destroying private keys include token surrender, token
destruction, and overwriting the key.
10. だれが秘密鍵を破壊できるか、そして、どのようにですか? 秘密鍵を破壊するメソッドに関する例は、トークン降伏と、トークン破壊と、キーを上書きするのを含んでいます。
11. Provide the capabilities of the cryptographic module in the
following areas: identification of the cryptographic module
boundary, input/output, roles and services, finite state machine,
physical security, software security, operating system security,
algorithm compliance, electromagnetic compatibility, and self
tests. Capability may be expressed through reference to
compliance with a standard such as U.S. FIPS 140-1, associated
level, and rating.
11. 暗号のモジュールの能力を以下の領域に提供してください: 暗号のモジュール限界、入力/出力、役割、サービス、有限状態機械、物理的なセキュリティ、ソフトウェアセキュリティ、オペレーティングシステムセキュリティ、アルゴリズムコンプライアンス、電磁環境適合性、および自己診断の識別。 能力はU.S. FIPS140-1や、関連レベルや、格付けなどの規格へのコンプライアンスの参照で言い表されるかもしれません。
Chokhani, et al. Informational [Page 41] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [41ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
4.6.3. Other Aspects of Key Pair Management
4.6.3. 主要な組管理の他の局面
Other aspects of key management need to be considered for the issuing CA, repositories, subject CAs, RAs, subscribers, and other participants. For each of these types of entities, the following questions potentially need to be answered:
かぎ管理の他の局面は、発行カリフォルニア、倉庫、対象のCAs、RAs、加入者、および他の関係者のために考えられる必要があります。 それぞれのこれらのタイプの実体のために、以下の質問は、潜在的に答えられる必要があります:
1. Is the public key archived? If so, who is the archival agent and
what are the security controls on the archival system? Also,
what software and hardware need to be preserved as part of the
archive to permit use of the public key over time? Note: this
subcomponent is not limited to requiring or describing the use of
digital signatures with archival data, but rather can address
integrity controls other than digital signatures when an archive
requires tamper protection. Digital signatures do not provide
tamper protection or protect the integrity of data; they merely
verify data integrity. Moreover, the archival period may be
greater than the cryptanalysis period for the public key needed
to verify any digital signature applied to archival data.
1. 公開鍵は格納されますか? そうだとすれば、記録保管所のエージェントはだれです、そして、記録保管所のシステムの上のセキュリティコントロールは何ですか? また、どんなソフトウェアとハードウェアが、時間がたつにつれて公開鍵の使用を可能にするためにアーカイブの一部として保存される必要がありますか? 以下に注意してください。 このサブコンポーネントは、保管データでデジタル署名の使用について必要である、または説明するのに制限されませんが、アーカイブがタンパー保護を必要とするとき、デジタル署名を除いて、保全がコントロールであるとむしろ扱うことができます。 デジタル署名は、タンパー保護を提供もしませんし、データの完全性を保護もしません。 彼らは単にデータ保全を確かめます。 そのうえ、公開鍵のための暗号文解読術の期間が、保管データに適用されたどんなデジタル署名についても確かめる必要があったより記録保管所の期間は長いかもしれません。
2. What is the operational period of the certificates issued to the
subscriber. What are the usage periods, or active lifetimes, for
the subscriber's key pair?
2. 加入者に発行された証明書の操作上の期間であること。 用法の期間、またはアクティブな寿命が加入者の主要な組のための何ですか?
4.6.4. Activation Data
4.6.4. 起動データ
Activation data refers to data values other than whole private keys that are required to operate private keys or cryptographic modules containing private keys, such as a PIN, passphrase, or portions of a private key used in a key-splitting scheme. Protection of activation data prevents unauthorized use of the private key, and potentially needs to be considered for the issuing CA, subject CAs, RAs, and subscribers. Such consideration potentially needs to address the entire life-cycle of the activation data from generation through archival and destruction. For each of the entity types (issuing CA, repository, subject CA, RA, subscriber, and other participants), all of the questions listed in 4.6.1 through 4.6.3 potentially need to be answered with respect to activation data rather than with respect to keys.
起動データは秘密鍵を操作するのに必要である全体の秘密鍵か秘密鍵を含む暗号のモジュール以外のデータ値について言及します、キーが分かれる体系に使用される秘密鍵の暗証番号、パスフレーズ、または部分などのように。 起動データの保護は、秘密鍵の無断使用を防いで、潜在的に発行カリフォルニア、対象のCAs、RAs、および加入者のために考えられる必要があります。 そのような考慮は、潜在的に記録保管所を通る世代と破壊から起動データの全体のライフサイクルを扱う必要があります。 (カリフォルニア、倉庫、対象のカリフォルニア、RA、加入者、および他の関係者を発行します)、質問のすべてが記載した実体タイプ各人、4.6、.1、通じて、4.6、.3、潜在的に、キーに関してというよりむしろ起動データに関して答えられるのが必要です。
4.6.5. Computer Security Controls
4.6.5. コンピュータセキュリティコントロール
This subcomponent is used to describe computer security controls such as: use of the trusted computing base concept, discretionary access control, labels, mandatory access controls, object re-use, audit, identification and authentication, trusted path, security testing, and penetration testing. Product assurance may also be addressed.
このサブコンポーネントは、以下などのコンピュータセキュリティコントロールについて説明するのに使用されます。 信頼できるコンピューティングベース概念の使用、任意のアクセスコントロール(ラベル、コントロール(オブジェクト再使用)が監査する義務的なアクセス、識別、および認証)は経路、セキュリティテスト、および侵入テストを信じました。 また、製品保証は扱われるかもしれません。
Chokhani, et al. Informational [Page 42] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [42ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
A computer security rating for computer systems may be required. The rating could be based, for example, on the Trusted System Evaluation Criteria (TCSEC), Canadian Trusted Products Evaluation Criteria, European Information Technology Security Evaluation Criteria (ITSEC), or the Common Criteria for Information Technology Security Evaluation, ISO/IEC 15408:1999. This subcomponent can also address requirements for product evaluation analysis, testing, profiling, product certification, and/or product accreditation related activity undertaken.
コンピュータ・システムのためのコンピュータセキュリティ格付けが必要であるかもしれません。 例えば、格付けはTrusted System Evaluation Criteria(TCSEC)、カナダのTrusted Products Evaluation Criteria、ヨーロッパの情報Technology Security Evaluation Criteria(ITSEC)、または情報Technology Security EvaluationのためのCommon Criteriaに基づくことができました、ISO/IEC、15408:1999 また、このサブコンポーネントは引き受けられた製品評価分析、テスト、プロフィール、製品証明、そして/または、製品認可関連活動のための要件を扱うことができます。
4.6.6. Life Cycle Security Controls
4.6.6. ライフサイクルセキュリティコントロール
This subcomponent addresses system development controls and security management controls.
このサブコンポーネントは、システム開発規則とセキュリティがマネジメント・コントロールであると扱います。
System development controls include development environment security, development personnel security, configuration management security during product maintenance, software engineering practices, software development methodology, modularity, layering, use of failsafe design and implementation techniques (e.g., defensive programming) and development facility security.
システム開発規則は製品メインテナンス、ソフトウェア工学習慣、ソフトウェア開発方法論、モジュール方式、レイヤリング、フェールセイフの設計と実装のテクニック(例えば、防衛的なプログラミング)と開発施設セキュリティの使用の間、開発環境セキュリティ、開発人的安全保護、構成管理セキュリティを含んでいます。
Security management controls include execution of tools and procedures to ensure that the operational systems and networks adhere to configured security. These tools and procedures include checking the integrity of the security software, firmware, and hardware to ensure their correct operation.
セキュリティマネジメント・コントロールは、基幹系システムとネットワークが構成されたセキュリティを固く守るのを保証するためにツールと手順の実行を含んでいます。 これらのツールと手順は、彼らの正しい操作を確実にするために機密保護ソフトウェア、ファームウェア、およびハードウェアの保全をチェックするのを含んでいます。
This subcomponent can also address life-cycle security ratings based, for example, on the Trusted Software Development Methodology (TSDM) level IV and V, independent life-cycle security controls audit, and the Software Engineering Institute's Capability Maturity Model (SEI- CMM).
また、このサブコンポーネントは、ライフサイクルセキュリティが例えばTrusted Software Development MethodologyレベルIVとV(TSDM)、コントロールが監査する独立しているライフサイクルセキュリティ、およびSoftware Engineering InstituteのCapability Maturity Model(SEI- CMM)に基づく格付けであると扱うことができます。
4.6.7. Network Security Controls
4.6.7. ネットワークセキュリティコントロール
This subcomponent addresses network security related controls, including firewalls.
このサブコンポーネントは、ネットワークセキュリティがファイアウォールを含む関連するコントロールであると扱います。
4.6.8. Time-stamping
4.6.8. 時間の刻印
This subcomponent addresses requirements or practices relating to the use of timestamps on various data. It may also discuss whether or not the time-stamping application must use a trusted time source.
このサブコンポーネントは様々なデータにおけるタイムスタンプの使用に関連する要件か習慣を扱います。 また、それは、時間の刻印アプリケーションが信じられた時間ソースを使用しなければならないかどうか議論するかもしれません。
Chokhani, et al. Informational [Page 43] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [43ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
4.7. Certificate and CRL Profiles
4.7. 証明書とCRLプロフィール
This component is used to specify the certificate format and, if CRLs and/or OCSP are used, the CRL and/or OCSP format. This includes information on profiles, versions, and extensions used.
このコンポーネントは、CRLs、そして/または、OCSPが使用されているときの証明書形式と、CRL、そして/または、OCSP形式を指定するのに使用されます。 これはプロフィール、バージョン、および使用される拡張子の情報を含んでいます。
4.7.1. Certificate Profile
4.7.1. 証明書プロフィール
This subcomponent addresses such topics as the following (potentially by reference to a separate profile definition, such as the one defined in IETF PKIX RFC 3280):
このサブコンポーネントは以下のような話題を扱います(潜在的に、別々のプロフィール定義の参照で、ものとしてのそのようなものはIETF PKIX RFCで3280を定義しました):
* Version number(s) supported;
* (s)がサポートしたバージョン番号。
* Certificate extensions populated and their criticality;
* 居住された拡大とそれらの臨界を証明してください。
* Cryptographic algorithm object identifiers;
* 暗号アルゴリズムオブジェクト識別子。
* Name forms used for the CA, RA, and subscriber names;
* 名前フォームはカリフォルニア、RA、および加入者に名前を使用しました。
* Name constraints used and the name forms used in the name
constraints;
* 規制が使用した名前と形成という名前は名前に規制を使用しました。
* Applicable CP OID(s);
* 適切なCP OID(s)。
* Usage of the policy constraints extension;
* 方針規制拡大の用法。
* Policy qualifiers syntax and semantics; and
* 方針資格を与える人構文と意味論。 そして
* Processing semantics for the critical CP extension.
* 重要なCP拡張子のために意味論を処理します。
4.7.2. CRL Profile
4.7.2. CRLプロフィール
This subcomponent addresses such topics as the following (potentially by reference to a separate profile definition, such as the one defined in IETF PKIX RFC 3280):
このサブコンポーネントは以下のような話題を扱います(潜在的に、別々のプロフィール定義の参照で、ものとしてのそのようなものはIETF PKIX RFCで3280を定義しました):
* Version numbers supported for CRLs; and
* CRLsのためにサポートされたバージョン番号。 そして
* CRL and CRL entry extensions populated and their criticality.
* CRL、居住されたCRLエントリー拡張子、およびそれらの臨界。
4.7.3. OCSP Profile
4.7.3. OCSPプロフィール
This subcomponent addresses such topics as the following (potentially by reference to a separate profile definition, such as the IETF RFC 2560 profile):
このサブコンポーネントは以下のような話題を扱います(aの参照で潜在的にプロフィール定義を切り離してください、IETF RFC2560プロフィールなどのように):
Chokhani, et al. Informational [Page 44] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [44ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
* Version of OCSP that is being used as the basis for establishing
an OCSP system; and
* OCSPシステムを確立する基礎として使用されているOCSPのバージョン。 そして
* OCSP extensions populated and their criticality.
* 居住されたOCSP拡張子とそれらの臨界。
4.8. Compliance Audit and Other Assessment
4.8. 承諾監査と他の査定
This component addresses the following:
このコンポーネントは以下を扱います:
* The list of topics covered by the assessment and/or the assessment
methodology used to perform the assessment; examples include
WebTrust for CAs (9) and SAS 70 (10).
* 査定、そして/または、査定方法論でカバーされた話題のリストは以前はよく査定を実行していました。 例はCAs(9)とSAS70(10)のためのWebTrustを含んでいます。
* Frequency of compliance audit or other assessment for each entity
that must be assessed pursuant to a CP or CPS, or the
circumstances that will trigger an assessment; possibilities
include an annual audit, pre-operational assessment as a condition
of allowing an entity to be operational, or investigation
following a possible or actual compromise of security.
* 承諾監査の頻度かCPかCPSによると、評価しなければならない各実体、または査定の引き金となる事情のための他の査定。 可能性は実体が操作上であることを許容するという条件、またはセキュリティの可能であるか実際の感染に続く調査として年次監査、プレ操作上の査定を含んでいます。
* The identity and/or qualifications of the personnel performing the
audit or other assessment.
* 監査か他の査定を実行している人員のアイデンティティ、そして/または、資格。
* The relationship between the assessor and the entity being
assessed, including the degree of independence of the assessor.
* 査定者からの独立の度合いを含んでいて、評価される査定者と実体との関係。
* Actions taken as a result of deficiencies found during the
assessment; examples include a temporary suspension of operations
until deficiencies are corrected, revocation of certificates
issued to the assessed entity, changes in personnel, triggering
special investigations or more frequent subsequent compliance
assessments, and claims for damages against the assessed entity.
* 査定の間に見つけられた欠乏の結果、取られた行動。 欠乏が直るまで、例は操作の一時的なサスペンションを含んでいます、と証明書の取消しが評価された実体に発行しました、人員における変化、評価された実体に対して特別捜査か、より頻繁なその後のコンプライアンス評価と、損害賠償のためのクレームの引き金となって。
* Who is entitled to see results of an assessment (e.g., assessed
entity, other participants, the general public), who provides them
(e.g., the assessor or the assessed entity), and how they are
communicated.
* 査定(例えば、実体、他の関係者、一般を評価する)の結果を見る権利を与えられて、彼ら(例えば、査定者か評価された実体)と、彼らがどう伝えられるかを前提とします。
4.9. Other Business and Legal Matters
4.9. 他のビジネスと法的な件
This component covers general business and legal matters. Sections 9.1 and 9.2 of the framework discuss the business issues of fees to be charged for various services and the financial responsibility of participants to maintain resources for ongoing operations and for paying judgments or settlements in response to claims asserted against them. The remaining sections are generally concerned with legal topics.
このコンポーネントは一般事業と法的な件を含んでいます。 フレームワークのセクション9.1と9.2は様々なサービスのために請求される料金のビジネス問題とそれらに対して断言されたクレームに対応して進行中の操作と判断か解決を支払うためのリソースを維持する関係者の金融責任について論じます。 一般に、残っているセクションは法的な話題に関係があります。
Chokhani, et al. Informational [Page 45] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [45ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
Starting with Section 9.3 of the framework, the ordering of topics is the same as or similar to the ordering of topics in a typical software licensing agreement or other technology agreement. Consequently, this framework may not only be used for CPs and CPSs, but also associated PKI-related agreements, especially subscriber agreements, and relying party agreements. This ordering is intended help lawyers review CPs, CPSs, and other documents adhering to this framework.
フレームワークのセクション9.3から始まって、話題の注文は、典型的なソフトウェアライセンス契約か他の技術合意における、話題の注文と同じであるか、または同様です。 その結果、このフレームワークは、CPsとCPSsに使用されたかもしれないだけではありませんが、PKI関連の協定、特に加入者協定、および信用パーティー協定をまた関連づけました。 この注文は、意図している助け弁護士レビューCPs(CPSs)とこのフレームワークを固く守る他のドキュメントです。
With respect to many of the legal subcomponents within this component, a CP or CPS drafter may choose to include in the document terms and conditions that apply directly to subscribers or relying parties. For instance, a CP or CPS may set forth limitations of liability that apply to subscribers and relying parties. The inclusion of terms and conditions is likely to be appropriate where the CP or CPS is itself a contract or part of a contract.
ドラフターが選ぶかもしれないこのコンポーネントの中の法的なサブコンポーネント、CPまたはCPSの多くに関して、ドキュメント条件にそれを含むには、加入者か信用パーティーに自薦してください。 例えば、CPかCPSが加入者に適用される責任の制限について詳しく説明するかもしれません、そして、信用はパーティーへ行きます。 条件の包含はCPかCPSがそれ自体で契約の契約か一部であるところで適切である傾向があります。
In other cases, however, the CP or CPS is not a contract or part of a contract; instead, it is configured so that its terms and conditions are applied to the parties by separate documents, which may include associated agreements, such as subscriber or relying party agreements. In that event, a CP drafter may write a CP so as to require that certain legal terms and conditions appear (or not appear) in such associated agreements. For example, a CP might include a subcomponent stating that a certain limitation of liability term must appear in a CA's subscriber and relying party agreements. Another example is a CP that contains a subcomponent prohibiting the use of a subscriber or relying party agreement containing a limitation upon CA liability inconsistent with the provisions of the CP. A CPS drafter may use legal subcomponents to disclose that certain terms and conditions appear in associated subscriber, relying party, or other agreements in use by the CA. A CPS might explain, for instance, that the CA writing it uses an associated subscriber or relying party agreement that applies a particular provision for limiting liability.
しかしながら、他の場合では、CPかCPSが契約の契約でなくて、また一部でもありません。 代わりに、それが構成されるので、別々のドキュメント(付随契約を含むかもしれない)によって条件はパーティーに適用されます、加入者か信用パーティー協定などのように。 その場合には、CPドラフターは、ある法的な条件がそのような付随契約に現れるのが(または、現れません)必要であるようにCPに書くかもしれません。 例えば、CPは責任用語のある制限がCAの加入者と信用パーティー合意に現れなければならないと述べるサブコンポーネントを含むかもしれません。 別の例はCPに関する条項に反しているカリフォルニア責任に制限を含む加入者か信用パーティー協定の使用を禁止するサブコンポーネントを含むCPです。 CPSドラフターは、ある条件がカリフォルニアのそばで使用中の関連加入者、当てにしているパーティー、または他の合意に現れるのを明らかにするのに法的なサブコンポーネントを使用するかもしれません。 例えば、CPSは、それを書くカリフォルニアが責任を限定するのに特定の支給を当てはまる関連加入者か信用パーティー協定を使用すると説明するかもしれません。
4.9.1. Fees
4.9.1. 料金
This subcomponent contains any applicable provisions regarding fees charged by CAs, repositories, or RAs, such as:
このサブコンポーネントは以下などのCAs、倉庫、またはRAsによって請求された料金に関するどんな適切な条項も含んでいます。
* Certificate issuance or renewal fees;
* 発行か更新料を証明してください。
* Certificate access fees;
* アクセスチャージを証明してください。
* Revocation or status information access fees;
* 取消しか状態情報アクセスチャージ。
Chokhani, et al. Informational [Page 46] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [46ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
* Fees for other services such as providing access to the relevant
CP or CPS; and
* 提供などの他のサービスのための料金はCPかCPSに関連にアクセスします。 そして
* Refund policy.
* 方針を還付してください。
4.9.2. Financial Responsibility
4.9.2. 金融責任
This subcomponent contains requirements or disclosures relating to the resources available to CAs, RAs, and other participants providing certification services to support performance of their operational PKI responsibilities, and to remain solvent and pay damages in the event they are liable to pay a judgment or settlement in connection with a claim arising out of such operations. Such provisions include:
このサブコンポーネントはそれらがそのような操作から起こるクレームに関する判断か解決を支払うのにおいて責任があるイベントでそれらの操作上のPKI責任の性能をサポートして、支払能力があったままで残って、損害を賠償するために証明サービスを提供するCAs、RAs、および他の関係者にとって、利用可能なリソースに関連する要件か公開を含んでいます。 そのような条項は:
* A statement that the participant maintains a certain amount of
insurance coverage for its liabilities to other participants;
* 関係者が負債のためにある一定の保険金額適用範囲を他の関係者に維持するという声明。
* A statement that a participant has access to other resources to
support operations and pay damages for potential liability, which
may be couched in terms of a minimum level of assets necessary to
operate and cover contingencies that might occur within a PKI,
where examples include assets on the balance sheet of an
organization, a surety bond, a letter of credit, and a right under
an agreement to an indemnity under certain circumstances; and
* 関係者が潜在的責任のために操作をサポートして、損害を賠償するために他のリソースに近づく手段を持っているという声明責任はある状況の下での保障への組織、保証書、信用状、および協定直下でのaの貸借対照表に例が資産を含んでいるPKIの中に起こるかもしれない偶然性を操作して、カバーするのに必要な資産の最低水準で堆積するかもしれません。 そして
* A statement that a participant has a program that offers first-
party insurance or warranty protection to other participants in
connection with their use of the PKI.
* 関係者が彼らのPKIの使用に関して保険か保証保護を最初に、パーティーに提供するプログラムを他の関係者に持っているという声明。
4.9.3. Confidentiality of Business Information
4.9.3. 企業情報の秘密性
This subcomponent contains provisions relating to the treatment of confidential business information that participants may communicate to each other, such as business plans, sales information, trade secrets, and information received from a third party under a nondisclosure agreement. Specifically, this subcomponent addresses:
このサブコンポーネントは関係者が互いに交信するかもしれないという企業秘密情報の処理に関連する条項を含んでいます、第三者から不告知協定で受け取られたビジネスプランや、販売情報や、企業秘密や、情報などのように。 明確に、このサブコンポーネントは以下を扱います。
* The scope of what is considered confidential information,
* 何に関する範囲は秘密情報であると考えられるか。
* The types of information that are considered to be outside the
scope of confidential information, and
* そして秘密情報の範囲の外にあると考えられる情報のタイプ。
* The responsibilities of participants that receive confidential
information to secure it from compromise, and refrain from using
it or disclosing it to third parties.
* それを機密保護する秘密情報を受け取る関係者の責任は、妥協して、それを使用するか、または第三者にそれを明らかにするのを控えます。
Chokhani, et al. Informational [Page 47] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [47ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
4.9.4. Privacy of Personal Information
4.9.4. 個人情報の秘密
This subcomponent relates to the protection that participants, particularly CAs, RAs, and repositories, may be required to afford to personally identifiable private information of certificate applicants, subscribers, and other participants. Specifically, this subcomponent addresses the following, to the extent pertinent under applicable law:
このサブコンポーネントは関係者、特にCAs、RAs、および倉庫が証明書応募者、加入者、および他の関係者の個人的に身元保証可能な個人情報に都合しなければならないかもしれない保護に関連します。 明確に、このサブコンポーネントは準拠法の下において適切な範囲に以下を扱います:
* The designation and disclosure of the applicable privacy plan that
applies to a participant's activities, if required by applicable
law or policy;
* 必要なら準拠法か方針で関係者の活動に適用される適切なプライバシープランの名称と公開。
* Information that is or is not considered private within the PKI;
* あるか、またはPKIの中で個人的であることは考えられない情報。
* Any responsibility of participants that receive private
information to secure it, and refrain from using it and from
disclosing it to third parties;
* それを使用して、それを明らかにすることが第三者にそれを機密保護して、控えられるために内密の報道を受け取る関係者のどんな責任も。
* Any requirements as to notices to, or consent from individuals
regarding use or disclosure of private information; and
* 個人情報の使用か公開に関する個人からの通知、または同意に関するどんな要件も。 そして
* Any circumstances under which a participant is entitled or
required to disclose private information pursuant to judicial,
administrative process in a private or governmental proceeding, or
in any legal proceeding.
* どんな事情も、関係者がどれであるかの下で権利を与えられるか、または司法の、そして、管理の過程に従って個人的であるか政府の進行、またはどんな合法的な処置でも個人情報を明らかにするのが必要です。
4.9.5. Intellectual Property Rights
4.9.5. 知的所有権
This subcomponent addresses the intellectual property rights, such as copyright, patent, trademarks, or trade secrets, that certain participants may have or claim in a CP, CPS, certificates, names, and keys, or are the subject of a license to or from participants.
このサブコンポーネントは、知的所有権が権利であると扱います、著作権、特許、商標、または企業秘密などのように、関係者がCP、CPSで証明書、名前、およびキーを持っているか、要求するかもしれない、または関係者か関係者からのライセンスの対象であることをそんなに確信しています。
4.9.6. Representations and Warranties
4.9.6. 表明保証条項
This subcomponent can include representations and warranties of various entities that are being made pursuant to the CP or CPS. For example, a CPS that serves as a contract might contain a CA's warranty that information contained in the certificate is accurate. Alternatively, a CPS might contain a less extensive warranty to the effect that the information in the certificate is true to the best of the CA's knowledge after performing certain identity authentication procedures with due diligence. This subcomponent can also include requirements that representations and warranties appear in certain agreements, such as subscriber or relying party agreements. For instance, a CP may contain a requirement that all CAs utilize a subscriber agreement, and that a subscriber agreement must contain a
このサブコンポーネントはCPかCPSによると、作られている様々な実体の表明保証条項を含むことができます。例えば、契約が情報が証明書に含んだCAの保証を含むかもしれなくて役立つCPSは正確です。 あるいはまた、CPSは適切な注意で、あるアイデンティティ認証手順を実行した後にCAの知識では、証明書の情報が誠実であるという効果にそれほど大規模でない保証を含むかもしれません。 また、このサブコンポーネントは表明保証条項が、ある合意に現れるという要件を含むことができます、加入者か信用パーティー協定などのように。 例えば、CPはすべてのCAsが加入者協定を利用して、加入者協定がaを含まなければならないという要件を含むかもしれません。
Chokhani, et al. Informational [Page 48] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [48ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
warranty by the CA that information in the certificate is accurate. Participants that may make representations and warranties include CAs, RAs, subscribers, relying parties, and other participants.
保証、カリフォルニアのそばでは、証明書のその情報が正確です。 表明保証条項を作るかもしれない関係者がCAs、RAs、加入者、当てにしているパーティー、および他の関係者を入れます。
4.9.7. Disclaimers of Warranties
4.9.7. 保証に関する注意書き
This subcomponent can include disclaimers of express warranties that may otherwise be deemed to exist in an agreement, and disclaimers of implied warranties that may otherwise be imposed by applicable law, such as warranties of merchantability or fitness for a particular purpose. The CP or CPS may directly impose such disclaimers, or the CP or CPS may contain a requirement that disclaimers appear in associated agreements, such as subscriber or relying party agreements.
このサブコンポーネントは合意で存在すると別の方法で考えられるかもしれない、明示的な保証に関する注意書き、およびそうでなければ準拠法で課されるかもしれない黙示的な保証に関する注意書きを含むことができます、市場性か特定目的への適合性の保証などのように。 CPかCPSが直接そのような注意書きを課すかもしれませんか、またはCPかCPSが注意書きが付随契約に現れるという要件を含むかもしれません、加入者か信用パーティー協定などのように。
4.9.8. Limitations of Liability
4.9.8. 責任の制限
This subcomponent can include limitations of liability in a CP or CPS or limitations that appear or must appear in an agreement associated with the CP or CPS, such as a subscriber or relying party agreement. These limitations may fall into one of two categories: limitations on the elements of damages recoverable and limitations on the amount of damages recoverable, also known as liability caps. Often, contracts contain clauses preventing the recovery of elements of damages such as incidental and consequential damages, and sometimes punitive damages. Frequently, contracts contain clauses that limit the possible recovery of one party or the other to an amount certain or to an amount corresponding to a benchmark, such as the amount a vendor was paid under the contract.
このサブコンポーネントは、現れるCP、CPSまたは制限に責任の制限を含むことができなければならないか、またはCPかCPSに関連している合意に現れなければなりません、加入者か信用パーティー協定のように。 これらの制限は2つのカテゴリの1つになるかもしれません: 損害賠償の回復可能な要素における制限と回復可能で、また、責任上限として知られている損害賠償の量における制限。 しばしば、契約は付帯的で必然的な損害賠償や、時々損害賠償などの損害賠償の要素の回復を防ぐ節を含んでいます。 頻繁に、契約が1回のパーティーかもう片方の可能な回復を量に確かな状態で制限する節を含んでいるか、または量などのベンチマークに対応する量に、契約に基づきベンダーを支払いました。
4.9.9. Indemnities
4.9.9. 保障
This subcomponent includes provisions by which one party makes a second party whole for losses or damage incurred by the second party, typically arising out of the first party's conduct. They may appear in a CP, CPS, or agreement. For example, a CP may require that subscriber agreements contain a term under which a subscriber is responsible for indemnifying a CA for losses the CA sustains arising out of a subscriber's fraudulent misrepresentations on the certificate application under which the CA issued the subscriber an inaccurate certificate. Similarly, a CPS may say that a CA uses a relying party agreement, under which relying parties are responsible for indemnifying a CA for losses the CA sustains arising out of use of a certificate without properly checking revocation information or use of a certificate for purposes beyond what the CA permits.
このサブコンポーネントはパーティーが2番目のパーティーを2番目のパーティーによって被られた損失か損害で全体にする条項を含んでいます、最初のパーティーの行為から通常起こって。 彼らはCP、CPS、または合意に現れるかもしれません。 例えば、CPは、加入者協定が加入者が証明書アプリケーションときにカリフォルニアが不正確な証明書を加入者に発行した加入者の詐欺的な誤伝から起こりながらカリフォルニアが被る損失でカリフォルニアを保障するのに責任がある諸条件を含むのを必要とするかもしれません。 同様に、CPSは、カリフォルニアが信用パーティーにカリフォルニアが可能にすることを超えて証明書の目的の一致、カリフォルニアが損失でカリフォルニアを保障して、信用パーティーはどれに責任があるかの下で証明書の使用から適切に取消し情報をチェックしないで起こり続けるか、そして、または使用を使用すると言うかもしれません。
Chokhani, et al. Informational [Page 49] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [49ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
4.9.10. Term and Termination
4.9.10. 用語と終了
This subcomponent can include the time period in which a CP or a CPS remains in force and the circumstances under which the document, portions of the document, or its applicability to a particular participant can be terminated. In addition or alternatively, the CP or CPS may include requirements that certain term and termination clauses appear in agreements, such as subscriber or relying party agreements. In particular, such terms can include:
このサブコンポーネントはCPかCPSが有効なままで残っている期間とドキュメント、ドキュメントの一部、または特定の関係者へのその適用性を終えることができる事情を含むことができます。 中では、あるいはまた、追加、CPまたはCPSはそうするかもしれません。ある用語と契約解除条項が合意に現れるという要件を含めてください、加入者か信用パーティー協定などのように。 特に、そのような用語は以下を含むことができます。
* The term of a document or agreement, that is, when the document
becomes effective and when it expires if it is not terminated
earlier.
* すなわち、ドキュメントが有効になって、より早く終えられないなら期限が切れるときのドキュメントか協定の期間。
* Termination provisions stating circumstances under which the
document, certain portions of it, or its application to a
particular participant ceases to remain in effect.
* ドキュメント、それのある部分、または特定の関係者へのそのアプリケーションが有効なままで残っているのをやめる事情を述べる終了条項。
* Any consequences of termination of the document. For example,
certain provisions of an agreement may survive its termination and
remain in force. Examples include acknowledgements of
intellectual property rights and confidentiality provisions.
Also, termination may trigger a responsibility of parties to
return confidential information to the party that disclosed it.
* Any consequences of termination of the document. For example, certain provisions of an agreement may survive its termination and remain in force. Examples include acknowledgements of intellectual property rights and confidentiality provisions. Also, termination may trigger a responsibility of parties to return confidential information to the party that disclosed it.
4.9.11. Individual notices and communications with participants
4.9.11. Individual notices and communications with participants
This subcomponent discusses the way in which one participant can or must communicate with another participant on a one-to-one basis in order for such communications to be legally effective. For example, an RA may wish to inform the CA that it wishes to terminate its agreement with the CA. This subcomponent is different from publication and repository functions, because unlike individual communications described in this subcomponent, publication and posting to a repository are for the purpose of communicating to a wide audience of recipients, such as all relying parties. This subcomponent may establish mechanisms for communication and indicate the contact information to be used to route such communications, such as digitally signed e-mail notices to a specified address, followed by a signed e-mail acknowledgement of receipt.
This subcomponent discusses the way in which one participant can or must communicate with another participant on a one-to-one basis in order for such communications to be legally effective. For example, an RA may wish to inform the CA that it wishes to terminate its agreement with the CA. This subcomponent is different from publication and repository functions, because unlike individual communications described in this subcomponent, publication and posting to a repository are for the purpose of communicating to a wide audience of recipients, such as all relying parties. This subcomponent may establish mechanisms for communication and indicate the contact information to be used to route such communications, such as digitally signed e-mail notices to a specified address, followed by a signed e-mail acknowledgement of receipt.
4.9.12. Amendments
4.9.12. Amendments
It will occasionally be necessary to amend a CP or CPS. Some of these changes will not materially reduce the assurance that a CP or its implementation provides, and will be judged by the policy administrator to have an insignificant effect on the acceptability of certificates. Such changes to a CP or CPS need not require a change
It will occasionally be necessary to amend a CP or CPS. Some of these changes will not materially reduce the assurance that a CP or its implementation provides, and will be judged by the policy administrator to have an insignificant effect on the acceptability of certificates. Such changes to a CP or CPS need not require a change
Chokhani, et al. Informational [Page 50] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani, et al. Informational [Page 50] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
in the CP OID or the CPS pointer (URL). On the other hand, some changes to a specification will materially change the acceptability of certificates for specific purposes, and these changes may require corresponding changes to the CP OID or CPS pointer qualifier (URL).
in the CP OID or the CPS pointer (URL). On the other hand, some changes to a specification will materially change the acceptability of certificates for specific purposes, and these changes may require corresponding changes to the CP OID or CPS pointer qualifier (URL).
This subcomponent may also contain the following information:
This subcomponent may also contain the following information:
* The procedures by which the CP or CPS and/or other documents must,
may be, or are amended. In the case of CP or CPS amendments,
change procedures may include a notification mechanism to provide
notice of proposed amendments to affected parties, such as
subscribers and relying parties, a comment period, a mechanism by
which comments are received, reviewed and incorporated into the
document, and a mechanism by which amendments become final and
effective.
* The procedures by which the CP or CPS and/or other documents must, may be, or are amended. In the case of CP or CPS amendments, change procedures may include a notification mechanism to provide notice of proposed amendments to affected parties, such as subscribers and relying parties, a comment period, a mechanism by which comments are received, reviewed and incorporated into the document, and a mechanism by which amendments become final and effective.
* The circumstances under which amendments to the CP or CPS would
require a change in CP OID or CPS pointer (URL).
* The circumstances under which amendments to the CP or CPS would require a change in CP OID or CPS pointer (URL).
4.9.13. Dispute Resolution Procedures
4.9.13. Dispute Resolution Procedures
This subcomponent discusses procedures utilized to resolve disputes arising out of the CP, CPS, and/or agreements. Examples of such procedures include requirements that disputes be resolved in a certain forum or by alternative dispute resolution mechanisms.
This subcomponent discusses procedures utilized to resolve disputes arising out of the CP, CPS, and/or agreements. Examples of such procedures include requirements that disputes be resolved in a certain forum or by alternative dispute resolution mechanisms.
4.9.14. Governing Law
4.9.14. Governing Law
This subcomponent sets forth a statement that the law of a certain jurisdiction governs the interpretation and enforcement of the subject CP or CPS or agreements.
This subcomponent sets forth a statement that the law of a certain jurisdiction governs the interpretation and enforcement of the subject CP or CPS or agreements.
4.9.15. Compliance with Applicable Law
4.9.15. Compliance with Applicable Law
This subcomponent relates to stated requirements that participants comply with applicable law, for example, laws relating to cryptographic hardware and software that may be subject to the export control laws of a given jurisdiction. The CP or CPS could purport to impose such requirements or may require that such provisions appear in other agreements.
This subcomponent relates to stated requirements that participants comply with applicable law, for example, laws relating to cryptographic hardware and software that may be subject to the export control laws of a given jurisdiction. The CP or CPS could purport to impose such requirements or may require that such provisions appear in other agreements.
4.9.16. Miscellaneous Provisions
4.9.16. Miscellaneous Provisions
This subcomponent contains miscellaneous provisions, sometimes called "boilerplate provisions," in contracts. The clauses covered in this subcomponent may appear in a CP, CPS, or agreements and include:
This subcomponent contains miscellaneous provisions, sometimes called "boilerplate provisions," in contracts. The clauses covered in this subcomponent may appear in a CP, CPS, or agreements and include:
Chokhani, et al. Informational [Page 51] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani, et al. Informational [Page 51] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
* An entire agreement clause, which typically identifies the
document or documents comprising the entire agreement between the
parties and states that such agreements supersede all prior and
contemporaneous written or oral understandings relating to the
same subject matter;
* An entire agreement clause, which typically identifies the document or documents comprising the entire agreement between the parties and states that such agreements supersede all prior and contemporaneous written or oral understandings relating to the same subject matter;
* An assignment clause, which may act to limit the ability of a
party in an agreement, assigning its rights under the agreement to
another party (such as the right to receive a stream of payments
in the future) or limiting the ability of a party to delegate its
obligations under the agreement;
* An assignment clause, which may act to limit the ability of a party in an agreement, assigning its rights under the agreement to another party (such as the right to receive a stream of payments in the future) or limiting the ability of a party to delegate its obligations under the agreement;
* A severability clause, which sets forth the intentions of the
parties in the event that a court or other tribunal determines
that a clause within an agreement is, for some reason, invalid or
unenforceable, and whose purpose is frequently to prevent the
unenforceability of one clause from causing the whole agreement to
be unenforceable; and
* A severability clause, which sets forth the intentions of the parties in the event that a court or other tribunal determines that a clause within an agreement is, for some reason, invalid or unenforceable, and whose purpose is frequently to prevent the unenforceability of one clause from causing the whole agreement to be unenforceable; and
* An enforcement clause, which may state that a party prevailing in
any dispute arising out of an agreement is entitled to attorneys'
fees as part of its recovery, or may state that a party's waiver
of one breach of contract does not constitute a continuing waiver
or a future waiver of other breaches of contract.
* An enforcement clause, which may state that a party prevailing in any dispute arising out of an agreement is entitled to attorneys' fees as part of its recovery, or may state that a party's waiver of one breach of contract does not constitute a continuing waiver or a future waiver of other breaches of contract.
* A force majeure clause, commonly used to excuse the performance of
one or more parties to an agreement due to an event outside the
reasonable control of the affected party or parties. Typically,
the duration of the excused performance is commensurate with the
duration of the delay caused by the event. The clause may also
provide for the termination of the agreement under specified
circumstances and conditions. Events considered to constitute a
"force majeure" may include so-called "Acts of God," wars,
terrorism, strikes, natural disasters, failures of suppliers or
vendors to perform, or failures of the Internet or other
infrastructure. Force majeure clauses should be drafted so as to
be consistent with other portions of the framework and applicable
service level agreements. For instance, responsibilities and
capabilities for business continuity and disaster recovery may
place some events within the reasonable control of the parties,
such as an obligation to maintain backup electrical power in the
face of power outages.
* A force majeure clause, commonly used to excuse the performance of one or more parties to an agreement due to an event outside the reasonable control of the affected party or parties. Typically, the duration of the excused performance is commensurate with the duration of the delay caused by the event. The clause may also provide for the termination of the agreement under specified circumstances and conditions. Events considered to constitute a "force majeure" may include so-called "Acts of God," wars, terrorism, strikes, natural disasters, failures of suppliers or vendors to perform, or failures of the Internet or other infrastructure. Force majeure clauses should be drafted so as to be consistent with other portions of the framework and applicable service level agreements. For instance, responsibilities and capabilities for business continuity and disaster recovery may place some events within the reasonable control of the parties, such as an obligation to maintain backup electrical power in the face of power outages.
Chokhani, et al. Informational [Page 52] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani, et al. Informational [Page 52] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
4.9.17. Other Provisions
4.9.17. Other Provisions
This subcomponent is a "catchall" location where additional responsibilities and terms can be imposed on PKI participants that do not neatly fit within one of the other components or subcomponents of the framework. CP and CPS writers can place any provision within this subcomponent that is not covered by another subcomponent.
This subcomponent is a "catchall" location where additional responsibilities and terms can be imposed on PKI participants that do not neatly fit within one of the other components or subcomponents of the framework. CP and CPS writers can place any provision within this subcomponent that is not covered by another subcomponent.
5. Security Considerations
5. Security Considerations
According to X.509, a certificate policy (CP) is "a named set of rules that indicates the applicability of a certificate to a particular community and/or class of applications with common security requirements." A CP may be used by a relying party to help in deciding whether a certificate, and the binding therein, are sufficiently trustworthy and otherwise appropriate for a particular application.
According to X.509, a certificate policy (CP) is "a named set of rules that indicates the applicability of a certificate to a particular community and/or class of applications with common security requirements." A CP may be used by a relying party to help in deciding whether a certificate, and the binding therein, are sufficiently trustworthy and otherwise appropriate for a particular application.
The degree to which a relying party can trust the binding embodied in a certificate depends on several factors. These factors can include the practices followed by the certification authority (CA) in authenticating the subject; the CA's operating policy, procedures, and technical security controls, including the scope of the subscriber's responsibilities (for example, in protecting the private key), and the stated responsibilities and liability terms and conditions of the CA (for example, warranties, disclaimers of warranties, and limitations of liability).
The degree to which a relying party can trust the binding embodied in a certificate depends on several factors. These factors can include the practices followed by the certification authority (CA) in authenticating the subject; the CA's operating policy, procedures, and technical security controls, including the scope of the subscriber's responsibilities (for example, in protecting the private key), and the stated responsibilities and liability terms and conditions of the CA (for example, warranties, disclaimers of warranties, and limitations of liability).
This document provides a framework to address technical, procedural, personnel, and physical security aspects of Certification Authorities, Registration Authorities, repositories, subscribers, and relying party cryptographic modules, in order to ensure that the certificate generation, publication, renewal, re-key, usage, and revocation is done in a secure manner. Specifically, Section 4.3 Identification and Authentication (I&A); Section 4.4 Certificate Life-Cycle Operational Requirements; Section 4.5 Facility Management, and Operational Controls; Section 4.6 Technical Security Controls; Section 4.7 Certificate CRL, and OCSP Profiles; and Section 4.8 Compliance Audit and Other Assessment, are oriented towards ensuring secure operation of the PKI entities such as CA, RA, repository, subscriber systems, and relying party systems.
This document provides a framework to address technical, procedural, personnel, and physical security aspects of Certification Authorities, Registration Authorities, repositories, subscribers, and relying party cryptographic modules, in order to ensure that the certificate generation, publication, renewal, re-key, usage, and revocation is done in a secure manner. Specifically, Section 4.3 Identification and Authentication (I&A); Section 4.4 Certificate Life-Cycle Operational Requirements; Section 4.5 Facility Management, and Operational Controls; Section 4.6 Technical Security Controls; Section 4.7 Certificate CRL, and OCSP Profiles; and Section 4.8 Compliance Audit and Other Assessment, are oriented towards ensuring secure operation of the PKI entities such as CA, RA, repository, subscriber systems, and relying party systems.
6. Outline of a Set of Provisions
6. Outline of a Set of Provisions
This section contains a recommended outline for a set of provisions, intended to serve as a checklist or (with some further development) a standard template for use by CP or CPS writers. Such a common outline will facilitate:
This section contains a recommended outline for a set of provisions, intended to serve as a checklist or (with some further development) a standard template for use by CP or CPS writers. Such a common outline will facilitate:
Chokhani, et al. Informational [Page 53] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani, et al. Informational [Page 53] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
(a) Comparison of two certificate policies during cross-
certification or other forms of interoperation (for the purpose
of equivalency mapping).
(a) Comparison of two certificate policies during cross- certification or other forms of interoperation (for the purpose of equivalency mapping).
(b) Comparison of a CPS with a CP to ensure that the CPS faithfully
implements the policy.
(b) Comparison of a CPS with a CP to ensure that the CPS faithfully implements the policy.
(c) Comparison of two CPSs.
(c) Comparison of two CPSs.
In order to comply with the RFC, the drafters of a compliant CP or CPS are strongly advised to adhere to this outline. While use of an alternate outline is discouraged, it may be accepted if a proper justification is provided for the deviation and a mapping table is provided to readily discern where each of the items described in this outline is provided.
In order to comply with the RFC, the drafters of a compliant CP or CPS are strongly advised to adhere to this outline. While use of an alternate outline is discouraged, it may be accepted if a proper justification is provided for the deviation and a mapping table is provided to readily discern where each of the items described in this outline is provided.
1. INTRODUCTION 1.1 Overview 1.2 Document name and identification 1.3 PKI participants 1.3.1 Certification authorities 1.3.2 Registration authorities 1.3.3 Subscribers 1.3.4 Relying parties 1.3.5 Other participants 1.4 Certificate usage 1.4.1. Appropriate certificate uses 1.4.2 Prohibited certificate uses 1.5 Policy administration 1.5.1 Organization administering the document 1.5.2 Contact person 1.5.3 Person determining CPS suitability for the policy 1.5.4 CPS approval procedures 1.6 Definitions and acronyms 2. PUBLICATION AND REPOSITORY RESPONSIBILITIES 2.1 Repositories 2.2 Publication of certification information 2.3 Time or frequency of publication 2.4 Access controls on repositories 3. IDENTIFICATION AND AUTHENTICATION (11) 3.1 Naming 3.1.1 Types of names 3.1.2 Need for names to be meaningful 3.1.3 Anonymity or pseudonymity of subscribers 3.1.4 Rules for interpreting various name forms 3.1.5 Uniqueness of names 3.1.6 Recognition, authentication, and role of trademarks 3.2 Initial identity validation
1. INTRODUCTION 1.1 Overview 1.2 Document name and identification 1.3 PKI participants 1.3.1 Certification authorities 1.3.2 Registration authorities 1.3.3 Subscribers 1.3.4 Relying parties 1.3.5 Other participants 1.4 Certificate usage 1.4.1. Appropriate certificate uses 1.4.2 Prohibited certificate uses 1.5 Policy administration 1.5.1 Organization administering the document 1.5.2 Contact person 1.5.3 Person determining CPS suitability for the policy 1.5.4 CPS approval procedures 1.6 Definitions and acronyms 2. PUBLICATION AND REPOSITORY RESPONSIBILITIES 2.1 Repositories 2.2 Publication of certification information 2.3 Time or frequency of publication 2.4 Access controls on repositories 3. IDENTIFICATION AND AUTHENTICATION (11) 3.1 Naming 3.1.1 Types of names 3.1.2 Need for names to be meaningful 3.1.3 Anonymity or pseudonymity of subscribers 3.1.4 Rules for interpreting various name forms 3.1.5 Uniqueness of names 3.1.6 Recognition, authentication, and role of trademarks 3.2 Initial identity validation
Chokhani, et al. Informational [Page 54] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani, et al. Informational [Page 54] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
3.2.1 Method to prove possession of private key 3.2.2 Authentication of organization identity 3.2.3 Authentication of individual identity 3.2.4 Non-verified subscriber information 3.2.5 Validation of authority 3.2.6 Criteria for interoperation 3.3 Identification and authentication for re-key requests 3.3.1 Identification and authentication for routine re-key 3.3.2 Identification and authentication for re-key after revocation 3.4 Identification and authentication for revocation request 4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS (11) 4.1 Certificate Application 4.1.1 Who can submit a certificate application 4.1.2 Enrollment process and responsibilities 4.2 Certificate application processing 4.2.1 Performing identification and authentication functions 4.2.2 Approval or rejection of certificate applications 4.2.3 Time to process certificate applications 4.3 Certificate issuance 4.3.1 CA actions during certificate issuance 4.3.2 Notification to subscriber by the CA of issuance of certificate 4.4 Certificate acceptance 4.4.1 Conduct constituting certificate acceptance 4.4.2 Publication of the certificate by the CA 4.4.3 Notification of certificate issuance by the CA to other entities 4.5 Key pair and certificate usage 4.5.1 Subscriber private key and certificate usage 4.5.2 Relying party public key and certificate usage 4.6 Certificate renewal 4.6.1 Circumstance for certificate renewal 4.6.2 Who may request renewal 4.6.3 Processing certificate renewal requests 4.6.4 Notification of new certificate issuance to subscriber 4.6.5 Conduct constituting acceptance of a renewal certificate 4.6.6 Publication of the renewal certificate by the CA 4.6.7 Notification of certificate issuance by the CA to other entities 4.7 Certificate re-key 4.7.1 Circumstance for certificate re-key 4.7.2 Who may request certification of a new public key 4.7.3 Processing certificate re-keying requests 4.7.4 Notification of new certificate issuance to subscriber 4.7.5 Conduct constituting acceptance of a re-keyed certificate 4.7.6 Publication of the re-keyed certificate by the CA 4.7.7 Notification of certificate issuance by the CA to other entities
3.2.1 Method to prove possession of private key 3.2.2 Authentication of organization identity 3.2.3 Authentication of individual identity 3.2.4 Non-verified subscriber information 3.2.5 Validation of authority 3.2.6 Criteria for interoperation 3.3 Identification and authentication for re-key requests 3.3.1 Identification and authentication for routine re-key 3.3.2 Identification and authentication for re-key after revocation 3.4 Identification and authentication for revocation request 4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS (11) 4.1 Certificate Application 4.1.1 Who can submit a certificate application 4.1.2 Enrollment process and responsibilities 4.2 Certificate application processing 4.2.1 Performing identification and authentication functions 4.2.2 Approval or rejection of certificate applications 4.2.3 Time to process certificate applications 4.3 Certificate issuance 4.3.1 CA actions during certificate issuance 4.3.2 Notification to subscriber by the CA of issuance of certificate 4.4 Certificate acceptance 4.4.1 Conduct constituting certificate acceptance 4.4.2 Publication of the certificate by the CA 4.4.3 Notification of certificate issuance by the CA to other entities 4.5 Key pair and certificate usage 4.5.1 Subscriber private key and certificate usage 4.5.2 Relying party public key and certificate usage 4.6 Certificate renewal 4.6.1 Circumstance for certificate renewal 4.6.2 Who may request renewal 4.6.3 Processing certificate renewal requests 4.6.4 Notification of new certificate issuance to subscriber 4.6.5 Conduct constituting acceptance of a renewal certificate 4.6.6 Publication of the renewal certificate by the CA 4.6.7 Notification of certificate issuance by the CA to other entities 4.7 Certificate re-key 4.7.1 Circumstance for certificate re-key 4.7.2 Who may request certification of a new public key 4.7.3 Processing certificate re-keying requests 4.7.4 Notification of new certificate issuance to subscriber 4.7.5 Conduct constituting acceptance of a re-keyed certificate 4.7.6 Publication of the re-keyed certificate by the CA 4.7.7 Notification of certificate issuance by the CA to other entities
Chokhani, et al. Informational [Page 55] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani, et al. Informational [Page 55] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
4.8 Certificate modification 4.8.1 Circumstance for certificate modification 4.8.2 Who may request certificate modification 4.8.3 Processing certificate modification requests 4.8.4 Notification of new certificate issuance to subscriber 4.8.5 Conduct constituting acceptance of modified certificate 4.8.6 Publication of the modified certificate by the CA 4.8.7 Notification of certificate issuance by the CA to other entities 4.9 Certificate revocation and suspension 4.9.1 Circumstances for revocation 4.9.2 Who can request revocation 4.9.3 Procedure for revocation request 4.9.4 Revocation request grace period 4.9.5 Time within which CA must process the revocation request 4.9.6 Revocation checking requirement for relying parties 4.9.7 CRL issuance frequency (if applicable) 4.9.8 Maximum latency for CRLs (if applicable) 4.9.9 On-line revocation/status checking availability 4.9.10 On-line revocation checking requirements 4.9.11 Other forms of revocation advertisements available 4.9.12 Special requirements re key compromise 4.9.13 Circumstances for suspension 4.9.14 Who can request suspension 4.9.15 Procedure for suspension request 4.9.16 Limits on suspension period 4.10 Certificate status services 4.10.1 Operational characteristics 4.10.2 Service availability 4.10.3 Optional features 4.11 End of subscription 4.12 Key escrow and recovery 4.12.1 Key escrow and recovery policy and practices 4.12.2 Session key encapsulation and recovery policy and practices 5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS (11) 5.1 Physical controls 5.1.1 Site location and construction 5.1.2 Physical access 5.1.3 Power and air conditioning 5.1.4 Water exposures 5.1.5 Fire prevention and protection 5.1.6 Media storage 5.1.7 Waste disposal 5.1.8 Off-site backup 5.2 Procedural controls 5.2.1 Trusted roles 5.2.2 Number of persons required per task 5.2.3 Identification and authentication for each role
4.8 Certificate modification 4.8.1 Circumstance for certificate modification 4.8.2 Who may request certificate modification 4.8.3 Processing certificate modification requests 4.8.4 Notification of new certificate issuance to subscriber 4.8.5 Conduct constituting acceptance of modified certificate 4.8.6 Publication of the modified certificate by the CA 4.8.7 Notification of certificate issuance by the CA to other entities 4.9 Certificate revocation and suspension 4.9.1 Circumstances for revocation 4.9.2 Who can request revocation 4.9.3 Procedure for revocation request 4.9.4 Revocation request grace period 4.9.5 Time within which CA must process the revocation request 4.9.6 Revocation checking requirement for relying parties 4.9.7 CRL issuance frequency (if applicable) 4.9.8 Maximum latency for CRLs (if applicable) 4.9.9 On-line revocation/status checking availability 4.9.10 On-line revocation checking requirements 4.9.11 Other forms of revocation advertisements available 4.9.12 Special requirements re key compromise 4.9.13 Circumstances for suspension 4.9.14 Who can request suspension 4.9.15 Procedure for suspension request 4.9.16 Limits on suspension period 4.10 Certificate status services 4.10.1 Operational characteristics 4.10.2 Service availability 4.10.3 Optional features 4.11 End of subscription 4.12 Key escrow and recovery 4.12.1 Key escrow and recovery policy and practices 4.12.2 Session key encapsulation and recovery policy and practices 5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS (11) 5.1 Physical controls 5.1.1 Site location and construction 5.1.2 Physical access 5.1.3 Power and air conditioning 5.1.4 Water exposures 5.1.5 Fire prevention and protection 5.1.6 Media storage 5.1.7 Waste disposal 5.1.8 Off-site backup 5.2 Procedural controls 5.2.1 Trusted roles 5.2.2 Number of persons required per task 5.2.3 Identification and authentication for each role
Chokhani, et al. Informational [Page 56] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani, et al. Informational [Page 56] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
5.2.4 Roles requiring separation of duties 5.3 Personnel controls 5.3.1 Qualifications, experience, and clearance requirements 5.3.2 Background check procedures 5.3.3 Training requirements 5.3.4 Retraining frequency and requirements 5.3.5 Job rotation frequency and sequence 5.3.6 Sanctions for unauthorized actions 5.3.7 Independent contractor requirements 5.3.8 Documentation supplied to personnel 5.4 Audit logging procedures 5.4.1 Types of events recorded 5.4.2 Frequency of processing log 5.4.3 Retention period for audit log 5.4.4 Protection of audit log 5.4.5 Audit log backup procedures 5.4.6 Audit collection system (internal vs. external) 5.4.7 Notification to event-causing subject 5.4.8 Vulnerability assessments 5.5 Records archival 5.5.1 Types of records archived 5.5.2 Retention period for archive 5.5.3 Protection of archive 5.5.4 Archive backup procedures 5.5.5 Requirements for time-stamping of records 5.5.6 Archive collection system (internal or external) 5.5.7 Procedures to obtain and verify archive information 5.6 Key changeover 5.7 Compromise and disaster recovery 5.7.1 Incident and compromise handling procedures 5.7.2 Computing resources, software, and/or data are corrupted 5.7.3 Entity private key compromise procedures 5.7.4 Business continuity capabilities after a disaster 5.8 CA or RA termination 6. TECHNICAL SECURITY CONTROLS (11) 6.1 Key pair generation and installation 6.1.1 Key pair generation 6.1.2 Private key delivery to subscriber 6.1.3 Public key delivery to certificate issuer 6.1.4 CA public key delivery to relying parties 6.1.5 Key sizes 6.1.6 Public key parameters generation and quality checking 6.1.7 Key usage purposes (as per X.509 v3 key usage field) 6.2 Private Key Protection and Cryptographic Module Engineering Controls 6.2.1 Cryptographic module standards and controls 6.2.2 Private key (n out of m) multi-person control 6.2.3 Private key escrow
5.2.4 Roles requiring separation of duties 5.3 Personnel controls 5.3.1 Qualifications, experience, and clearance requirements 5.3.2 Background check procedures 5.3.3 Training requirements 5.3.4 Retraining frequency and requirements 5.3.5 Job rotation frequency and sequence 5.3.6 Sanctions for unauthorized actions 5.3.7 Independent contractor requirements 5.3.8 Documentation supplied to personnel 5.4 Audit logging procedures 5.4.1 Types of events recorded 5.4.2 Frequency of processing log 5.4.3 Retention period for audit log 5.4.4 Protection of audit log 5.4.5 Audit log backup procedures 5.4.6 Audit collection system (internal vs. external) 5.4.7 Notification to event-causing subject 5.4.8 Vulnerability assessments 5.5 Records archival 5.5.1 Types of records archived 5.5.2 Retention period for archive 5.5.3 Protection of archive 5.5.4 Archive backup procedures 5.5.5 Requirements for time-stamping of records 5.5.6 Archive collection system (internal or external) 5.5.7 Procedures to obtain and verify archive information 5.6 Key changeover 5.7 Compromise and disaster recovery 5.7.1 Incident and compromise handling procedures 5.7.2 Computing resources, software, and/or data are corrupted 5.7.3 Entity private key compromise procedures 5.7.4 Business continuity capabilities after a disaster 5.8 CA or RA termination 6. TECHNICAL SECURITY CONTROLS (11) 6.1 Key pair generation and installation 6.1.1 Key pair generation 6.1.2 Private key delivery to subscriber 6.1.3 Public key delivery to certificate issuer 6.1.4 CA public key delivery to relying parties 6.1.5 Key sizes 6.1.6 Public key parameters generation and quality checking 6.1.7 Key usage purposes (as per X.509 v3 key usage field) 6.2 Private Key Protection and Cryptographic Module Engineering Controls 6.2.1 Cryptographic module standards and controls 6.2.2 Private key (n out of m) multi-person control 6.2.3 Private key escrow
Chokhani, et al. Informational [Page 57] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani, et al. Informational [Page 57] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
6.2.4 Private key backup 6.2.5 Private key archival 6.2.6 Private key transfer into or from a cryptographic module 6.2.7 Private key storage on cryptographic module 6.2.8 Method of activating private key 6.2.9 Method of deactivating private key 6.2.10 Method of destroying private key 6.2.11 Cryptographic Module Rating 6.3 Other aspects of key pair management 6.3.1 Public key archival 6.3.2 Certificate operational periods and key pair usage periods 6.4 Activation data 6.4.1 Activation data generation and installation 6.4.2 Activation data protection 6.4.3 Other aspects of activation data 6.5 Computer security controls 6.5.1 Specific computer security technical requirements 6.5.2 Computer security rating 6.6 Life cycle technical controls 6.6.1 System development controls 6.6.2 Security management controls 6.6.3 Life cycle security controls 6.7 Network security controls 6.8 Time-stamping 7. CERTIFICATE, CRL, AND OCSP PROFILES 7.1 Certificate profile 7.1.1 Version number(s) 7.1.2 Certificate extensions 7.1.3 Algorithm object identifiers 7.1.4 Name forms 7.1.5 Name constraints 7.1.6 Certificate policy object identifier 7.1.7 Usage of Policy Constraints extension 7.1.8 Policy qualifiers syntax and semantics 7.1.9 Processing semantics for the critical Certificate Policies extension 7.2 CRL profile 7.2.1 Version number(s) 7.2.2 CRL and CRL entry extensions 7.3 OCSP profile 7.3.1 Version number(s) 7.3.2 OCSP extensions 8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS 8.1 Frequency or circumstances of assessment 8.2 Identity/qualifications of assessor 8.3 Assessor's relationship to assessed entity 8.4 Topics covered by assessment 8.5 Actions taken as a result of deficiency
6.2.4 Private key backup 6.2.5 Private key archival 6.2.6 Private key transfer into or from a cryptographic module 6.2.7 Private key storage on cryptographic module 6.2.8 Method of activating private key 6.2.9 Method of deactivating private key 6.2.10 Method of destroying private key 6.2.11 Cryptographic Module Rating 6.3 Other aspects of key pair management 6.3.1 Public key archival 6.3.2 Certificate operational periods and key pair usage periods 6.4 Activation data 6.4.1 Activation data generation and installation 6.4.2 Activation data protection 6.4.3 Other aspects of activation data 6.5 Computer security controls 6.5.1 Specific computer security technical requirements 6.5.2 Computer security rating 6.6 Life cycle technical controls 6.6.1 System development controls 6.6.2 Security management controls 6.6.3 Life cycle security controls 6.7 Network security controls 6.8 Time-stamping 7. CERTIFICATE, CRL, AND OCSP PROFILES 7.1 Certificate profile 7.1.1 Version number(s) 7.1.2 Certificate extensions 7.1.3 Algorithm object identifiers 7.1.4 Name forms 7.1.5 Name constraints 7.1.6 Certificate policy object identifier 7.1.7 Usage of Policy Constraints extension 7.1.8 Policy qualifiers syntax and semantics 7.1.9 Processing semantics for the critical Certificate Policies extension 7.2 CRL profile 7.2.1 Version number(s) 7.2.2 CRL and CRL entry extensions 7.3 OCSP profile 7.3.1 Version number(s) 7.3.2 OCSP extensions 8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS 8.1 Frequency or circumstances of assessment 8.2 Identity/qualifications of assessor 8.3 Assessor's relationship to assessed entity 8.4 Topics covered by assessment 8.5 Actions taken as a result of deficiency
Chokhani, et al. Informational [Page 58] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani, et al. Informational [Page 58] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
8.6 Communication of results 9. OTHER BUSINESS AND LEGAL MATTERS 9.1 Fees 9.1.1 Certificate issuance or renewal fees 9.1.2 Certificate access fees 9.1.3 Revocation or status information access fees 9.1.4 Fees for other services 9.1.5 Refund policy 9.2 Financial responsibility 9.2.1 Insurance coverage 9.2.2 Other assets 9.2.3 Insurance or warranty coverage for end-entities 9.3 Confidentiality of business information 9.3.1 Scope of confidential information 9.3.2 Information not within the scope of confidential information 9.3.3 Responsibility to protect confidential information 9.4 Privacy of personal information 9.4.1 Privacy plan 9.4.2 Information treated as private 9.4.3 Information not deemed private 9.4.4 Responsibility to protect private information 9.4.5 Notice and consent to use private information 9.4.6 Disclosure pursuant to judicial or administrative process 9.4.7 Other information disclosure circumstances 9.5 Intellectual property rights 9.6 Representations and warranties 9.6.1 CA representations and warranties 9.6.2 RA representations and warranties 9.6.3 Subscriber representations and warranties 9.6.4 Relying party representations and warranties 9.6.5 Representations and warranties of other participants 9.7 Disclaimers of warranties 9.8 Limitations of liability 9.9 Indemnities 9.10 Term and termination 9.10.1 Term 9.10.2 Termination 9.10.3 Effect of termination and survival 9.11 Individual notices and communications with participants 9.12 Amendments 9.12.1 Procedure for amendment 9.12.2 Notification mechanism and period 9.12.3 Circumstances under which OID must be changed 9.13 Dispute resolution provisions 9.14 Governing law 9.15 Compliance with applicable law 9.16 Miscellaneous provisions 9.16.1 Entire agreement
8.6 Communication of results 9. OTHER BUSINESS AND LEGAL MATTERS 9.1 Fees 9.1.1 Certificate issuance or renewal fees 9.1.2 Certificate access fees 9.1.3 Revocation or status information access fees 9.1.4 Fees for other services 9.1.5 Refund policy 9.2 Financial responsibility 9.2.1 Insurance coverage 9.2.2 Other assets 9.2.3 Insurance or warranty coverage for end-entities 9.3 Confidentiality of business information 9.3.1 Scope of confidential information 9.3.2 Information not within the scope of confidential information 9.3.3 Responsibility to protect confidential information 9.4 Privacy of personal information 9.4.1 Privacy plan 9.4.2 Information treated as private 9.4.3 Information not deemed private 9.4.4 Responsibility to protect private information 9.4.5 Notice and consent to use private information 9.4.6 Disclosure pursuant to judicial or administrative process 9.4.7 Other information disclosure circumstances 9.5 Intellectual property rights 9.6 Representations and warranties 9.6.1 CA representations and warranties 9.6.2 RA representations and warranties 9.6.3 Subscriber representations and warranties 9.6.4 Relying party representations and warranties 9.6.5 Representations and warranties of other participants 9.7 Disclaimers of warranties 9.8 Limitations of liability 9.9 Indemnities 9.10 Term and termination 9.10.1 Term 9.10.2 Termination 9.10.3 Effect of termination and survival 9.11 Individual notices and communications with participants 9.12 Amendments 9.12.1 Procedure for amendment 9.12.2 Notification mechanism and period 9.12.3 Circumstances under which OID must be changed 9.13 Dispute resolution provisions 9.14 Governing law 9.15 Compliance with applicable law 9.16 Miscellaneous provisions 9.16.1 Entire agreement
Chokhani, et al. Informational [Page 59] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani, et al. Informational [Page 59] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
9.16.2 Assignment 9.16.3 Severability 9.16.4 Enforcement (attorneys' fees and waiver of rights) 9.16.5 Force Majeure 9.17 Other provisions
9.16.2 Assignment 9.16.3 Severability 9.16.4 Enforcement (attorneys' fees and waiver of rights) 9.16.5 Force Majeure 9.17 Other provisions
7. Comparison to RFC 2527
7. Comparison to RFC 2527
This framework represents an incremental improvement over RFC 2527. The new framework benefits from the experience gained in the course of deploying CP and CPS documents under RFC 2527. Further, this new framework is based on coordination with the American Bar Association Information Security Committee within the Section of Science and Technology Law. The ISC wrote the PKI Assessment Guidelines [ABA2], which embodies a great deal of technical, business, and legal experience in PKI operations. In particular, representatives of the ISC made changes to the framework to better suite it to the legal environment and make it more accessible to lawyers.
This framework represents an incremental improvement over RFC 2527. The new framework benefits from the experience gained in the course of deploying CP and CPS documents under RFC 2527. Further, this new framework is based on coordination with the American Bar Association Information Security Committee within the Section of Science and Technology Law. The ISC wrote the PKI Assessment Guidelines [ABA2], which embodies a great deal of technical, business, and legal experience in PKI operations. In particular, representatives of the ISC made changes to the framework to better suite it to the legal environment and make it more accessible to lawyers.
>From a technical perspective, the changes to the RFC 2527 framework were minimal and incremental, rather than revolutionary. Sections 3-7 have largely been preserved, with modest reorganization and new topics. For example, the new framework includes a revision of Section 4 of the framework to include a full treatment of the certificate life-cycle, the addition of key escrow, key encapsulation, and key recovery policies and practices, and OCSP. Section 2 audit functions now appear alone in Section 8, and Section 2 focuses exclusively on repository functions. The business and legal matters in RFC 2527's Section 2 now appear in a new Section 9.
>From a technical perspective, the changes to the RFC 2527 framework were minimal and incremental, rather than revolutionary. Sections 3-7 have largely been preserved, with modest reorganization and new topics. For example, the new framework includes a revision of Section 4 of the framework to include a full treatment of the certificate life-cycle, the addition of key escrow, key encapsulation, and key recovery policies and practices, and OCSP. Section 2 audit functions now appear alone in Section 8, and Section 2 focuses exclusively on repository functions. The business and legal matters in RFC 2527's Section 2 now appear in a new Section 9.
From a legal perspective, the new Section 9 is useful because it places topics in the framework in an ordering that is similar to software licensing and other technology agreements and thus is familiar to technology lawyers. Moreover, the framework as a whole can double as a framework for a subscriber, relying party, or other PKI-related agreement. The changes are intended to make legal review of, and input into, CP and CPS documents more efficient. Section 9 also adds new legal topics, such as the privacy of personal information, liability terms, and duration of the effectiveness of the document.
From a legal perspective, the new Section 9 is useful because it places topics in the framework in an ordering that is similar to software licensing and other technology agreements and thus is familiar to technology lawyers. Moreover, the framework as a whole can double as a framework for a subscriber, relying party, or other PKI-related agreement. The changes are intended to make legal review of, and input into, CP and CPS documents more efficient. Section 9 also adds new legal topics, such as the privacy of personal information, liability terms, and duration of the effectiveness of the document.
Section 1 of the new framework is largely the same as RFC 2527, although it increases coverage of PKI participants by breaking out subscribers from relying parties and adding a section for other participants. It changes the "applicability" section to one covering appropriate and prohibited uses of certificates. Also, it moves CPS
新しい枠組みのセクション1はRFC2527と主に同じです、信用パーティーから加入者を開けて、他の関係者のためにセクションを加えることによって、PKI関係者の適用範囲を増加させますが。 それは、証明書の適切で禁止された用途をカバーしながら、「適用性」セクションを1つに変えます。 また、それはCPSを動かします。
Chokhani, et al. Informational [Page 60] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [60ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
approval procedures from RFC 2527's Section 8.3 into a collected policy administration section. Finally, Section 1.6 adds a place to list definitions and acronyms.
集まっている方針管理部へのRFC2527のセクション8.3からの承認の手順。 最終的に、セクション1.6は定義と頭文字語を記載する場所を加えます。
Section 2 of the new framework is a reorganization of Section 2.6 of the old framework. Section 3 of the new framework is based on a division of the old Section 3.1 into two parts for naming and identification and authentication issues. It adds new issues, such as the permissibility of pseudonyms and anonymity. Old Section 4 topics on audit logging, record archives, key changeover, compromise and disaster recovery, and CA termination have moved to Section 5. The remaining Section 4 topics have been expanded and reorganized to cover a complete certificate lifecycle. New topics include items implicit in the RFC 2527 Section 4, but now explicit, such as certificate application processing, certificate modification, and the end of subscription.
新しい枠組みのセクション2は古い枠組みのセクション2.6の再編成です。 新しい枠組みのセクション3は命名、識別、および認証問題のための2つの部品への古いセクション3.1の師団に基づいています。 それは匿名と匿名のpermissibilityなどの新規発行を加えます。 古いセクション4 監査伐採での話題、記録的なアーカイブ、主要な転換、妥協、災害復旧、およびカリフォルニアの終了はセクション5に動きました。 残っているセクション4話題は、完全な証明書lifecycleを覆うために広げられて、再編成されました。 新しい話題は購読の証明書手続きの経緯や、証明書変更や、終わりなどのようにRFC2527セクション4の暗黙の、しかし、現在明白な項目を含んでいます。
New Sections 5.1 through 5.3 are almost identical to their counterparts in RFC 2527. The remainder of the new Section 5 is the topics moved from RFC 2527's Section 4, in the order that they appeared in Section 4. Section 6 of the new framework is almost the same as the old Section 6, with some exceptions, such as the consolidation of old Section 6.8 (cryptographic module engineering controls) into Section 6.2.1 (now called "cryptographic module standards and controls") and the addition of time-stamping in a new Section 6.8. Section 7 is almost identical to the old Section 7, the major change being the addition of a section covering OCSP profile. Section 8 is almost identical to RFC 2527's Section 2.7.
RFC2527の彼らの対応者にとって、新しいセクション5.1〜5.3はほとんど同じです。 新しいセクション5の残りはオーダーでRFC2527のセクション4からセクション4に現れたのが動かされた話題です。 新しい枠組みのセクション6は古いセクション6とほとんど同じです、若干の例外はあるものの、セクション6.2.1(現在、「暗号のモジュール規格とコントロール」と呼ばれる)への古いセクション6.8(暗号のモジュール工学コントロール)の強化や新しいセクション6.8における、時間の刻印の添加のように。 セクション7は古いセクション7(セクション覆いOCSPプロフィールの添加である大きな変化)とほとんど同じです。 セクション8はRFC2527のセクション2.7とほとんど同じです。
New Section 9 contains business and legal topics that were covered in RFC 2527's Section 2, including fees, financial responsibility, confidentiality, and intellectual property. It adds a section on the privacy of personal information, which has become a significant policy issue. The "liability" Section 2.2 in RFC 2527 now appears in Sections 9.6 through 9.9, covering representations and warranties, disclaimers, limitations of liability, and indemnities. Section 9.10 adds a section concerning the duration of the effectiveness of documentation. Section 9.12 collects terms concerning the way in which a document (CP, CPS, agreement, or other document) may be amended, formerly appearing in Section 8.1. Section 9 includes "legal boilerplate" topics, some of which were in the old Section 2. Finally, Section 9.17 is a catch-all "other provisions" section where drafters can place information that does not fit well into any other section of the framework.
新しいセクション9はRFC2527のセクション2で含まれていたビジネスと法的な話題を含みます、料金、金融責任、秘密性、および知的所有権を含んでいて。 それは個人情報の秘密のセクションを加えます。(個人情報の秘密は重要な政策問題になりました)。 RFC2527の「責任」セクション2.2は今セクション9.6〜9.9に現れます、表明保証条項、注意書き、責任の制限、および保障を含んでいて。 セクション9.10はドキュメンテーションの有効性の持続時間に関してセクションを加えます。 セクション9.12はドキュメント(CP、CPS、協定、または他のドキュメント)が修正されるかもしれない方法に関して用語を集めます、以前セクション8.1に現れて。 セクション9は「法律上の決まり文句」話題を含めます。その或るものは古いセクション2にありました。 最終的に、セクション9.17はドラフターが枠組みのいかなる他のセクションにもよく収まらない情報を置くことができるキャッチすべて、「他の条項」部です。
The following matrix shows the sections in the old RFC 2527 framework and their successor sections in the new framework.
以下のマトリクスは新しい枠組みで古いRFC2527枠組みにおけるセクションとそれらの後継者部を示しています。
Chokhani, et al. Informational [Page 61] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [61ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
ORIGINAL RFC 2527 NEW RFC SECTION
SECTION
------------------------------------------------------
1. Introduction 1.
------------------------------------------------------
1.1 Overview 1.1
------------------------------------------------------
1.2 Identification 1.2
------------------------------------------------------
1.3 Community and
Applicability 1.3
------------------------------------------------------
1.3.1 Certification
Authorities 1.3.1
------------------------------------------------------
1.3.2 Registration Authorities 1.3.2
------------------------------------------------------
1.3.3 End entities 1.3.3,
1.3.4
------------------------------------------------------
1.3.4 Applicability 1.4, 4.5
------------------------------------------------------
1.4 Contact Details 1.5
------------------------------------------------------
1.4.1 Specification Administration
Organization 1.5.1
------------------------------------------------------
1.4.2 Contact Person 1.5.2
------------------------------------------------------
1.4.3 Person Determining CPS
Suitability for the Policy 1.5.3
------------------------------------------------------
2. General Provisions 2, 8, 9
------------------------------------------------------
2.1 Obligations 2.6.4
------------------------------------------------------
2.1.1 1A Obligations Integrated
throughout
portions of the
framework that
apply to CAs
------------------------------------------------------
2.1.2 RA Obligations Integrated
throughout
portions of the
framework that
apply to RAs
オリジナルのRFC2527の新しいRFCセクション部分------------------------------------------------------ 1. 序論1。 ------------------------------------------------------ 1.1 概観1.1------------------------------------------------------ 1.2 識別1.2------------------------------------------------------ 1.3 共同体と適用性1.3------------------------------------------------------ 1.3.1 証明当局1.3.1------------------------------------------------------ 1.3.2 登録局1.3.2------------------------------------------------------ 1.3.3 終わり実体1.3.3、1.3の.4------------------------------------------------------ 1.3.4 適用性1.4、4.5------------------------------------------------------ 1.4 連絡の詳細1.5------------------------------------------------------ 1.4.1 仕様政権組織1.5.1------------------------------------------------------ 1.4.2 連絡窓口1.5の.2------------------------------------------------------ 1.4.3 方針1.5.3へのCPS適合を決定する人------------------------------------------------------ 2. 予算総則2、8、9------------------------------------------------------ 2.1 義務2.6.4------------------------------------------------------ 2.1.1 1 CAsに適用される枠組みの部分中のObligations Integrated------------------------------------------------------ 2.1.2 RAsに適用される枠組みの部分中のRA Obligations Integrated
Chokhani, et al. Informational [Page 62] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [62ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
------------------------------------------------------
2.1.3 Subscriber Obligations 4.1.2, 4.4, 4.5,
4.5.1, 4.6.5,
4.7.5, 4.8.1,
4.8.5, 4.9.1,
4.9.2, 4.9.13,
4.9.15, 5., 6.,
9.6.3, 9.9
------------------------------------------------------
2.1.4 Relying Party Obligations 4.5, 4.5.2, 4.9.6,
5., 6., 9.6.4, 9.9
------------------------------------------------------
2.1.5 Repository Obligations 2., 4.4.2, 4.4.3,
4.6.6, 4.6.7,
4.7.6, 4.7.7,
4.8.6, 4.8.7
------------------------------------------------------
2.2 Liability 9.6, 9.7, 9.8, 9.9
------------------------------------------------------
2.2.1 CA Liability 9.6.1, 9.7., 9.8,
9.9
------------------------------------------------------
2.2.2 RA Liability 9.6.2, 9.7, 9.8, 9.9
------------------------------------------------------
2.3 Financial Responsibility 9.2
------------------------------------------------------
2.3.1 Indemnification by Relying
Parties 9.9
------------------------------------------------------
2.3.2 Fiduciary Relationships 9.7
------------------------------------------------------
2.4 Interpretation and Enforcement 9.16
------------------------------------------------------
2.4.1 Governing Law 9.14, 9.15
------------------------------------------------------
2.4.2 Severability, Survival,
Merger, Notice 9.10.3, 9.11,
9.16.1,9.16.3
------------------------------------------------------
2.4.3 Dispute Resolution
Procedures 9.13, 9.16.4
------------------------------------------------------
2.5 Fees 9.1
------------------------------------------------------
2.5.1 Certificate Issuance
or Renewal Fees 9.1.1
------------------------------------------------------
2.5.2 Certificate Access Fees 9.1.2
------------------------------------------------------ 2.1.3 加入者義務、4.1、.2、4.4 4.5 4.5 .1 4.6 .5 4.7 .5 4.8 .1 4.8 .5 4.9 .1 4.9 .2 4.9 .13 4.9 .15 5.、6.、9.6、.3、9.9------------------------------------------------------ 2.1.4 信用パーティ義務4.5、4.5.2、4.9.6、5.、6.、9.6、.4、9.9------------------------------------------------------ 2.1.5 倉庫義務2.、4.4、.2、4.4 .3 4.6 .6 4.6 .7 4.7 .6 4.7 .7 4.8 .6、4.8、.7------------------------------------------------------ 2.2 責任9.6、9.7、9.8、9.9------------------------------------------------------ 2.2.1 カリフォルニア責任9.6.1、9.8と、9.9の9.7.------------------------------------------------------ 2.2.2 RA責任9.6.2、9.7、9.8、9.9------------------------------------------------------ 2.3 金融責任9.2------------------------------------------------------ 2.3.1 当てにしている党9.9による保障------------------------------------------------------ 2.3.2 信用上の関係9.7------------------------------------------------------ 2.4 解釈と実施9.16------------------------------------------------------ 2.4.1 準拠法9.14、9.15------------------------------------------------------ 2.4.2 Severability、生存、合併、9.11と、9.16の通知9.10.3、.1、9.16、.3------------------------------------------------------ 2.4.3 論争の解決手順9.13、9.16.4------------------------------------------------------ 2.5 料金9.1------------------------------------------------------ 2.5.1 証明書発行か更新料9.1.1------------------------------------------------------ 2.5.2 証明書アクセスチャージ9.1.2
Chokhani, et al. Informational [Page 63] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [63ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
------------------------------------------------------
2.5.3 Revocation or Status
Information Access Fees 9.1.3
------------------------------------------------------
2.5.4 Fees for Other Services Such
as Policy Information 9.1.4
------------------------------------------------------
2.5.5 Refund Policy 9.1.5
------------------------------------------------------
2.6 Publication and Repository 2.
------------------------------------------------------
2.6.1 Publication of CA
Information 2.2, 4.4.2,
4.4.3, 4.6.6,
4.6.7, 4.7.6,
4.7.7, 4.8.6,
4.8.7
------------------------------------------------------
2.6.2 Frequency of Publication 2.3
------------------------------------------------------
2.6.3 Access Controls 2.4
------------------------------------------------------
2.6.4 Repositories 2.1
------------------------------------------------------
2.7 Compliance Audit 8.
------------------------------------------------------
2.7.1 Frequency of Entity Compliance
Audit 8.1
------------------------------------------------------
2.7.2 Identity/Qualifications of
Auditor 8.2
------------------------------------------------------
2.7.3 Auditor's Relationship to Audited
Party 8.3
------------------------------------------------------
2.7.4 Topics Covered by Audit 8.4
------------------------------------------------------
2.7.5 Actions Taken as a Result of
Deficiency 8.5
------------------------------------------------------
2.7.6 Communications of Results 8.6
------------------------------------------------------
2.8 Confidentiality 9.3, 9.4
------------------------------------------------------
2.8.1 Types of Information to be
Kept Confidential 9.3.1, 9.4.2
------------------------------------------------------ 2.5.3 取消しか状態情報アクセスチャージ9.1.3------------------------------------------------------ 2.5.4 方針情報9.1.4などの他のサービスのための料金------------------------------------------------------ 2.5.5 代金返却方針9.1.5------------------------------------------------------ 2.6 公表と倉庫2。 ------------------------------------------------------ 2.6.1 カリフォルニア情報の公表、2.2 4.4 .2 4.4 .3 4.6 .6 4.6 .7 4.7 .6 4.7 .7 4.8 .6、4.8、.7------------------------------------------------------ 2.6.2 公表2.3の頻度------------------------------------------------------ 2.6.3 アクセス管理2.4------------------------------------------------------ 2.6.4 倉庫2.1------------------------------------------------------ 2.7 承諾監査8。 ------------------------------------------------------ 2.7.1 実体承諾監査8.1の頻度------------------------------------------------------ 2.7.2 監査役8.2のアイデンティティ/資格------------------------------------------------------ 2.7.3 監査のパーティ8.3との監査役の関係------------------------------------------------------ 2.7.4 監査8.4でカバーされた話題------------------------------------------------------ 2.7.5 欠乏8.5の結果、取られた行動------------------------------------------------------ 2.7.6 結果8.6に関するコミュニケーション------------------------------------------------------ 2.8 秘密性9.3、9.4------------------------------------------------------ 2.8.1、情報はKept Confidential9.3.1、9.4が.2であったならタイプされます。
Chokhani, et al. Informational [Page 64] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [64ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
------------------------------------------------------
2.8.2 Types of Information Not
Considered Confidential 9.3.2, 9.4.3
------------------------------------------------------
2.8.3 Disclosure of Certificate
Revocation/Suspension
Information 9.3.1, 9.3.2,
9.3.3, 9.4.2,
9.4.3, 9.4.4
------------------------------------------------------
2.8.4 Release to Law Enforcement
Officials 9.3.3, 9.4.6
------------------------------------------------------
2.8.5 Release as Part of Civil
Discovery 9.3.3, 9.4.6
------------------------------------------------------
2.8.6 Disclosure Upon Owner's
Request 9.3.3, 9.4.7
------------------------------------------------------
2.8.7 Other Information Release
Circumstances 9.3.3, 9.4.7
------------------------------------------------------
2.9 Intellectual Property Rights 9.5
------------------------------------------------------
3. Identification and Authentication 3.
------------------------------------------------------
3.1 Initial Registration 3.1, 3.2
------------------------------------------------------
3.1.1 Type of Names 3.1.1
------------------------------------------------------
3.1.2 Need for Names to be
Meaningful 3.1.2, 3.1.3
------------------------------------------------------
3.1.3 Rules for Interpreting
Various Name Forms 3.1.4
------------------------------------------------------
3.1.4 Uniqueness of Names 3.1.5
------------------------------------------------------
3.1.5 Name Claim Dispute
Resolution Procedure 3.1.6
------------------------------------------------------
3.1.6 Recognition, Authentication,
and Role of Trademarks 3.1.6
------------------------------------------------------
3.1.7 Method to Prove Possession
of Private Key 3.2.1
------------------------------------------------------ 2.8.2 情報のタイプが、.2、9.4であると秘密の9.3に考えなかった、.3------------------------------------------------------ 2.8.3 証明書取消し/サスペンション情報の公開、9.3、.1、9.3 .2 9.3 .3 9.4 .2 9.4 .3、9.4、.4------------------------------------------------------ 2.8.4 取締官9.3.3、9.4に.6をリリースしてください。------------------------------------------------------ 2.8.5 民間発見9.3.3、9.4の一部として、.6をリリースしてください。------------------------------------------------------ 2.8.6 要求9.3.3、所有者の9.4での公開、.7------------------------------------------------------ 2.8.7 他の情報リリース事情9.3.3、9.4.7------------------------------------------------------ 2.9 知的所有権9.5------------------------------------------------------ 3. 識別と認証3。 ------------------------------------------------------ 3.1 新規登録3.1、3.2------------------------------------------------------ 3.1.1 名前3.1.1人のタイプ------------------------------------------------------ 3.1.2 NamesがMeaningful3.1.2、3.1である必要性、.3------------------------------------------------------ 3.1.3 解釈するのに、様々な規則はフォーム3.1を.4と命名します。------------------------------------------------------ 3.1.4 名前3.1.5のユニークさ------------------------------------------------------ 3.1.5 名前クレーム論争の解決手順3.1.6------------------------------------------------------ 3.1.6 商標3.1.6の認識、認証、および役割------------------------------------------------------ 3.1.7 秘密鍵3.2.1の所有物を立証する方法
Chokhani, et al. Informational [Page 65] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [65ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
------------------------------------------------------
3.1.8 Authentication of
Organization Identity 3.2.2
------------------------------------------------------
3.1.9 Authentication of
Individual Identity 3.2.3
------------------------------------------------------
3.2 Routine Rekey 3.3.1, 4.6, 4.7
------------------------------------------------------
3.3 Rekey After Revocation 3.3.2
------------------------------------------------------
3.4 Revocation Request 3.4
------------------------------------------------------
4. Operational Requirements 4., 5.
------------------------------------------------------
4.1 Certificate Application 4.1, 4.2, 4.6,
4.7
------------------------------------------------------
4.2 Certificate Issuance 4.2, 4.3, 4.4.3,
4.6, 4.7, 4.8.4,
4.8.6, 4.8.7
------------------------------------------------------
4.3 Certificate Acceptance 4.3.2, 4.4, 4.6,
4.7, 4.8.4-4.8.7
------------------------------------------------------
4.4 Certificate Suspension
and Revocation 4.8, 4.9
------------------------------------------------------
4.4.1 Circumstances for Revocation 4.8.1, 4.9.1
------------------------------------------------------
4.4.2 Who Can Request Revocation 4.8.2, 4.9.2
------------------------------------------------------
4.4.3 Procedure for Revocation
Request 4.8.3-4.8.7,
4.9.3
------------------------------------------------------
4.4.4 Revocation Request
Grace Period 4.9.4
------------------------------------------------------
4.4.5 Circumstances for Suspension 4.9.13
------------------------------------------------------
4.4.6 Who Can Request Suspension 4.9.14
------------------------------------------------------
4.4.7 Procedure for Suspension
Request 4.9.15
------------------------------------------------------
4.4.8 Limits on Suspension Period 4.9.16
------------------------------------------------------ 3.1.8 組織のアイデンティティ3.2.2の認証------------------------------------------------------ 3.1.9 個々のアイデンティティ3.2.3の認証------------------------------------------------------ 3.2 通常のRekey3.3.1、4.6、4.7------------------------------------------------------ 3.3 取消し3.3.2の後のRekey------------------------------------------------------ 3.4 取消し要求3.4------------------------------------------------------ 4. 操作上の要件4.、5。 ------------------------------------------------------ 4.1 証明書アプリケーション4.1、4.2、4.6、4.7------------------------------------------------------ 4.2証明書発行4.2、4.3、4.4.3、4.6、4.7、4.8.4、4.8、.6、4.8、.7------------------------------------------------------ 4.3 証明書承認4.3.2、4.4、4.6、4.7、4.8.4-4.8.7------------------------------------------------------ 4.4 証明書サスペンションと取消し4.8、4.9------------------------------------------------------ 4.4.1 取消し4.8.1、4.9のための事情、.1------------------------------------------------------ 4.4.2 だれが取消し4.8.2、4.9を要求できるか、.2------------------------------------------------------ 4.4.3 取消し要求4.8.3-4.8.7、4.9.3のための手順------------------------------------------------------ 4.4.4 取消し要求据置期間4.9の.4------------------------------------------------------ 4.4.5 サスペンション4.9.13のための事情------------------------------------------------------ 4.4.6 だれがサスペンション4.9.14を要求できますか?------------------------------------------------------ 4.4.7 サスペンション要求4.9.15のための手順------------------------------------------------------ 4.4.8 休職期間4.9.16における限界
Chokhani, et al. Informational [Page 66] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [66ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
------------------------------------------------------
4.4.9 CRL Issuance Frequency
(If Applicable) 4.9.7, 4.9.8,
4.10
------------------------------------------------------
4.4.10 CRL Checking Requirements 4.9.6, 4.10
------------------------------------------------------
4.4.11 On-Line Revocation/
Status Checking
Availability 4.9.9, 4.10
------------------------------------------------------
4.4.12 On-Line Revocation
Checking Requirements 4.9.6, 4.9.10,
4.10
------------------------------------------------------
4.4.13 Other Forms
of Revocation
Advertisements 4.9.11, 4.10
------------------------------------------------------
4.4.14 Checking Requirements
for Other Forms of
Revocation
Advertisements 4.9.6, 4.9.11,
4.10
------------------------------------------------------
4.4.15 Special Requirements re
Key Compromise 4.9.12
------------------------------------------------------
4.5 Security Audit Procedures 5.4
------------------------------------------------------
4.5.1 Types of Events Recorded 5.4.1
------------------------------------------------------
4.5.2 Frequency of Processing Log 5.4.2
------------------------------------------------------
4.5.3 Retention Period for Audit
Log 5.4.3
------------------------------------------------------
4.5.4 Protection of Audit Log 5.4.4
------------------------------------------------------
4.5.5 Audit Log Backup Procedures 5.4.5
------------------------------------------------------
4.5.6 Audit Collection System
(Internal vs. External) 5.4.6
------------------------------------------------------
4.5.7 Notification to Event-Causing
Subject 5.4.7
------------------------------------------------------
4.5.8 Vulnerability Assessments 5.4.8
------------------------------------------------------ 4.4.9 CRL発行頻度(適切であるなら)4.9.7、4.9.8、4.10------------------------------------------------------ 4.4.10 要件4.9.6、4.10をチェックするCRL------------------------------------------------------ 4.4.11 有用性4.9.9、4.10をチェックするオンライン取消し/状態------------------------------------------------------ 4.4.12 要件4.9.6、4.9をチェックするオンライン取消し、.10、4.10------------------------------------------------------ 4.4.13 取消し広告4.9.11、他の4.10のフォーム------------------------------------------------------ 4.4.14 取消し広告4.9.6、4.9.11、他の4.10のフォームのための要件をチェックすること。------------------------------------------------------ 4.4.15 Key Compromise4.9.12に関して特別なRequirements------------------------------------------------------ 4.5 セキュリティ監査手順5.4------------------------------------------------------ 4.5.1 出来事のタイプは5.4に.1を記録しました。------------------------------------------------------ 4.5.2 処理ログ5.4.2の頻度------------------------------------------------------ 4.5.3 監査ログ5.4.3のための保有の期間------------------------------------------------------ 4.5.4 監査ログ5.4.4の保護------------------------------------------------------ 4.5.5 監査ログバックアップ手順5.4.5------------------------------------------------------ 4.5.6 監査収集システム(外部に対して内部の)5.4.6------------------------------------------------------ 4.5.7 イベント引き起こす対象5.4.7への通知------------------------------------------------------ 4.5.8 弱点査定5.4.8
Chokhani, et al. Informational [Page 67] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [67ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
------------------------------------------------------
4.6 Records Archival 5.5
------------------------------------------------------
4.6.1 Types of Records Archived 5.5.1
------------------------------------------------------
4.6.2 Retention Period for Archive 5.5.2
------------------------------------------------------
4.6.3 Protection of Archive 5.5.3
------------------------------------------------------
4.6.4 Archive Backup Procedures 5.5.4
------------------------------------------------------
4.6.5 Requirements for
Time-Stamping of Records 5.5.5
------------------------------------------------------
4.6.6 Archive Collection System
(Internal or External) 5.5.6
------------------------------------------------------
4.6.6 Procedures to Obtain and
Verify Archive Information 5.5.7
------------------------------------------------------
4.7 Key Changeover 5.6
------------------------------------------------------
4.8 Compromise and Disaster
Recovery 5.7, 5.7.1
------------------------------------------------------
4.8.1 Computing Resources, Software,
and/or Data Are Corrupted 5.7.2
------------------------------------------------------
4.8.2 Entity Public
Key is Revoked 4.9.7, 4.9.9,
4.9.11
------------------------------------------------------
4.8.3 Entity Key is Compromised 5.7.3
------------------------------------------------------
4.8.4 Secure Facility After a Natural
or Other Type of Disaster 5.7.4
------------------------------------------------------
4.9 CA Termination 5.8
------------------------------------------------------
5. Physical, Procedural, and
Personnel Security Controls 5.
------------------------------------------------------
5.1 Physical Controls 5.1
------------------------------------------------------
5.1.1 Site Location and Construction 5.1.1
------------------------------------------------------
5.1.2 Physical Access 5.1.2
------------------------------------------------------ 4.6は記録保管所の5.5を記録します。------------------------------------------------------ 4.6.1 記録のタイプは5.5に.1を格納しました。------------------------------------------------------ 4.6.2 アーカイブ5.5.2のための保有の期間------------------------------------------------------ 4.6.3 アーカイブ5.5.3の保護------------------------------------------------------ 4.6.4 アーカイブバックアップ手順5.5.4------------------------------------------------------ 4.6.5 記録5.5.5の時間の刻印のための要件------------------------------------------------------ 4.6.6 収集システム(内部か外部)の5.5.6を格納してください。------------------------------------------------------ 4.6.6 得て、確かめる手順は情報5.5.7を格納します。------------------------------------------------------ 4.7 主要な転換5.6------------------------------------------------------ 4.8 妥協と災害復旧5.7、5.7.1------------------------------------------------------ 4.8.1 コンピューティング資源、ソフトウェア、そして/または、データが5.7に崩壊する、.2------------------------------------------------------ 4.8.2 実体Public KeyがRevoked4.9.7、4.9である、.9、4.9、.11------------------------------------------------------ 4.8.3 実体KeyはCompromised5.7.3です。------------------------------------------------------ 4.8.4 .4の自然であるか他の災害5.7タイプの後の安全な施設------------------------------------------------------ 4.9 カリフォルニアの終了5.8------------------------------------------------------ 5. 物理的、そして、手続き上、および人的安全保護は5を制御します。 ------------------------------------------------------ 5.1 物理的なコントロール5.1------------------------------------------------------ 5.1.1 立地と工事5.1.1------------------------------------------------------ 5.1.2 物理的なアクセス5.1.2
Chokhani, et al. Informational [Page 68] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [68ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
------------------------------------------------------ 5.1.3 Power and Air Conditioning 5.1.3 ------------------------------------------------------
------------------------------------------------------ 5.1.3 パワーと空調5.1.3------------------------------------------------------
5.1.4 Water Exposures 5.1.4
------------------------------------------------------
5.1.5 Fire Prevention and Protection 5.1.5
------------------------------------------------------
5.1.6 Media Storage 5.1.6
------------------------------------------------------
5.1.7 Waste Disposal 5.1.7
------------------------------------------------------
5.1.8 Off-Site Backup 5.1.8
------------------------------------------------------
5.2 Procedural Controls 5.2
------------------------------------------------------
5.2.1 Trusted Roles 5.2.1, 5.2.4
------------------------------------------------------
5.2.2 Number of Persons
Required per Task 5.2.2, 5.2.4
------------------------------------------------------
5.2.3 Identification and
Authentication for Each Role 5.2.3
------------------------------------------------------
5.3 Personnel Controls 5.3
------------------------------------------------------
5.3.1 Background, Qualifications,
Experience, and Clearance
Requirements 5.3.1
------------------------------------------------------
5.3.2 Background Check Procedures 5.3.2
------------------------------------------------------
5.3.3 Training Requirements 5.3.3
------------------------------------------------------
5.3.4 Retraining Frequency
and Requirements 5.3.4
------------------------------------------------------
5.3.5 Job Rotation Frequency
and Sequence 5.3.5
------------------------------------------------------
5.3.6 Sanctions for
Unauthorized Actions 5.3.6
------------------------------------------------------
5.3.7 Contracting Personnel
Requirements 5.3.7
------------------------------------------------------
5.3.8 Documentation Supplied to
Personnel 5.3.8
5.1.4 水の露出5.1.4------------------------------------------------------ 5.1.5 防火と保護5.1.5------------------------------------------------------ 5.1.6 メディア格納5.1.6------------------------------------------------------ 5.1.7 ゴミ処理5.1.7------------------------------------------------------ 5.1.8 オフサイトバックアップ5.1.8------------------------------------------------------ 5.2 手続き上のコントロール5.2------------------------------------------------------ 5.2.1 信じられた役割5.2.1、5.2、.4------------------------------------------------------ 5.2.2 人員はタスク5.2.2、5.2単位で.4を必要としました。------------------------------------------------------ 5.2.3 それぞれの役割5.2の.3のための識別と認証------------------------------------------------------ 5.3人の人員が5.3を制御します。------------------------------------------------------ 5.3.1 バックグラウンド、資格、経験、およびクリアランス要件5.3.1------------------------------------------------------ 5.3.2 素性調査手順5.3.2------------------------------------------------------ 5.3.3 トレーニング要件5.3.3------------------------------------------------------ 5.3.4 再教育頻度と要件5.3.4------------------------------------------------------ 5.3.5 ジョブローテーション頻度と系列5.3.5------------------------------------------------------ 5.3.6 権限のない動作5.3.6のための制裁------------------------------------------------------ 5.3.7 契約人材の条件5.3.7------------------------------------------------------ 5.3.8 人員5.3.8に供給されたドキュメンテーション
Chokhani, et al. Informational [Page 69] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [69ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
------------------------------------------------------
6. Technical Security Controls 6.
------------------------------------------------------
6.1 Key Pair Generation and
Installation 6.1
------------------------------------------------------
6.1.1 Key Pair Generation 6.1.1
------------------------------------------------------
6.1.2 Private Key Delivery to Entity 6.1.2
------------------------------------------------------
6.1.3 Public Key Delivery to
Certificate Issuer 6.1.3
------------------------------------------------------
6.1.4 CA Public Key Delivery to Users 6.1.4
------------------------------------------------------
6.1.5 Key Sizes 6.1.5
------------------------------------------------------
6.1.6 Public Key Parameters Generation 6.1.6
------------------------------------------------------
6.1.7 Parameter Quality Checking 6.1.6
------------------------------------------------------
6.1.8 Hardware/Software Key Generation 6.1.1
------------------------------------------------------
6.1.9 Key Usage Purposes
(as per X.509 v3 Key Usage Field) 6.1.9
------------------------------------------------------
6.2 Private Key Protection 6.2
------------------------------------------------------
6.2.1 Standards for Cryptographic
Module 6.2.1
------------------------------------------------------
------------------------------------------------------ 6. 技術的なセキュリティは6を制御します。 ------------------------------------------------------ 6.1 主要な組世代とインストール6.1------------------------------------------------------ 6.1.1 主要な組世代6.1.1------------------------------------------------------ 6.1.2 実体6.1.2への秘密鍵配送------------------------------------------------------ 6.1.3 発行人6.1.3を証明する公開鍵配送------------------------------------------------------ 6.1.4 ユーザ6.1.4へのカリフォルニアの公開鍵配送------------------------------------------------------ 6.1.5 主要なサイズ6.1.5------------------------------------------------------ 6.1.6 公開鍵パラメタ世代6.1.6------------------------------------------------------ 6.1.7 パラメタ品質検査6.1.6------------------------------------------------------ 6.1.8 ハードウェア/ソフトウェアキー生成6.1.1------------------------------------------------------ 6.1.9 主要なUsage Purposes(X.509 v3 Key Usage Fieldに従って)6.1.9------------------------------------------------------ 6.2 秘密鍵保護6.2------------------------------------------------------ 6.2.1 暗号のモジュール6.2.1の規格------------------------------------------------------
6.2.2 Private Key (n out of m)
Multi-Person Control 6.2.2
------------------------------------------------------
6.2.3 Private Key Escrow 6.2.3
------------------------------------------------------
6.2.4 Private Key Backup 6.2.4
------------------------------------------------------
6.2.5 Private Key Archival 6.2.5
------------------------------------------------------
6.2.6 Private Key Entry Into
Cryptographic Module 6.2.6, 6.2.7
------------------------------------------------------
6.2.7 Method of Activating
Private Key 6.2.8
6.2.2 個人的なKey(mからのn)マルチPerson Controlの6.2.2------------------------------------------------------ 6.2.3 秘密鍵エスクロー6.2.3------------------------------------------------------ 6.2.4 秘密鍵バックアップ6.2.4------------------------------------------------------ 6.2.5 秘密鍵記録保管所の6.2.5------------------------------------------------------ 6.2.6 暗号のモジュール6.2.6、6.2への秘密鍵エントリー、.7------------------------------------------------------ 6.2.7 秘密鍵6.2.8を活性化するメソッド
Chokhani, et al. Informational [Page 70] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [70ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
------------------------------------------------------
6.2.8 Method of Deactivating
Private Key 6.2.9
------------------------------------------------------
6.2.9 Method of Destroying Private
Key 6.2.10
------------------------------------------------------
6.3 Other Aspects of Key Pair
Management 6.3
------------------------------------------------------
6.3.1 Public Key Archival 6.3.1
------------------------------------------------------
6.3.2 Usage Periods for the Public
and Private Keys 6.3.2
------------------------------------------------------
6.4 Activation Data 6.4
------------------------------------------------------
6.4.1 Activation Data Generation
and Installation 6.4.1
------------------------------------------------------
6.4.2 Activation Data Protection 6.4.2
------------------------------------------------------
6.4.3 Other Aspects of Activation
Data 6.4.3
------------------------------------------------------
6.5 Computer Security Controls 6.5
------------------------------------------------------
6.5.1 Specific Computer Security
Technical Requirements 6.5.1
------------------------------------------------------
6.5.2 Computer Security Rating 6.5.2
------------------------------------------------------
6.6 Life Cycle Technical Controls 6.6
------------------------------------------------------
6.6.1 System Development Controls 6.6.1
------------------------------------------------------
6.6.2 Security Management Controls 6.6.2
------------------------------------------------------
6.6.3 Life Cycle Security Controls 6.6.3
------------------------------------------------------
6.7 Network Security Controls 6.7
------------------------------------------------------
6.8 Cryptographic Module
Engineering Controls 6.2.1, 6.2,
6.2.1, 6.2.11
------------------------------------------------------
7.Certificate and CRL Profiles 7.
------------------------------------------------------ 6.2.8 秘密鍵6.2.9を非活性化するメソッド------------------------------------------------------ 6.2.9 秘密鍵6.2.10を破壊するメソッド------------------------------------------------------ 6.3 主要な組管理6.3の他の局面------------------------------------------------------ 6.3.1 公開鍵記録保管所の6.3.1------------------------------------------------------ 6.3.2 公衆と秘密鍵6.3.2のための用法の期間------------------------------------------------------ 6.4 起動データ6.4------------------------------------------------------ 6.4.1 起動データ生成とインストール6.4.1------------------------------------------------------ 6.4.2 起動データ保護6.4.2------------------------------------------------------ 6.4.3 起動データ6.4.3の他の局面------------------------------------------------------ 6.5 コンピュータセキュリティコントロール6.5------------------------------------------------------ 6.5.1 特定のコンピュータセキュリティ技術的要求事項6.5.1------------------------------------------------------ 6.5.2 コンピュータセキュリティ格付け6.5の.2------------------------------------------------------ 6.6 ライフサイクル技術制御6.6------------------------------------------------------ 6.6.1 システム開発のコントロール6.6.1------------------------------------------------------ 6.6.2 セキュリティマネジメント・コントロール6.6.2------------------------------------------------------ 6.6.3 ライフサイクルセキュリティコントロール6.6.3------------------------------------------------------ 6.7 ネットワークセキュリティコントロール6.7------------------------------------------------------ 6.8 暗号のモジュール工学コントロール6.2.1、6.2、6.2.1、6.2.11------------------------------------------------------ 7. 証明書とCRLプロフィール7。
Chokhani, et al. Informational [Page 71] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [71ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
------------------------------------------------------
7.1 Certificate Profile 7.1
------------------------------------------------------
7.1.1 Version Number(s) 7.1.1
------------------------------------------------------
7.1.2 Certificate Extensions 7.1.2
------------------------------------------------------
7.1.3 Algorithm Object Identifiers 7.1.3
------------------------------------------------------
7.1.4 Name Forms 7.1.4
------------------------------------------------------
7.1.5 Name Constraints 7.1.5
------------------------------------------------------
7.1.6 Certificate Policy Object
Identifier 7.1.6
------------------------------------------------------
7.1.7 Usage of Policy Constraints
Extension 7.1.7
------------------------------------------------------
7.1.8 Policy Qualifiers Syntax
and Semantics 7.1.8
------------------------------------------------------
7.1.9 Processing Semantics for
the Critical Certificate
Policies Extension 7.1.9
------------------------------------------------------
7.2 CRL Profile 7.2
------------------------------------------------------
7.2.1 Version Number(s) 7.2.1
------------------------------------------------------
7.2.2 CRL and CRL Entry Extensions 7.2.1
------------------------------------------------------
8. Specification Administration N/A
------------------------------------------------------
8.1 Specification Change
Procedures 9.12
------------------------------------------------------
8.2 Publication and Notification
Policies 2.2, 2.3
------------------------------------------------------
8.3 CPS Approval Procedures 1.5.4
------------------------------------------------------
------------------------------------------------------ 7.1 証明書プロフィール7.1------------------------------------------------------ 7.1.1 バージョンNo.7.1.1------------------------------------------------------ 7.1.2 証明書拡張子7.1.2------------------------------------------------------ 7.1.3 アルゴリズムオブジェクト識別子7.1.3------------------------------------------------------ 7.1.4 フォーム7.1を.4と命名してください。------------------------------------------------------ 7.1.5 名前規制7.1.5------------------------------------------------------ 7.1.6 証明書政策目的識別子7.1.6------------------------------------------------------ 7.1.7 方針規制拡大7.1.7の用法------------------------------------------------------ 7.1.8 方針資格を与える人構文と意味論7.1.8------------------------------------------------------ 7.1.9 重要な証明書方針拡大7.1.9のための処理意味論------------------------------------------------------ 7.2 CRLプロフィール7.2------------------------------------------------------ 7.2.1 バージョンNo.7.2.1------------------------------------------------------ 7.2.2 CRLとCRLエントリー拡張子7.2.1------------------------------------------------------ 8. 仕様政権、なし。------------------------------------------------------ 8.1 仕様書変更手順9.12------------------------------------------------------ 8.2 公表と通知方針2.2、2.3------------------------------------------------------ 8.3 CPS承認の手順1.5.4------------------------------------------------------
Chokhani, et al. Informational [Page 72] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [72ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
The following matrix shows the sections in the new framework and the sections in RFC 2527 to which the headings in the new framework correspond.
以下のマトリクスは新しいフレームワークにおける見出しが相当する新しいフレームワークにおけるセクションとRFC2527のセクションを示しています。
NEW RFC SECTION ORIGINAL RFC 2527
SECTION
------------------------------------------------------
1. Introduction 1.
------------------------------------------------------
1.1 Overview 1.1
------------------------------------------------------
1.2 Document Name and Identification 1.2
------------------------------------------------------
1.3 PKI Participants 1.3
------------------------------------------------------
1.3.1 Certification Authorities 1.3.1
------------------------------------------------------
1.3.2 Registration Authorities 1.3.2
------------------------------------------------------
1.3.3 Subscribers 1.3.3
------------------------------------------------------
1.3.4 Relying Parties 1.3.3
------------------------------------------------------
1.3.5 Other Participants N/A
------------------------------------------------------
1.4 Certificate Usage 1.3.4
------------------------------------------------------
1.4.1 Appropriate Certificate Uses 1.3.4
------------------------------------------------------
1.4.2 Prohibited Certificate Uses 1.3.4
------------------------------------------------------
1.5 Policy Administration 1.4
------------------------------------------------------
1.5.1 Organization Administering
the Document 1.4.1
------------------------------------------------------
1.5.2 Contact Person 1.4.2
------------------------------------------------------
1.5.3 Person Determining CPS
Suitability for the Policy 1.4.3
------------------------------------------------------
1.5.4 CPS Approval Procedures 8.3
------------------------------------------------------
1.6 Definitions and Acronyms N/A
------------------------------------------------------
2. Publication and Repository
Responsibilities 2.1.5, 2.6
新しいRFCセクションオリジナルのRFC2527部------------------------------------------------------ 1. 序論1。 ------------------------------------------------------ 1.1 概要1.1------------------------------------------------------ 1.2 ドキュメント名と識別1.2------------------------------------------------------ 1.3 PKI関係者1.3------------------------------------------------------ 1.3.1 証明当局1.3.1------------------------------------------------------ 1.3.2 登録局1.3.2------------------------------------------------------ 1.3.3 加入者1.3.3------------------------------------------------------ 1.3.4 信用党1.3の.3------------------------------------------------------ 1.3.5 他の関係者、なし。------------------------------------------------------ 1.4 証明書用法1.3.4------------------------------------------------------ 1.4.1 適切な証明書用途1.3.4------------------------------------------------------ 1.4.2 禁止された証明書用途1.3.4------------------------------------------------------ 1.5 方針政権1.4------------------------------------------------------ 1.5.1 ドキュメント1.4.1を管理する組織------------------------------------------------------ 1.5.2 連絡窓口1.4の.2------------------------------------------------------ 1.5.3 方針1.4.3へのCPS適合を決定する人------------------------------------------------------ 1.5.4 CPS承認の手順8.3------------------------------------------------------ 1.6の定義と頭文字語、なし。------------------------------------------------------ 2. 公表と倉庫責任2.1.5、2.6
Chokhani, et al. Informational [Page 73] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [73ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
------------------------------------------------------
2.1 Repositories 2.6.4
------------------------------------------------------
2.2 Publication of Certification
Information 2.6.1, 8.2
------------------------------------------------------
2.3 Time or Frequency of
Publication 2.6.2, 8.2
------------------------------------------------------
2.4 Access Controls on Repositories 2.6.3
------------------------------------------------------
3. Identification and Authentication 3.
------------------------------------------------------
3.1 Naming 3.1
------------------------------------------------------
3.1.1 Type of Names 3.1.1
------------------------------------------------------
3.1.2 Need for Names to be Meaningful 3.1.2
------------------------------------------------------
3.1.3. Anonymity or Pseudonymity of
Subscribers 3.1.2
------------------------------------------------------
3.1.4 Rules for Interpreting Various
Name Forms 3.1.3
------------------------------------------------------
3.1.5 Uniqueness of Names 3.1.4
------------------------------------------------------
3.1.6 Recognition, Authentication,
and Role of Trademarks 3.1.5, 3.1.6
------------------------------------------------------
3.2 Initial Identity Validation 3.1
------------------------------------------------------
3.2.1 Method to Prove Possession
of Private Key 3.1.7
------------------------------------------------------
3.2.2 Authentication of
Organization Identity 3.1.8
------------------------------------------------------
3.2.3 Authentication of Individual
Identity 3.1.9
------------------------------------------------------
3.2.4 Non-Verified Subscriber
Information N/A
------------------------------------------------------
3.2.5 Validation of Authority 3.1.9
------------------------------------------------------ 2.1 倉庫2.6.4------------------------------------------------------ 2.2 証明情報2.6.1、8.2の公表------------------------------------------------------ 2.3 公表2.6.2、8.2の時間か頻度------------------------------------------------------ 2.4 倉庫2.6.3におけるアクセスコントロール------------------------------------------------------ 3. 識別と認証3。 ------------------------------------------------------ 3.1 命名3.1------------------------------------------------------ 3.1.1 名前3.1.1人のタイプ------------------------------------------------------ 3.1.2 NamesがMeaningful3.1.2である必要性------------------------------------------------------ 3.1.3. 加入者3.1.2の匿名か偽名------------------------------------------------------ 3.1.4 解釈するのに、様々な規則はフォーム3.1を.3と命名します。------------------------------------------------------ 3.1.5 名前3.1.4のユニークさ------------------------------------------------------ 3.1.6 .5、商標3.1 3.1の認識、認証、および役割、.6------------------------------------------------------ 3.2 初期のアイデンティティ合法化3.1------------------------------------------------------ 3.2.1 秘密鍵3.1.7の所有物を立証するメソッド------------------------------------------------------ 3.2.2 組織のアイデンティティ3.1.8の認証------------------------------------------------------ 3.2.3 個々のアイデンティティ3.1.9の認証------------------------------------------------------ 3.2.4 非確かめられた加入者情報、なし。------------------------------------------------------ 3.2.5 権威3.1.9の合法化
Chokhani, et al. Informational [Page 74] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [74ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
------------------------------------------------------
3.2.6 Criteria for Interoperation 4.1
------------------------------------------------------
3.3 Identification and Authentication
for Re-Key Requests 3.2, 3.3
------------------------------------------------------
3.3.1 Identification and
Authentication for Routine
Re-Key 3.2
------------------------------------------------------
3.3.2 Identification and
Authentication for Re-Key
After Revocation 3.3
------------------------------------------------------
3.4 Identification and Authentication
for Revocation Request 3.4
------------------------------------------------------
4. Certificate Life-Cycle
Operational Requirements 4.
------------------------------------------------------
4.1 Certificate Application 4.1
------------------------------------------------------
4.1.1 Who Can Submit a Certificate
Application 4.1
------------------------------------------------------
4.1.2 Enrollment Process and
Responsibilities 2.1.3, 4.1
------------------------------------------------------
4.2 Certificate Application
Processing 4.1, 4.2
------------------------------------------------------
4.2.1 Performing Identification
and Authentication Functions 4.1, 4.2
------------------------------------------------------
4.2.2 Approval or Rejection of
Certificate Applications 4.1, 4.2
------------------------------------------------------
4.2.3 Time to Process
Certificate Applications 4.1, 4.2
------------------------------------------------------
4.3 Certificate Issuance 4.2
------------------------------------------------------
4.3.1 CA Actions During
Certificate Issuance 4.2
------------------------------------------------------
4.3.2 Notifications to Subscriber by
the CA of Issuance of Certificate 4.2, 4.3
------------------------------------------------------ 3.2.6 Interoperation4.1の評価基準------------------------------------------------------ 3.3 再主要な要求3.2、3.3のための識別と認証------------------------------------------------------ 3.3.1 通常の再主要な3.2のための識別と認証------------------------------------------------------ 3.3.2 取消し3.3の後の再キーのための識別と認証------------------------------------------------------ 3.4 取消し要求3.4のための識別と認証------------------------------------------------------ 4. ライフサイクルの操作上の要件4を証明してください。 ------------------------------------------------------ 4.1 証明書アプリケーション4.1------------------------------------------------------ 4.1.1 だれが証明書アプリケーション4.1を提出できるか。------------------------------------------------------ 4.1.2 登録プロセスと責任2.1.3、4.1------------------------------------------------------ 4.2 証明書手続きの経緯4.1、4.2------------------------------------------------------ 4.2.1 識別と認証機能4.1、4.2を実行すること。------------------------------------------------------ 4.2.2 証明書アプリケーション4.1、4.2の承認か拒絶------------------------------------------------------ 4.2.3証明書アプリケーション4.1、4.2を処理する時間------------------------------------------------------ 4.3 証明書発行4.2------------------------------------------------------ 4.3.1 証明書発行4.2の間のカリフォルニアの動作------------------------------------------------------ 4.3.2 証明書4.2、4.3の発行のカリフォルニアのそばの加入者への通知
Chokhani, et al. Informational [Page 75] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [75ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
------------------------------------------------------
4.4 Certificate Acceptance 2.1.3, 4.3
------------------------------------------------------
4.4.1 Conduct Constituting
Certificate Acceptance 4.3
------------------------------------------------------
4.4.2 Publication of the
Certificate by the CA 2.1.5, 2.6.1, 4.3
------------------------------------------------------
4.4.3 Notification of
Certificate Issuance by
the CA to Other Entities 2.1.5, 2.6.1,
4.2, 4.3
------------------------------------------------------
4.5 Key Pair and
Certificate Usage 1.3.4, 2.1.3,
2.1.4
------------------------------------------------------
4.5.1 Subscriber Private Key
and Certificate Usage 1.3.4, 2.1.3
------------------------------------------------------
4.5.2 Relying Party Public
Key and Certificate
Usage 1.3.4, 2.1.4
------------------------------------------------------
4.6 Certificate Renewal 3.2, 4.1, 4.2,
4.3
------------------------------------------------------
4.6.1 Circumstances for
Certificate Renewal 3.2, 4.1
------------------------------------------------------
4.6.2 Who May Request Renewal 3.2, 4.1
------------------------------------------------------
4.6.3 Processing Certificate
Renewal Requests 3.2, 4.1, 4.2
------------------------------------------------------
4.6.4 Notification of New
Certificate Issuance to
Subscriber 3.2, 4.2, 4.3
------------------------------------------------------
4.6.5 Conduct Constituting
Acceptance of a Renewal
Certificate 2.1.3, 3.2, 4.3
------------------------------------------------------
4.6.6 Publication of the
Renewal Certificate
by the CA 2.1.5, 2.6.1,
3.2, 4.3
------------------------------------------------------ 4.4 証明書承認2.1.3、4.3------------------------------------------------------ 4.4.1 証明書承認4.3を成立させて、伝導してください。------------------------------------------------------ 4.4.2 カリフォルニア2.1.5、2.6のものの証明書の公表、.1、4.3------------------------------------------------------ 4.4.3 他の実体2.1.5、2.6へのカリフォルニアによる証明書発行の通知、.1、4.2、4.3------------------------------------------------------ 主要な4.5組、および証明書用法1.3.4、2.1.3、2.1、.4------------------------------------------------------ 4.5.1 加入者秘密鍵と証明書用法1.3.4、2.1.3------------------------------------------------------ 4.5.2 当てにしているパーティ公開鍵と証明書用法1.3.4、2.1.4------------------------------------------------------ 4.6 証明書更新3.2、4.1、4.2、4.3------------------------------------------------------ 4.6.1 証明書更新3.2、4.1のための事情------------------------------------------------------ 4.6.2 だれが更新3.2、4.1を要求するかもしれないか。------------------------------------------------------ 4.6.3 処理証明書更新要求3.2、4.1、4.2------------------------------------------------------ 4.6.4 加入者3.2、4.2、4.3への新しい証明書発行の通知------------------------------------------------------ 4.6.5 保険契約継続証2.1.3、3.2、4.3の承認を成立させて、伝導してください。------------------------------------------------------ 4.6.6 更新の公表は.1、3.2、4.3をカリフォルニア2.1.5、2.6で証明します。
Chokhani, et al. Informational [Page 76] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [76ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
------------------------------------------------------
4.6.7 Notification of
Certificate Issuance by
the CA to Other Entities 2.1.5, 2.6.1, 3.2,
4.2, 4.3
------------------------------------------------------
4.7 Certificate Re-Key 3.2, 4.1, 4.2, 4.3
------------------------------------------------------
4.7.1 Circumstances for
Certificate Re-Key 3.2, 4.1
------------------------------------------------------
4.7.2 Who May Request Certification
of a New Public Key 3.2, 4.1
------------------------------------------------------
4.7.3 Processing Certificate
Re-Keying Requests 3.2, 4.1, 4.2
------------------------------------------------------
4.7.4 Notification of New
Certificate Issuance to
Subscriber 3.2, 4.2, 4.3
------------------------------------------------------
4.7.5 Conduct Constituting
Acceptance of a
Re-Keyed Certificate 2.1.3, 3.2, 4.3
------------------------------------------------------
4.7.6 Publication of the
Re-Keyed Certificate
by the CA 2.1.5, 2.6.1,
3.2, 4.3
------------------------------------------------------
4.7.7 Notification of Certificate
Issuance by the CA
to Other Entities 2.1.5, 2.6.1,
3.2, 4.2, 4.3
------------------------------------------------------
4.8 Certificate Modification 4.4
------------------------------------------------------
4.8.1 Circumstances for
Certificate Modification 2.1.3, 4.4.1
------------------------------------------------------
4.8.2 Who May Request Certificate
Modification 4.4.2
------------------------------------------------------
4.8.3 Processing Certificate
Modification Requests 4.4.3
------------------------------------------------------ 4.6.7 他の実体へのカリフォルニアによる証明書発行の通知、2.1、.5、2.6、.1、3.2、4.2、4.3------------------------------------------------------ 4.7は再キー3.2、4.1、4.2、4.3を証明します。------------------------------------------------------ 4.7.1 証明書再キー3.2、4.1のための事情------------------------------------------------------ 4.7.2 だれが新しい公開鍵3.2、4.1の証明を要求するかもしれないか。------------------------------------------------------ 4.7.3 処理証明書再の合わせる要求3.2、4.1、4.2------------------------------------------------------ 4.7.4 加入者3.2、4.2、4.3への新しい証明書発行の通知------------------------------------------------------ 4.7.5 再合わせられた証明書2.1.3、3.2、4.3の承認を成立させて、伝導してください。------------------------------------------------------ 4.7.6 カリフォルニアのそばの再合わせられた証明書の公表、2.1、.5、2.6、.1、3.2、4.3------------------------------------------------------ 4.7.7 他の実体へのカリフォルニアによる証明書発行の通知、2.1、.5、2.6、.1、3.2、4.2、4.3------------------------------------------------------ 4.8 証明書変更4.4------------------------------------------------------ 4.8.1 証明書変更2.1.3、4.4.1のための事情------------------------------------------------------ 4.8.2 だれが証明書変更4.4.2を要求するかもしれませんか?------------------------------------------------------ 4.8.3 処理証明書変更要求4.4.3
Chokhani, et al. Informational [Page 77] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [77ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
------------------------------------------------------
4.8.4 Notification of New
Certificate Issuance to
Subscriber 4.2, 4.3, 4.4.3
------------------------------------------------------
4.8.5 Conduct Constituting
Acceptance of Modified
Certificate 2.1.3, 4.3, 4.4.3
------------------------------------------------------
4.8.6 Publication of the Modified
Certificate by
the CA 2.1.5, 2.6.1,
4.2, 4.3, 4.4.3
------------------------------------------------------
4.8.7 Notification of
Certificate Issuance by
the CA to Other
Entities 2.1.5, 2.6.1,
4.2, 4.3, 4.4.3
------------------------------------------------------
4.9 Certificate Revocation
and Suspension 4.4
------------------------------------------------------
4.9.1 Circumstances for Revocation 2.1.3, 4.4.1
------------------------------------------------------
4.9.2 Who Can Request Revocation 4.4.2
------------------------------------------------------
4.9.3 Procedure for Revocation
Request 2.1.3, 4.4.3
------------------------------------------------------
4.9.4 Revocation Request Grace
Period 4.4.4
------------------------------------------------------
4.9.5 Time Within Which CA Must
Process the Revocation Request N/A
------------------------------------------------------
4.9.6 Revocation Checking
Requirements for Relying
Parties 2.1.4, 4.4.10,
4.4.12, 4.4.14
------------------------------------------------------
4.9.7 CRL Issuance Frequency 4.4.9, 4.8.3
------------------------------------------------------
4.9.8 Maximum Latency for CRLs 4.4.9
------------------------------------------------------
4.9.9 On-Line Revocation/Status
Checking Availability 4.4.11, 4.8.3
------------------------------------------------------ 4.8.4 加入者4.2、4.3、4.4.3への新しい証明書発行の通知------------------------------------------------------ 4.8.5 変更された証明書2.1.3、4.3、4.4の承認を成立させて、伝導してください、.3------------------------------------------------------ 4.8.6 カリフォルニアのそばの変更された証明書の公表、2.1、.5、2.6、.1、4.2、4.3、4.4、.3------------------------------------------------------ 4.8.7 他の実体へのカリフォルニアによる証明書発行の通知、2.1、.5、2.6、.1、4.2、4.3、4.4、.3------------------------------------------------------ 4.9 証明書取消しとサスペンション4.4------------------------------------------------------ 4.9.1 取消し2.1.3、4.4のための事情、.1------------------------------------------------------ 4.9.2 だれが取消し4.4.2を要求できますか?------------------------------------------------------ 4.9.3 取消し要求2.1.3、4.4.3のための手順------------------------------------------------------ 4.9.4 取消し要求据置期間4.4の.4------------------------------------------------------ 4.9.5 カリフォルニアが取消しを処理しなければならない時は、なしよう要求します。------------------------------------------------------ 4.9.6 .4、信用党2.1の4.4のための要件をチェックする取消し、.10 4.4 .12、4.4、.14------------------------------------------------------ 4.9.7 CRL発行頻度4.4.9、4.8.3------------------------------------------------------ 4.9.8 CRLs4.4.9のための最大の潜在------------------------------------------------------ 4.9.9 有用性4.4.11、4.8をチェックするオンライン取消し/状態、.3
Chokhani, et al. Informational [Page 78] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [78ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
------------------------------------------------------
4.9.10 On-Line Revocation
Checking Requirements 4.4.12
------------------------------------------------------
4.9.11 Other Forms of Revocation
Advertisements Available 4.4.13, 4.4.14,
4.8.3
------------------------------------------------------
4.9.12 Special Requirements re
Key Compromise 4.4.15
------------------------------------------------------
4.9.13 Circumstances for Suspension 2.1.3, 4.4.5
------------------------------------------------------
4.9.14 Who Can Request Suspension 4.4.6
------------------------------------------------------
4.9.15 Procedure for
Suspension Request 2.1.3, 4.4.7
------------------------------------------------------
4.9.16 Limits on Suspension Period 4.4.8
------------------------------------------------------
4.10 Certificate Status Services 4.4.9-4.4.14
------------------------------------------------------
4.10.1 Operational
Characteristics 4.4.9, 4.4.11,
4.4.13
------------------------------------------------------
4.10.2 Service Availability 4.4.9, 4.4.11,
4.4.13
------------------------------------------------------
4.10.3 Operational Features 4.4.9, 4.4.11,
4.4.13
------------------------------------------------------
4.11 End of Subscription N/A
------------------------------------------------------
4.12 Key Escrow and Recovery 6.2.3
------------------------------------------------------
4.12.1 Key Escrow and Recovery Policy
and Practices 6.2.3
------------------------------------------------------
4.12.2 Session Key Encapsulation
and Recovery Policy and
Practices 6.2.3
------------------------------------------------------
5. Facility, Management, and
Operational Controls 2.1.3, 2.1.4,
4., 5.
------------------------------------------------------
5.1 Physical Controls 5.1
------------------------------------------------------ 4.9.10 要件4.4.12をチェックするオンライン取消し------------------------------------------------------ 取消し広告利用可能な4.4.13、4.4.14、4.9.11 他の4.8のフォーム、.3------------------------------------------------------ 4.9.12 Key Compromise4.4.15に関して特別なRequirements------------------------------------------------------ 4.9.13 サスペンション2.1.3、4.4のための事情、.5------------------------------------------------------ 4.9.14 だれがサスペンション4.4.6を要求できますか?------------------------------------------------------ 4.9.15 サスペンション要求2.1.3、4.4.7のための手順------------------------------------------------------ 4.9.16 休職期間4.4.8における限界------------------------------------------------------ 4.10 証明書状態サービス4.4.9-4.4.14------------------------------------------------------ 4.10.1 操作上の特性4.4.9、4.4、.11、4.4、.13------------------------------------------------------ 4.10.2 サービス有用性4.4.9、4.4.11、4.4、.13------------------------------------------------------ 4.10.3 操作上の特徴4.4.9、4.4、.11、4.4、.13------------------------------------------------------ 購読の4.11終わり、なし。------------------------------------------------------ 4.12 キーエスクローと回復6.2.3------------------------------------------------------ 4.12.1 キーエスクロー、回復方針、および習慣6.2.3------------------------------------------------------ 4.12.2 セッションの主要なカプセル化と回復方針と習慣6.2.3------------------------------------------------------ 5. 施設、管理、および運用統制2.1.3、2.1、.4、4.、5 ------------------------------------------------------ 5.1 物理的なコントロール5.1
Chokhani, et al. Informational [Page 79] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [79ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
------------------------------------------------------
5.1.1 Site Location and Construction 5.1.1
------------------------------------------------------
5.1.2 Physical Access 5.1.2
------------------------------------------------------
5.1.3 Power and Air Conditioning 5.1.3
------------------------------------------------------
5.1.4 Water Exposures 5.1.4
------------------------------------------------------
5.1.5 Fire Prevention and Protection 5.1.5
------------------------------------------------------
5.1.6 Media Storage 5.1.6
------------------------------------------------------
5.1.7 Waste Disposal 5.1.7
------------------------------------------------------
5.1.8 Off-Site Backup 5.1.8
------------------------------------------------------
5.2 Procedural Controls 5.2
------------------------------------------------------
5.2.1 Trusted Roles 5.2.1
------------------------------------------------------
5.2.2 Number of Persons Required
per Task 5.2.2
------------------------------------------------------
5.2.3 Identification and
Authentication for Each Role 5.2.3
------------------------------------------------------
5.2.4 Roles Requiring Separation
of Duties 5.2.1, 5.2.2
------------------------------------------------------
5.3 Personnel Controls 5.3
------------------------------------------------------
5.3.1 Qualifications, Experience,
and Clearance Requirements 5.3.1
------------------------------------------------------
5.3.2 Background Check Procedures 5.3.2
------------------------------------------------------
5.3.3 Training Requirements 5.3.3
------------------------------------------------------
5.3.4 Retraining Frequency
and Requirements 5.3.4
------------------------------------------------------
5.3.5 Job Rotation Frequency
and Sequence 5.3.5
------------------------------------------------------
5.3.6 Sanctions for Unauthorized
Actions 5.3.6
------------------------------------------------------ 5.1.1 立地と工事5.1.1------------------------------------------------------ 5.1.2 物理的なアクセス5.1.2------------------------------------------------------ 5.1.3 パワーと空調5.1.3------------------------------------------------------ 5.1.4 水の暴露5.1.4------------------------------------------------------ 5.1.5 防火と保護5.1.5------------------------------------------------------ 5.1.6 メディアストレージ5.1.6------------------------------------------------------ 5.1.7 ゴミ処理5.1.7------------------------------------------------------ 5.1.8 オフサイトバックアップ5.1.8------------------------------------------------------ 5.2 手続き上のコントロール5.2------------------------------------------------------ 5.2.1 信じられた役割5.2の.1------------------------------------------------------ 5.2.2 人員がタスク5.2.2単位で必要です。------------------------------------------------------ 5.2.3 それぞれの役割5.2の.3のための識別と認証------------------------------------------------------ 5.2.4 義務5.2.1、5.2の分離を必要とする役割、.2------------------------------------------------------ 5.3人の人員が5.3を制御します。------------------------------------------------------ 5.3.1 資格、経験、およびクリアランス要件5.3.1------------------------------------------------------ 5.3.2 素性調査手順5.3.2------------------------------------------------------ 5.3.3 トレーニング要件5.3.3------------------------------------------------------ 5.3.4 再教育頻度と要件5.3.4------------------------------------------------------ 5.3.5 ジョブローテーション頻度と系列5.3.5------------------------------------------------------ 5.3.6 権限のない動作5.3.6のための制裁
Chokhani, et al. Informational [Page 80] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [80ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
------------------------------------------------------
5.3.7 Independent Contractor
Requirements 5.3.7
------------------------------------------------------
5.3.8 Documentation Supplied to
Personnel 5.3.8
------------------------------------------------------
5.4 Audit Logging Procedures 4.5
------------------------------------------------------
5.4.1 Types of Events Recorded 4.5.1
------------------------------------------------------
5.4.2 Frequency of Processing Log 4.5.2
------------------------------------------------------
5.4.3 Retention Period for Audit
Log 4.5.3
------------------------------------------------------
5.4.4 Protection of Audit Log 4.5.4
------------------------------------------------------
5.4.5 Audit Log Backup Procedures 4.5.5
------------------------------------------------------
5.4.6 Audit Collection System
(Internal vs. External) 4.5.6
------------------------------------------------------
5.4.7 Notification to Event-Causing
Subject 4.5.7
------------------------------------------------------
5.4.8 Vulnerability Assessments 4.5.8
------------------------------------------------------
5.5 Records Archival 4.6
------------------------------------------------------
5.5.1 Types of Records Archived 4.6.1
------------------------------------------------------
5.5.2 Retention Period for Archive 4.6.2
------------------------------------------------------
5.5.3 Protection of Archive 4.6.3
------------------------------------------------------
5.5.4 Archive Backup Procedures 4.6.4
------------------------------------------------------
5.5.5 Requirements for Time-Stamping
of Records 4.6.5
------------------------------------------------------
5.5.6 Archive Collection System
(Internal or External) 4.6.6
------------------------------------------------------
5.5.7 Procedures to Obtain and
Verify Archive
Information 4.6.7
------------------------------------------------------ 5.3.7 請負人要件5.3.7------------------------------------------------------ 5.3.8 人員5.3.8に供給されたドキュメンテーション------------------------------------------------------ 5.4 監査伐採手順4.5------------------------------------------------------ 5.4.1 イベントのタイプは4.5に.1を記録しました。------------------------------------------------------ 5.4.2 処理ログ4.5.2の頻度------------------------------------------------------ 5.4.3 監査ログ4.5.3のための保有の期間------------------------------------------------------ 5.4.4 監査ログ4.5.4の保護------------------------------------------------------ 5.4.5 監査ログバックアップ手順4.5.5------------------------------------------------------ 5.4.6 監査収集システム(外部に対して内部の)4.5.6------------------------------------------------------ 5.4.7 イベント引き起こす対象4.5.7への通知------------------------------------------------------ 5.4.8 弱点査定4.5.8------------------------------------------------------ 5.5は記録保管所の4.6を記録します。------------------------------------------------------ 5.5.1 記録のタイプは4.6に.1を格納しました。------------------------------------------------------ 5.5.2 アーカイブ4.6.2のための保有の期間------------------------------------------------------ 5.5.3 アーカイブ4.6.3の保護------------------------------------------------------ 5.5.4 アーカイブバックアップ手順4.6.4------------------------------------------------------ 5.5.5 記録4.6.5の時間の刻印のための要件------------------------------------------------------ 5.5.6 収集システム(内部か外部)の4.6.6を格納してください。------------------------------------------------------ 5.5.7 得て、確かめる手順は情報4.6.7を格納します。
Chokhani, et al. Informational [Page 81] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [81ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
------------------------------------------------------
5.6 Key Changeover 4.7
------------------------------------------------------
5.7 Compromise and Disaster Recovery 4.8
------------------------------------------------------
5.7.1 Incident and Compromise
Handling Procedures 4.8
------------------------------------------------------
5.7.2 Computing Resources, Software,
and/or Data Are Corrupted 4.8.1
------------------------------------------------------
5.7.3 Entity Private Key
Compromise Procedures 4.8.3
------------------------------------------------------
5.7.4 Business Continuity
Capabilities After a
Disaster 4.8.4
------------------------------------------------------
5.8 CA or RA Termination 4.9
------------------------------------------------------
6. Technical Security Controls 2.1.3, 2.1.4,
6.
------------------------------------------------------
6.1 Key Pair Generation and
Installation 6.1
------------------------------------------------------
6.1.1 Key Pair Generation 6.1.1, 6.1.8
------------------------------------------------------
6.1.2 Private Key Delivery to
Subscriber 6.1.2
------------------------------------------------------
6.1.3 Public Key Delivery to
Certificate Issuer 6.1.3
------------------------------------------------------
6.1.4 CA Public Key Delivery to
Relying Parties 6.1.4
------------------------------------------------------
6.1.5 Key Sizes 6.1.5
------------------------------------------------------
6.1.6 Public Key Parameters Generation
and Quality Checking 6.1.6, 6.1.7
------------------------------------------------------
6.1.7 Key Usage Purposes
(as per X.509 v3
Key Usage Field) 6.1.9
------------------------------------------------------ 5.6 主要な転換4.7------------------------------------------------------ 5.7 感染と災害復旧4.8------------------------------------------------------ 5.7.1 インシデントと感染取り扱い手順4.8------------------------------------------------------ 5.7.2 コンピューティング資源、ソフトウェア、そして/または、データが4.8に崩壊する、.1------------------------------------------------------ 5.7.3 実体秘密鍵感染手順4.8.3------------------------------------------------------ 5.7.4 災害4.8.4の後のビジネス継続性能力------------------------------------------------------ 5.8 カリフォルニアかRA終了4.9------------------------------------------------------ 6. 技術的なセキュリティは制御されます。2.1 .3 2.1 .4、6。 ------------------------------------------------------ 6.1 主要な組世代とインストール6.1------------------------------------------------------ 6.1.1 主要な組世代6.1.1、6.1.8------------------------------------------------------ 6.1.2 加入者6.1.2への秘密鍵配送------------------------------------------------------ 6.1.3 発行人6.1.3を証明する公開鍵配送------------------------------------------------------ 6.1.4 信用党6.1の.4へのカリフォルニアの公開鍵配送------------------------------------------------------ 6.1.5 主要なサイズ6.1.5------------------------------------------------------ 6.1.6 公開鍵パラメタ世代と品質検査6.1.6、6.1.7------------------------------------------------------ 6.1.7 主要なUsage Purposes(X.509 v3 Key Usage Fieldに従って)6.1.9
Chokhani, et al. Informational [Page 82] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [82ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
------------------------------------------------------
6.2 Private Key Protection and
Cryptographic Module
Engineering Controls 6.2, 6.8
------------------------------------------------------
6.2.1 Cryptographic Module Standards
and Controls 6.2.1, 6.8
------------------------------------------------------
6.2.2 Private Key (n out of m)
Multi-Person Control 6.2.2
------------------------------------------------------
6.2.3 Private Key Escrow 6.2.3
------------------------------------------------------
6.2.4 Private Key Backup 6.2.4
------------------------------------------------------
6.2.5 Private Key Archival 6.2.5
------------------------------------------------------
6.2.6 Private Key Transfer Into
or From a Cryptographic
Module 6.2.6
------------------------------------------------------
6.2.7 Private Key Storage on
Cryptographic Module 6.2.6
------------------------------------------------------
6.2.8 Method of Activating Private
Key 6.2.7
------------------------------------------------------
6.2.9 Method of Deactivating
Private Key 6.2.8
------------------------------------------------------
6.2.10 Method of Destroying
Private Key 6.2.9
------------------------------------------------------
6.2.11 Cryptographic Module Rating 6.2.1, 6.8
------------------------------------------------------
6.3 Other Aspects of Key Pair
Management 6.3
------------------------------------------------------
6.3.1 Public Key Archival 6.3.1
------------------------------------------------------
6.3.2 Certificate Operational
Periods and Key Pair Usage
Periods 6.3.2
------------------------------------------------------
6.4 Activation Data 6.4
------------------------------------------------------ 6.2 秘密鍵保護と暗号のモジュール工学コントロール6.2、6.8------------------------------------------------------ 6.2.1 暗号のモジュール規格とコントロール6.2.1、6.8------------------------------------------------------ 6.2.2 個人的なKey(mからのn)マルチPerson Controlの6.2.2------------------------------------------------------ 6.2.3 秘密鍵エスクロー6.2.3------------------------------------------------------ 6.2.4 秘密鍵バックアップ6.2.4------------------------------------------------------ 6.2.5 秘密鍵記録保管所の6.2.5------------------------------------------------------ 6.2.6 .6、または、暗号のモジュール6.2.6からの秘密鍵転送------------------------------------------------------ 6.2.7 暗号のモジュール6.2.6における秘密鍵ストレージ------------------------------------------------------ 6.2.8 秘密鍵6.2.7を活性化するメソッド------------------------------------------------------ 6.2.9 秘密鍵6.2.8を非活性化するメソッド------------------------------------------------------ 6.2.10 秘密鍵6.2.9を破壊するメソッド------------------------------------------------------ 6.2.11 暗号のモジュール格付け6.2.1、6.8------------------------------------------------------ 6.3 主要な組管理6.3の他の局面------------------------------------------------------ 6.3.1 公開鍵記録保管所の6.3.1------------------------------------------------------ 6.3.2 証明書の操作上の期間と主要な組用法の期間6.3の.2------------------------------------------------------ 6.4 起動データ6.4
Chokhani, et al. Informational [Page 83] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [83ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
------------------------------------------------------
6.4.1 Activation Data Generation
and Installation 6.4.1
------------------------------------------------------
6.4.2 Activation Data Protection 6.4.2
------------------------------------------------------
6.4.3 Other Aspects of Activation
Data 6.4.3
------------------------------------------------------
6.5 Computer Security Controls 6.5
------------------------------------------------------
6.5.1 Specific Computer Security
Technical Requirements 6.5.1
------------------------------------------------------
6.5.2 Computer Security Rating 6.5.2
------------------------------------------------------
6.6 Life Cycle Technical Controls 6.6
------------------------------------------------------
6.6.1 System Development Controls 6.6.1
------------------------------------------------------
6.6.2 Security Management Controls 6.6.2
------------------------------------------------------
6.6.3 Life Cycle Security Controls 6.6.3
------------------------------------------------------
6.7 Network Security Controls 6.7
------------------------------------------------------
6.8 Time-Stamping N/A
------------------------------------------------------
7. Certificate, CRL, and
OCSP Profiles 7.
------------------------------------------------------
7.1 Certificate Profile 7.1
------------------------------------------------------
7.1.1 Version Number(s) 7.1.1
------------------------------------------------------
7.1.2 Certificate Extensions 7.1.2
------------------------------------------------------
7.1.3 Algorithm Object Identifiers 7.1.3
------------------------------------------------------
7.1.4 Name Forms 7.1.4
------------------------------------------------------
7.1.5 Name Constraints 7.1.5
------------------------------------------------------
7.1.6 Certificate Policy
Object Identifier 7.1.6
------------------------------------------------------
7.1.7 Usage of Policy Constraints
Extension 7.1.7
------------------------------------------------------ 6.4.1 起動データ生成とインストール6.4.1------------------------------------------------------ 6.4.2 起動データ保護6.4.2------------------------------------------------------ 6.4.3 起動データ6.4.3の他の局面------------------------------------------------------ 6.5 コンピュータセキュリティコントロール6.5------------------------------------------------------ 6.5.1 特定のコンピュータセキュリティ技術的要求事項6.5.1------------------------------------------------------ 6.5.2 コンピュータセキュリティ格付け6.5の.2------------------------------------------------------ 6.6 ライフサイクル技術制御6.6------------------------------------------------------ 6.6.1 システム開発のコントロール6.6.1------------------------------------------------------ 6.6.2 セキュリティマネジメント・コントロール6.6.2------------------------------------------------------ 6.6.3 ライフサイクルセキュリティコントロール6.6.3------------------------------------------------------ 6.7 ネットワークセキュリティコントロール6.7------------------------------------------------------ 6.8時間の刻印、なし。------------------------------------------------------ 7. 証明書、CRL、およびOCSPプロフィール7。 ------------------------------------------------------ 7.1 証明書プロフィール7.1------------------------------------------------------ 7.1.1 バージョンNo.7.1.1------------------------------------------------------ 7.1.2 証明書拡張子7.1.2------------------------------------------------------ 7.1.3 アルゴリズムオブジェクト識別子7.1.3------------------------------------------------------ 7.1.4 フォーム7.1を.4と命名してください。------------------------------------------------------ 7.1.5 名前規制7.1.5------------------------------------------------------ 7.1.6 証明書政策目的識別子7.1.6------------------------------------------------------ 7.1.7 方針規制拡大7.1.7の用法
Chokhani, et al. Informational [Page 84] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [84ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
------------------------------------------------------
7.1.8 Policy Qualifiers Syntax
and Semantics 7.1.8
------------------------------------------------------
7.1.9 Processing Semantics for the
Critical Certificate Policies
Extension 7.1.9
------------------------------------------------------
7.2 CRL Profile 7.2
------------------------------------------------------
7.2.1 Version Number(s) 7.2.1
------------------------------------------------------
7.2.2 CRL and CRL Entry Extensions 7.2.1
------------------------------------------------------
7.3 OCSP Profile N/A
------------------------------------------------------
7.3.1 Version Number(s) N/A
------------------------------------------------------
7.3.2 OCSP Extensions N/A
------------------------------------------------------
8. Compliance Audit and Other
Assessments 2.7
------------------------------------------------------
8.1 Frequency and Circumstances
of Assessment 2.7.1
------------------------------------------------------
8.2 Identity/Qualifications of
Assessor 2.7.2
------------------------------------------------------
8.3 Assessor's Relationship to
Assessed Entity 2.7.3
------------------------------------------------------
8.4 Topics Covered by Assessment 2.7.4
------------------------------------------------------
8.5 Actions Taken as a Result
of Deficiency 2.7.5
------------------------------------------------------
8.6 Communications of Results 2.7.6
------------------------------------------------------
9. Other Business and Legal
Matters 2.
------------------------------------------------------ 7.1.8 方針資格を与える人構文と意味論7.1.8------------------------------------------------------ 7.1.9 重要な証明書方針拡大7.1.9のための処理意味論------------------------------------------------------ 7.2 CRLプロフィール7.2------------------------------------------------------ 7.2.1 バージョンNo.7.2.1------------------------------------------------------ 7.2.2 CRLとCRLエントリー拡張子7.2.1------------------------------------------------------ 7.3OCSPが輪郭を描く、なし。------------------------------------------------------ 7.3.1 バージョン番号、なし。------------------------------------------------------ 7.3.2 OCSP拡張子、なし。------------------------------------------------------ 8. 承諾監査と他の査定2.7------------------------------------------------------ 8.1 査定2.7.1の頻度と事情------------------------------------------------------ 8.2 査定者2.7.2のアイデンティティ/資格------------------------------------------------------ 8.3 評価された実体2.7.3との査定者の関係------------------------------------------------------ 8.4 査定2.7.4でカバーされた話題------------------------------------------------------ 8.5 欠乏2.7.5の結果、取られた行動------------------------------------------------------ 8.6 結果2.7.6に関するコミュニケーション------------------------------------------------------ 9. 他のビジネスと法的な件2。
------------------------------------------------------
9.1 Fees 2.5
------------------------------------------------------
9.1.1 Certificate Issuance or
Renewal Fees 2.5.1
------------------------------------------------------ 9.1 料金2.5------------------------------------------------------ 9.1.1 証明書発行か更新料2.5.1
Chokhani, et al. Informational [Page 85] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [85ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
------------------------------------------------------
9.1.2 Certificate Access Fees 2.5.2
------------------------------------------------------
9.1.3 Revocation or Status
Information Access Fees 2.5.3
------------------------------------------------------
9.1.4 Fees for Other Services 2.5.4
------------------------------------------------------
9.1.5 Refund Policy 2.5.5
------------------------------------------------------
9.2 Financial Responsibility 2.3
------------------------------------------------------
9.2.1 Insurance Coverage 2.3
------------------------------------------------------
9.2.2 Other Assets 2.3
------------------------------------------------------
9.2.3 Insurance or Warranty Coverage
for End-Entities 2.3
------------------------------------------------------
9.3 Confidentiality of Business
Information 2.8
------------------------------------------------------
9.3.1 Scope of Confidential
Information 2.8.1, 2.8.3
------------------------------------------------------
9.3.2 Information Not Within the
Scope of Confidential
Information 2.8.2, 2.8.3
------------------------------------------------------
9.3.3 Responsibility to Protect
Confidential Information 2.8,
------------------------------------------------------ 9.1.2 証明書アクセスチャージ2.5.2------------------------------------------------------ 9.1.3 取消しか状態情報アクセスチャージ2.5.3------------------------------------------------------ 9.1.4 他のサービス2.5.4のための料金------------------------------------------------------ 9.1.5 代金返却方針2.5.5------------------------------------------------------ 9.2 金融責任2.3------------------------------------------------------ 9.2.1 損害補償の範囲2.3------------------------------------------------------ 9.2.2 他の資産2.3------------------------------------------------------ 9.2.3 終わり実体2.3のための保険か保証適用範囲------------------------------------------------------ 9.3 企業情報2.8の秘密性------------------------------------------------------ 9.3.1 秘密情報2.8.1、2.8の範囲、.3------------------------------------------------------ 9.3.2 秘密情報2.8.2、2.8の範囲の中の情報、.3------------------------------------------------------ 9.3.3 秘密情報2.8を保護する責任
2.8.3-2.8.7
------------------------------------------------------
9.4 Privacy of Personal Information 2.8
------------------------------------------------------
9.4.1 Privacy Plan N/A
------------------------------------------------------
9.4.2 Information Treated as Private 2.8.1, 2.8.3
------------------------------------------------------
9.4.3 Information Not Deemed Private 2.8.2, 2.8.3
------------------------------------------------------
9.4.4 Responsibility to Protect
Private Information 2.8, 2.8.1,
2.8.3
------------------------------------------------------
9.4.5 Notice and Consent to Use
Private Information N/A
2.8.3-2.8.7 ------------------------------------------------------ 9.4 個人情報の秘密2.8------------------------------------------------------ 9.4.1 プライバシープラン、なし。------------------------------------------------------ 9.4.2 情報は.1、兵士2.8の2.8として.3を扱いました。------------------------------------------------------ 9.4.3 情報の考えられなかった兵士2.8.2、2.8、.3------------------------------------------------------ 9.4.4 個人情報2.8、2.8.1、2.8を保護する責任、.3------------------------------------------------------ 9.4.5 注意してください、そして、なしを使用個人的な情報に同意してください。
Chokhani, et al. Informational [Page 86] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [86ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
------------------------------------------------------
9.4.6 Disclosure Pursuant to
Judicial or Administrative
Process 2.8.4-2.8.5
------------------------------------------------------
9.4.7 Other Information Disclosure
Circumstances 2.8.6-2.8.7
------------------------------------------------------
9.5 Intellectual Property rights 2.9
------------------------------------------------------
9.6 Representations and Warranties 2.2
------------------------------------------------------
9.6.1 CA Representations and
Warranties 2.2.1
------------------------------------------------------
9.6.2 RA Representations and
Warranties 2.2.2
------------------------------------------------------
9.6.3 Subscriber Representations
and Warranties 2.1.3
------------------------------------------------------
------------------------------------------------------ 9.4.6 司法の、または、管理の過程2.8.4-2.8.5に従った公開------------------------------------------------------ 9.4.7 他の情報公開事情2.8.6-2.8.7------------------------------------------------------ 9.5 知的なProperty権利2.9------------------------------------------------------ 9.6の表明保証条項2.2------------------------------------------------------ 9.6.1 カリフォルニア表明保証条項2.2.1------------------------------------------------------ 9.6.2 RA表明保証条項2.2.2------------------------------------------------------ 9.6.3 加入者表明保証条項2.1.3------------------------------------------------------
9.6.4 Relying Party Representations
and Warranties 2.1.4
------------------------------------------------------
9.6.5 Representations and Warranties
of Other Participants N/A
------------------------------------------------------
9.7 Disclaimers of Warranties 2.2, 2.3.2
------------------------------------------------------
9.8 Limitations of Liability 2.2
------------------------------------------------------
9.9 Indemnities 2.1.3, 2.1.4,
2.2, 2.3.1
------------------------------------------------------
9.10 Term and Termination N/A
------------------------------------------------------
9.10.1 Term N/A
------------------------------------------------------
9.10.2 Termination N/A
------------------------------------------------------
9.10.3 Effect of Termination and
Survival N/A
------------------------------------------------------
9.11 Individual Notices and
Communications with Participants 2.4.2
------------------------------------------------------
9.12 Amendments 8.1
9.6.4 信用パーティ表明保証条項2.1.4------------------------------------------------------ 9.6.5 他の関係者の表明保証条項、なし。------------------------------------------------------ 9.7 保証2.2、2.3.2に関する注意書き------------------------------------------------------ 9.8 責任2.2の制限------------------------------------------------------ 9.9の保障、2.1 .3 2.1 .4、2.2、2.3、.1------------------------------------------------------ 9.10の用語と終了、なし。------------------------------------------------------ 9.10.1 用語、なし。------------------------------------------------------ 9.10.2 終了、なし。------------------------------------------------------ 9.10.3 契約終了の効果と生存、なし。------------------------------------------------------ 9.11 関係者2.4.2との個々の通知とコミュニケーション------------------------------------------------------ 9.12 米国憲法の修正条項8.1
Chokhani, et al. Informational [Page 87] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [87ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
------------------------------------------------------
9.12.1 Procedure for Amendment 8.1
------------------------------------------------------
9.12.2 Notification Mechanism
and Period 8.1
------------------------------------------------------
9.12.3 Circumstances Under Which OID
Must be Changed 8.1
------------------------------------------------------
9.13 Dispute Resolution Provisions 2.4.3
------------------------------------------------------
9.14 Governing Law 2.4.1
------------------------------------------------------
9.15 Compliance with Applicable Law 2.4.1
------------------------------------------------------
9.16 Miscellaneous Provisions 2.4
------------------------------------------------------
9.16.1 Entire Agreement 2.4.2
------------------------------------------------------
9.16.2 Assignment N/A
------------------------------------------------------
9.16.3 Severability 2.4.2
------------------------------------------------------
9.16.4 Enforcement (Attorney's Fees
and Waiver of Rights) 2.4.3
------------------------------------------------------
9.17 Other Provisions N/A
------------------------------------------------------
------------------------------------------------------ 9.12.1 修正8.1のための手順------------------------------------------------------ 9.12.2 通知メカニズムと期間8.1------------------------------------------------------ 9.12.3 事情Under Which OID Must、Changed8.1になってください。------------------------------------------------------ 9.13 論争の解決条項2.4.3------------------------------------------------------ 9.14 準拠法2.4.1------------------------------------------------------ 9.15 準拠法2.4.1への承諾------------------------------------------------------ 9.16 種々雑多な条項2.4------------------------------------------------------ 9.16.1 全体の協定2.4.2------------------------------------------------------ 9.16.2 課題、なし。------------------------------------------------------ 9.16.3 Severability2.4.2------------------------------------------------------ 9.16.4 実施(弁護士の権利の料金と権利放棄)2.4.3------------------------------------------------------ 他の9.17の条項、なし。------------------------------------------------------
8. Acknowledgements
8. 承認
The development of the predecessor document (RFC 2527) was supported by the Government of Canada's Policy Management Authority (PMA) Committee, the National Security Agency, the National Institute of Standards and Technology (NIST), and the American Bar Association Information Security Committee Accreditation Working Group.
前任者ドキュメント(RFC2527)の開発はカナダのPolicy Management Authority(PMA)委員会の政府、国家安全保障局、米国商務省標準技術局(NIST)、およびアメリカ法曹協会情報Security Committee Accreditation作業部会によってサポートされました。
This revision effort is largely a result of constant inspiration from Michael Baum. Michael Power, Mike Jenkins, and Alice Sturgeon have also made several contributions.
この改正取り組みは主にマイケルバウムからの一定のインスピレーションの結果です。 また、マイケルPower、マイク・ジェンキンス、およびアリス・スタージャンはいくつかの貢献をしました。
9. References
9. 参照
[ABA1] American Bar Association, Digital Signature Guidelines: Legal
Infrastructure for Certification Authorities and Secure
Electronic Commerce, 1996.
[ABA1]アメリカ法曹協会、デジタル署名ガイドライン: 証明当局と安全な電子通商のための法的基盤、1996。
Chokhani, et al. Informational [Page 88] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [88ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
[ABA2] American Bar Association, PKI Assessment Guidelines, v0.30,
Public Draft For Comment, June 2001.
[ABA2] アメリカ法曹協会、PKI Assessment Guidelines、v0.30、Public Draft For Comment、2001年6月。
[BAU1] Michael. S. Baum, Federal Certification Authority Liability
and Policy, NIST-GCR-94-654, June 1994, available at
http://www.verisign.com/repository/pubs/index.html.
[BAU1]マイケル。 S。 1994年6月に http://www.verisign.com/repository/pubs/index.html に手があいている連邦政府の認証局のバウムとLiabilityとPolicy、NIST-GCR-94-654。
[ETS] European Telecommunications Standards Institute, "Policy
Requirements for Certification Authorities Issuing Qualified
Certificates," ETSI TS 101 456, Version 1.1.1, December 2000.
ヨーロッパのテレコミュニケーション規格が設ける[ETS]、「証明当局発行のための方針要件は証明書に資格を与えました」、ETSI t101 456、バージョン、1.1、.1、12月2000日
[GOC] Government of Canada PKI Policy Management Authority, "Digital
Signature and Confidentiality Certificate Policies for the
Government of Canada Public Key Infrastructure," v.3.02, April
1999.
[GOC]カナダ政府PKI Policy Management Authority、「デジタル署名と秘密性はカナダ政府公開鍵暗号基盤のために方針を証明します」、v.3.02、1999年4月。
[IDT] Identrus, LLC, "Identrus Identity Certificate Policy" IP-IPC
Version 1.7, March 2001.
[IDT] Identrus、LLC、「Identrusアイデンティティ証明書方針」IP-IPCバージョン1.7、2001年3月。
[ISO1] ISO/IEC 9594-8/ITU-T Recommendation X.509, "Information
Technology - Open Systems Interconnection: The Directory:
Authentication Framework," 1997 edition. (Pending publication
of 2000 edition, use 1997 edition.)
[ISO1]ISO/IEC ITU9594-8/T推薦X.509、「情報技術--オープン・システム・インターコネクション:、」 ディレクトリ: 「認証Framework」、1997年の版。 (2000年の版の公表まで、1997年の版を使用してください。)
[PEM1] Kent, S., "Privacy Enhancement for Internet Electronic Mail:
Part II: Certificate-Based Key Management", RFC 1422, February
1993.
[PEM1]ケント、S.、「インターネット電子メールのためのプライバシー増進:」 パートII: 「証明書ベースのKey Management」、RFC1422、1993年2月。
[PKI1] 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.
[PKI1] HousleyとR.とポークとW.フォードとW.と一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280、2002年4月。
[CPF] Chokhani, S. and W. Ford, "Internet X.509 Public Key
Infrastructure, Certificate Policy and Certification Practices
Statement Framework", RFC 2527, March 1999.
[CPF] Chokhani、S.、およびW.フォード、「インターネットX.509公開鍵基盤、方針を証明してください。そうすれば、証明は声明フレームワークを練習します」、RFC2527、1999年3月。
10. Notes
10. 注意
1. A paper copy of the ABA Digital Signature Guidelines can be
purchased from the ABA. See http://www.abanet.com for ordering
details. The DSG may also be downloaded without charge from the
ABA website at
http://www.abanet.org/scitech/ec/isc/digital_signature.html.
1. ABAからABA Digital Signature Guidelinesの紙のコピーを購入できます。 詳細を注文するために http://www.abanet.com を見てください。 また、 http://www.abanet.org/scitech/ec/isc/digital_signature.html のABAウェブサイトからDSGを無償にダウンロードするかもしれません。
2. A draft of the PKI Assessment Guidelines may be downloaded
without charge from the ABA website at
http://www.abanet.org/scitech/ec/isc/pag/pag.html.
2. http://www.abanet.org/scitech/ec/isc/pag/pag.html のABAウェブサイトからPKI Assessment Guidelinesの草稿を無償にダウンロードするかもしれません。
Chokhani, et al. Informational [Page 89] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [89ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
3. The term "meaningful" means that the name form has commonly
understood semantics to determine the identity of a person and/or
organization. Directory names and RFC 822 names may be more or
less meaningful.
3. 「重要である」という用語は、名前フォームが、意味論が人、そして/または、組織のアイデンティティを決定するのを一般的に理解していたことを意味します。 ディレクトリ名とRFC822名は多少重要であるかもしれません。
4. The subject may not need to prove to the CA that the subject has
possession of the private key corresponding to the public key
being registered if the CA generates the subject's key pair on
the subject's behalf.
4. 対象は、カリフォルニアが対象に代わって対象の主要な組を発生させるなら公開鍵に対応する秘密鍵の所有物が対象が登録させているとカリフォルニアに立証する必要はないかもしれません。
5. Examples of means to identify and authenticate individuals
include biometric means (such as thumb print, ten finger print,
and scan of the face, palm, or retina), a driver's license, a
credit card, a company badge, and a government badge.
5. 個人を特定して、認証する手段に関する例はバイオメトリックな手段(表面、掌、または網膜の10の親指印刷や、指の印刷や、スキャンなどの)、運転免許証、クレジットカード、社員バッジ、および政府バッジを含んでいます。
6. Certificate "modification" does not refer to making a change to
an existing certificate, since this would prevent the
verification of any digital signatures on the certificate and
cause the certificate to be invalid. Rather, the concept of
"modification" refers to a situation where the information
referred to in the certificate has changed or should be changed,
and the CA issues a new certificate containing the modified
information. One example is a subscriber that changes his or her
name, which would necessitate the issuance of a new certificate
containing the new name.
6. 「変更」という証明書は既存の証明書への変更を行うのを示しません、これが、証明書におけるどんなデジタル署名の検証も防いで、証明書が無効であることを引き起こすでしょう、したがって。 むしろ、「変更」の概念を証明書に示された情報が変化したところと状況を呼ぶべきであるか、または変えるべきです、そして、カリフォルニアは変更された情報を含む新しい証明書を発行します。 1つの例が新しい名前を含む新しい証明書の発行を必要とするだろうその人の名前を変える加入者です。
7. The n out of m rule allows a private key to be split in m parts.
The m parts may be given to m different individuals. Any n parts
out of the m parts may be used to fully reconstitute the private
key, but having any n-1 parts provides one with no information
about the private key.
7. 規則がmで部品を分けることであることを秘密鍵を許容するmからのn。 mの異なった個人にmの部品を与えるかもしれません。 mの部品からのどんなn部品も秘密鍵を完全に再編成するのに使用されるかもしれませんが、どんなn-1の部品も持っている場合、秘密鍵の情報は全く1つに提供されません。
8. A private key may be escrowed, backed up, or archived. Each of
these functions has a different purpose. Thus, a private key may
go through any subset of these functions depending on the
requirements. The purpose of escrow is to allow a third party
(such as an organization or government) to obtain the private key
without the cooperation of the subscriber. The purpose of back
up is to allow the subscriber to reconstitute the key in case of
the destruction or corruption of the key for business continuity
purposes. The purpose of archives is to provide for reuse of the
private key in the future, e.g., use to decrypt a document.
8. 秘密鍵は、escrowedされるか、支援されるか、または格納されるかもしれません。 それぞれのこれらの機能には、異なる役割があります。 したがって、要件によって、秘密鍵はこれらの機能のどんな部分集合を通っても行くかもしれません。 エスクローの目的は第三者(組織か政府などの)が加入者の協力なしで秘密鍵を得るのを許容することです。 逆上の目的は加入者がキーの破壊か不正の場合にビジネス継続性目的のためにキーを再編成するのを許容することです。 アーカイブの目的は未来(例えば、ドキュメントを解読する使用)の秘密鍵の再利用に備えることです。
9. WebTrust refers to the "WebTrust Program for Certification
Authorities," from the American Institute of Certified Public
Accountants, Inc., and the Canadian Institute of Chartered
Accountants.
9. WebTrustは「WebTrustは証明当局のためにプログラムを作ること」を参照します、公認会計士協会Inc.、およびChartered AccountantsのカナダのInstituteから。
Chokhani, et al. Informational [Page 90] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [90ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
10. See <http://www.aicpa.org>.
10. <http://www.aicpa.org>を見てください。
11. All or some of the following items may be different for the
various types of entities, i.e., CA, RA, and end entities.
11. すなわち、様々なタイプの実体、カリフォルニア、RA、および終わりの実体において、すべてか以下の数個の項目が、異なっているかもしれません。
11. List of Acronyms
11. 頭文字語のリスト
ABA - American Bar Association CA - Certification Authority CP - Certificate Policy CPS - Certification Practice Statement CRL - Certificate Revocation List DAM - Draft Amendment FIPS - Federal Information Processing Standard I&A - Identification and Authentication IEC - International Electrotechnical Commission IETF - Internet Engineering Task Force IP - Internet Protocol ISO - International Organization for Standardization ITU - International Telecommunications Union NIST - National Institute of Standards and Technology OID - Object Identifier PIN - Personal Identification Number PKI - Public Key Infrastructure PKIX - Public Key Infrastructure (X.509) (IETF Working Group) RA - Registration Authority RFC - Request For Comment URL - Uniform Resource Locator US - United States
アバ--アメリカ法曹協会カリフォルニア--認証局CP--証明書方針CPS--認証実施規定CRL--証明書失効リストダム--修正案FIPS--連邦情報処理基準私と--識別と認証IEC--国際電気標準化会議IETF--国際インターネット・エンジニアリング・タスク・フォースIP(インターネットプロトコルISO); 標準化ITUのための組織--国際電気通信組合NIST--米国商務省標準技術局OID--物の識別子暗証番号--個人識別番号PKI--公開鍵暗号基盤PKIX--公開鍵暗号基盤(X.509)(IETF作業部会)RA(登録局RFC)はコメントURL(Uniform Resource Locator米国)のために合衆国を要求します。
Chokhani, et al. Informational [Page 91] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [91ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
12. Authors' Addresses
12. 作者のアドレス
Santosh Chokhani Orion Security Solutions, Inc. 3410 N. Buchanan Street Arlington, VA 22207
アーリントン、Santosh ChokhaniオリオンセキュリティソリューションInc.3410N.ブキャナン・ストリートヴァージニア 22207
Phone: (703) 237-4621 Fax: (703) 237-4920 EMail: chokhani@orionsec.com
以下に電話をしてください。 (703) 237-4621 Fax: (703) 237-4920 メールしてください: chokhani@orionsec.com
Warwick Ford VeriSign, Inc. 6 Ellery Square Cambridge, MA 02138
ウォリックフォードベリサインInc.6エラリー正方形のケンブリッジ(MA)02138
Phone: (617) 642-0139 EMail: wford@verisign.com
以下に電話をしてください。 (617) 642-0139 メールしてください: wford@verisign.com
Randy V. Sabett, J.D., CISSP Cooley Godward LLP One Freedom Square, Reston Town Center 11951 Freedom Drive Reston, VA 20190-5656
ランディV.Sabett、J.D.、CISSPクーリーGodward LLP1つの自由正方形、レストン、レストンの町のセンター11951自由Driveヴァージニア20190-5656
Phone: (703) 456-8137 Fax: (703) 456-8100 EMail: rsabett@cooley.com
以下に電話をしてください。 (703) 456-8137 Fax: (703) 456-8100 メールしてください: rsabett@cooley.com
Charles (Chas) R. Merrill McCarter & English, LLP Four Gateway Center 100 Mulberry Street Newark, New Jersey 07101-0652
チャールズ・(Chas)R.メリルMcCarterと英語、LLP Fourゲートウェイセンター100マルベリー・ストリートニューアーク、ニュージャージー07101-0652
Phone: (973) 622-4444 Fax: (973) 624-7070 EMail: cmerrill@mccarter.com
以下に電話をしてください。 (973) 622-4444 Fax: (973) 624-7070 メールしてください: cmerrill@mccarter.com
Chokhani, et al. Informational [Page 92] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [92ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
Stephen S. Wu Infoliance, Inc. 800 West El Camino Real Suite 180 Mountain View, CA 94040
マウンテンビュー、スティーブンS.ウーInfoliance Inc.800の西高架鉄道幹線道路Suite180カリフォルニア 94040
Phone: (650) 917-8045 Fax: (650) 618-1454 EMail: swu@infoliance.com
以下に電話をしてください。 (650) 917-8045 Fax: (650) 618-1454 メールしてください: swu@infoliance.com
Chokhani, et al. Informational [Page 93] RFC 3647 Internet X.509 Public Key Infrastructure November 2003
Chokhani、他 [93ページ]情報のRFC3647インターネットX.509公開鍵暗号基盤2003年11月
13. Full Copyright Statement
13. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 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 assignees.
上に承諾された限られた許容は、永久であり、そのインターネット協会、後継者または指定代理人によって取り消されないでしょう。
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機能のための基金は現在、インターネット協会によって提供されます。
Chokhani, et al. Informational [Page 94]
Chokhani、他 情報[94ページ]
一覧
スポンサーリンク
