RFC1422 日本語訳
1422 Privacy Enhancement for Internet Electronic Mail: Part II:Certificate-Based Key Management. S. Kent. February 1993. (Format: TXT=86085 bytes) (Obsoletes RFC1114) (Status: HISTORIC)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group S. Kent
Request for Comments: 1422 BBN
Obsoletes: 1114 IAB IRTF PSRG, IETF PEM
February 1993
コメントを求めるワーキンググループS.ケント要求をネットワークでつないでください: 1422BBNは以下を時代遅れにします。 1114IAB IRTF PSRG、IETF PEM1993年2月
Privacy Enhancement for Internet Electronic Mail:
Part II: Certificate-Based Key Management
インターネット電子メールのためのプライバシー増進: パートII: 証明書ベースのKey Management
Status of this Memo
このMemoの状態
This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このRFCはIAB標準化過程プロトコルをインターネットコミュニティに指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Acknowledgements
承認
This memo is the outgrowth of a series of meetings of the Privacy and Security Research Group of the Internet Research Task Force (IRTF) and the Privacy-Enhanced Electronic Mail Working Group of the Internet Engineering Task Force (IETF). I would like to thank the members of the PSRG and the PEM WG for their comments and contributions at the meetings which led to the preparation of this document. I also would like to thank contributors to the PEM-DEV mailing list who have provided valuable input which is reflected in this memo.
このメモはインターネットResearch Task Force(IRTF)のPrivacyとSecurity Research GroupとPrivacyによって高められたElectronicメールインターネット・エンジニアリング・タスク・フォース作業部会(IETF)の一連のミーティングの派生物です。 このドキュメントの準備につながったミーティングで彼らのコメントと貢献についてPSRGとPEM WGのメンバーに感謝申し上げます。 また、PEM-DEVメーリングリストへのこのメモに反映される貴重な入力を提供した貢献者に感謝申し上げます。
1. Executive Summary
1. 要約
This is one of a series of documents defining privacy enhancement mechanisms for electronic mail transferred using Internet mail protocols. RFC 1421 [6] prescribes protocol extensions and processing procedures for RFC-822 mail messages, given that suitable cryptographic keys are held by originators and recipients as a necessary precondition. RFC 1423 [7] specifies algorithms, modes and associated identifiers for use in processing privacy-enhanced messages, as called for in RFC 1421 and this document. This document defines a supporting key management architecture and infrastructure, based on public-key certificate techniques, to provide keying information to message originators and recipients. RFC 1424 [8] provides additional specifications for services in conjunction with the key management infrastructure described herein.
これはインターネットメールプロトコルを使用することで移された電子メールのためにプライバシーエンハンスメカニズムを定義する一連のドキュメントの1つです。 RFC1421[6]はプロトコル拡大と現像処理をRFC-822メール・メッセージに定めます、適当な暗号化キーが必要な前提条件として創始者と受取人によって持たれているなら。 RFC1423[7]はプライバシーで高められたメッセージを処理することにおける使用のためのアルゴリズム、モード、および関連識別子を指定します、RFC1421とこのドキュメントで求められるように。 このドキュメントは、メッセージ創始者と受取人に情報を合わせながら提供するために公開鍵証明書のテクニックに基づくサポートの主要な管理体系とインフラストラクチャを定義します。 RFC1424[8]はここに説明されたかぎ管理インフラストラクチャに関連してサービスのための追加仕様を提供します。
The key management architecture described in this document is compatible with the authentication framework described in CCITT 1988 X.509 [2]. This document goes beyond X.509 by establishing
本書では説明されたかぎ管理アーキテクチャはCCITT1988X.509[2]で説明される認証フレームワークと互換性があります。 このドキュメントは、創業することによって、X.509を越えます。
Kent [Page 1] RFC 1422 Certificate-Based Key Management February 1993
Key Management1993年2月の証明書ベースのケント[1ページ]RFC1422
procedures and conventions for a key management infrastructure for use with Privacy Enhanced Mail (PEM) and with other protocols, from both the TCP/IP and OSI suites, in the future. There are several motivations for establishing these procedures and conventions (as opposed to relying only on the very general framework outlined in X.509):
未来のTCP/IPとOSIスイートの両方からのPrivacy Enhancedメール(PEM)と他のプロトコルによる使用のためのかぎ管理インフラストラクチャのための手順とコンベンション。 これらの手順とコンベンション(X.509に概説された非常に一般的なフレームワークだけを当てにすることと対照的に)を確立することに関するいくつかの動機があります:
-It is important that a certificate management infrastructure
for use in the Internet community accommodate a range of
clearly-articulated certification policies for both users
and organizations in a well-architected fashion.
Mechanisms must be provided to enable each user to be
aware of the policies governing any certificate which the
user may encounter. This requires the introduction
and standardization of procedures and conventions that are
outside the scope of X.509.
-よくarchitectedされたファッションでインターネットコミュニティにおける使用のための証明書管理インフラストラクチャがユーザと組織の両方のためのさまざまな明確に明確に話された証明方針に対応するのは、重要です。 それぞれのユーザが方針がユーザが遭遇するどんな証明書も支配するのを意識しているのを可能にするためにメカニズムを提供しなければなりません。 これはX.509の範囲の外にある手順とコンベンションの序論と標準化を必要とします。
-The procedures for authenticating originators and recipient in
the course of message submission and delivery should be
simple, automated and uniform despite the existence of
differing certificate management policies. For example,
users should not have to engage in careful examination of a
complex set of certification relationships in order to
evaluate the credibility of a claimed identity.
-メッセージ提案と配送の間に創始者と受取人を認証するための手順は、簡単で、自動化されて異なった証明書経営政策の存在にもかかわらず、一定であるべきです。 例えば、ユーザは、要求されたアイデンティティの真実性を評価するために複雑な証明関係の慎重な検討に従事する必要はないはずです。
-The authentication framework defined by X.509 is designed to
operate in the X.500 directory server environment. However
X.500 directory servers are not expected to be ubiquitous
in the Internet in the near future, so some conventions
are adopted to facilitate operation of the key management
infrastructure in the near term.
-X.509によって定義された認証フレームワークは、X.500ディレクトリサーバ環境で作動するように設計されています。 しかしながら、X.500ディレクトリサーバが近い将来インターネットに遍在させていないと予想されるので、いくつかのコンベンションが近いうちにかぎ管理インフラストラクチャの操作を容易にするために採用されます。
-Public key cryptosystems are central to the authentication
technology of X.509 and those which enjoy the most
widespread use are patented in the U.S. Although this
certification management scheme is compatible with
the use of different digital signature algorithms, it is
anticipated that the RSA cryptosystem will be used as
the primary signature algorithm in establishing the
Internet certification hierarchy. Special license
arrangements have been made to facilitate the
use of this algorithm in the U.S. portion of Internet
environment.
-公開鍵暗号方式はX.509の認証技術に主要です、そして、最も多くの普及使用を楽しむものが米国で特許をとられます。この証明経営者側が計画するAlthoughは異なったデジタル署名アルゴリズムの使用と互換性がある、RSA暗号系がプライマリ署名アルゴリズムとしてインターネット証明階層構造を確立する際に使用されると予期されます。 インターネット環境の米国の部分でのこのアルゴリズムの使用を容易にするのを結婚特別許可証手配をしました。
The infrastructure specified in this document establishes a single root for all certification within the Internet, the Internet Policy Registration Authority (IPRA). The IPRA establishes global policies, described in this document, which apply to all certification effected
本書では指定されたインフラストラクチャはインターネット(インターネットPolicy Registration Authority(IPRA))の中のすべての証明のためにただ一つの根を確立します。 IPRAは作用するすべての証明に適用される本書では説明されたグローバルな方針を確立します。
Kent [Page 2] RFC 1422 Certificate-Based Key Management February 1993
Key Management1993年2月の証明書ベースのケント[2ページ]RFC1422
under this hierarchy. Beneath IPRA root are Policy Certification Authorities (PCAs), each of which establishes and publishes (in the form of an informational RFC) its policies for registration of users or organizations. Each PCA is certified by the IPRA. (It is desirable that there be a relatively small number of PCAs, each with a substantively different policy, to facilitate user familiarity with the set of PCA policies. However there is no explicit requirement that the set of PCAs be limited in this fashion.) Below PCAs, Certification Authorities (CAs) will be established to certify users and subordinate organizational entities (e.g., departments, offices, subsidiaries, etc.). Initially, we expect the majority of users will be registered via organizational affiliation, consistent with current practices for how most user mailboxes are provided. In this sense the registration is analogous to the issuance of a university or company ID card.
この階層構造の下で。 IPRA根の下に、Policy Certification Authorities(PCAs)があります。それぞれユーザか組織の登録のための方針を確立して、それは発行します(情報のRFCの形で)。 各PCAはIPRAによって公認されます。 (そこに、いてください。それが望ましい、それ、比較的少ない数のPCAs、PCA方針のセットへのユーザ親しみを容易にする実質的に異なった方針があるそれぞれ。 しかしながら、PCAsのセットがこんなやり方で制限されるというどんな明白な要件もありません。) PCAsの下では、Certification Authorities(CAs)は、ユーザと下位の組織的な実体が(例えば、部、オフィス、子会社など)であると公認するために設立されるでしょう。 初めは、私たちは、ユーザの大部分が組織的な所属を通して示されると予想します、どうほとんどのユーザメールボックスを提供するかに現在の実務と一致しています。 この意味で、登録は大学か会社の身分証明書の発行に類似しています。
Some CAs are expected to provide certification for residential users in support of users who wish to register independent of any organizational affiliation. Over time, we anticipate that civil government entities which already provide analogous identification services in other contexts, e.g., driver's licenses, may provide this service. For users who wish anonymity while taking advantage of PEM privacy facilities, one or more PCAs will be established with policies that allow for registration of users, under subordinate CAs, who do not wish to disclose their identities.
いくつかのCAsがどんな組織的な所属の如何にかかわらず登録したがっているユーザを支持して住宅のユーザに証明を提供すると予想されます。 時間がたつにつれて、私たちは、既に類似の識別サービスを他の文脈に提供する民政実体(例えば、運転免許証)がこのサービスを提供するかもしれないと予期します。 PEMプライバシー施設を利用している間に匿名を願っているユーザに関しては、1PCAsがユーザの登録を考慮する方針で設立されるでしょう、下位のCAsの下で。CAsは彼らのアイデンティティを明らかにしたがっていません。
2. Overview of Approach
2. アプローチの概要
This document defines a key management architecture based on the use of public-key certificates, primarily in support of the message encipherment and authentication procedures defined in RFC 1421. The concept of public-key certificates is defined in X.509 and this architecture is a compliant subset of that envisioned in X.509.
このドキュメントは公開鍵証明書の使用に基づくかぎ管理アーキテクチャを定義します、主としてRFC1421で定義されたメッセージ暗号文と認証手順を支持して。 公開鍵証明書の概念はX.509で定義されます、そして、このアーキテクチャはX.509で思い描かれたその対応する部分集合です。
Briefly, a (public-key) certificate is a data structure which contains the name of a user (the "subject"), the public component (This document adopts the terms "private component" and "public component" to refer to the quantities which are, respectively, kept secret and made publicly available in asymmetric cryptosystems. This convention is adopted to avoid possible confusion arising from use of the term "secret key" to refer to either the former quantity or to a key in a symmetric cryptosystem.) of that user, and the name of an entity (the "issuer") which vouches that the public component is bound to the named user. This data, along with a time interval over which the binding is claimed to be valid, is cryptographically signed by the issuer using the issuer's private component. The subject and issuer names in certificates are Distinguished Names (DNs) as defined in the directory system (X.500).
簡潔に、(公開鍵)証明書はユーザ(「対象」)の名前を含むデータ構造です; このドキュメントは、それぞれ秘密にされて、非対称の暗号系で公的に利用可能にされる量について言及するために用語「個人的なコンポーネント」と「公共のコンポーネント」を採用します。そのユーザの公共のコンポーネント(このコンベンションは左右対称の暗号系で前の量かキーを参照するために「秘密鍵」という用語の使用から起こる可能な混乱を避けるために採用されます。); そして、太鼓判を押す公共のコンポーネントがある実体(「発行人」)の名前は命名されたユーザに付きました。 発行人の個人的なコンポーネントを使用することでこのデータは結合が有効であると主張される時間間隔と共に発行人によって暗号で署名されます。 証明書の対象と発行人名はディレクトリシステム(X.500)で定義されるようにDistinguished Names(DNs)です。
Kent [Page 3] RFC 1422 Certificate-Based Key Management February 1993
Key Management1993年2月の証明書ベースのケント[3ページ]RFC1422
Once signed, certificates can be stored in directory servers, transmitted via non-secure message exchanges, or distributed via any other means that make certificates easily accessible to message system users, without regard for the security of the transmission medium. Certificates are used in PEM to provide the originator of a message with the (authenticated) public component of each recipient and to provide each recipient with the (authenticated) public component of the originator. The following brief discussion illustrates the procedures for both originator and recipients.
一度署名されます、証明書をディレクトリサーバで保存するか、非安全な交換処理で伝えられるか、または証明書をメッセージシステムユーザには容易にアクセスしやすくするいかなる他の手段でも配布できます、トランスミッション媒体のセキュリティへの尊敬なしで。 証明書は、それぞれの受取人の(認証されます)公共のコンポーネントをメッセージの創始者に提供して、創始者の(認証されます)公共のコンポーネントを各受取人に提供するのにPEMで使用されます。 以下の簡潔な議論は創始者と受取人の両方のために手順を例証します。
Prior to sending an encrypted message (using PEM), an originator must acquire a certificate for each recipient and must validate these certificates. Briefly, validation is performed by checking the digital signature in the certificate, using the public component of the issuer whose private component was used to sign the certificate. The issuer's public component is made available via some out of band means (for the IPRA) or is itself distributed in a certificate to which this validation procedure is applied recursively. In the latter case, the issuer of a user's certificate becomes the subject in a certificate issued by another certifying authority (or a PCA), thus giving rise to a certification hierarchy. The validity interval for each certificate is checked and Certificate Revocation Lists (CRLs) are checked to ensure that none of the certificates employed in the validation process has been revoked by an issuer.
暗号化メッセージ(PEMを使用する)を送る前に、創始者は、各受取人への証明書を入手しなければならなくて、これらの証明書を有効にしなければなりません。 簡潔に、合法化は証明書におけるデジタル署名をチェックすることによって、実行されます、個人的なコンポーネントが証明書に署名するのに使用された発行人の公共のコンポーネントを使用して。 発行人の公共のコンポーネントは、バンド手段(IPRAのための)からのいくつかを通して利用可能に作られているか、またはこの合法化手順が再帰的に適用される証明書で分配されます。 後者の場合では、ユーザの証明書の発行人は権威(または、PCA)を公認しながら別のものによって発行された証明書で対象になります、その結果、証明階層構造をもたらします。 各証明書のための正当性間隔はチェックされます、そして、Certificate Revocation Lists(CRLs)は、合法化プロセスで使われた証明書のいずれも発行人によって取り消されていないのを保証するためにチェックされます。
Once a certificate for a recipient is validated, the public component contained in the certificate is extracted and used to encrypt the data encryption key (DEK), which, in turn, is used to encrypt the message itself. The resulting encrypted DEK is incorporated into the Key-Info field of the message header. Upon receipt of an encrypted message, a recipient employs his private component to decrypt this field, extracting the DEK, and then uses this DEK to decrypt the message.
受取人への証明書がいったん有効にされると、証明書に含まれた公共のコンポーネントは、データ暗号化キー(DEK)を暗号化するのに抽出されて、使用されます。(キーは、メッセージ自体を暗号化するのに順番に使用されます)。 結果として起こる暗号化されたDEKはメッセージヘッダーのKey-インフォメーション分野に組み入れられます。 暗号化メッセージを受け取り次第、受取人は、DEKを抽出して、この分野を解読するのに彼の個人的なコンポーネントを使って、次に、メッセージを解読するのにこのDEKを使用します。
In order to provide message integrity and data origin authentication, the originator generates a message integrity code (MIC), signs (encrypts) the MIC using the private component of his public-key pair, and includes the resulting value in the message header in the MIC-Info field. The certificate of the originator is (optionally) included in the header in the Certificate field as described in RFC 1421. This is done in order to facilitate validation in the absence of ubiquitous directory services. Upon receipt of a privacy enhanced message, a recipient validates the originator's certificate (using the IPRA public component as the root of a certification path), checks to ensure that it has not been revoked, extracts the public component from the certificate, and uses that value to recover (decrypt) the MIC. The recovered MIC is compared against the locally calculated MIC to verify the integrity and data origin authenticity
発生源認証をメッセージの保全とデータに提供するために、創始者は、メッセージの保全がコード(MIC)であると生成して、彼の公開鍵組の個人的なコンポーネントを使用することでMICに署名して(暗号化します)、MIC-インフォメーション分野のメッセージヘッダーで結果として起こる値を入れます。 創始者の証明書はRFC1421で説明されるようにCertificate分野のヘッダーに(任意に)含まれています。 遍在しているディレクトリサービスがないとき合法化を容易にするためにこれをします。 プライバシーの高められたメッセージを受け取り次第、受取人は創始者の証明書を有効にします(証明経路の根としてIPRAの公共の部品を使用して)、とMICは取り消されていなくて、証明書から公共のコンポーネントを抽出して、回復すること(解読する)にその値を使用するのを保証するためにチェックします。 回復しているMICは、保全とデータ発生源の信憑性について確かめるために局所的に計算されたMICに対して比較されます。
Kent [Page 4] RFC 1422 Certificate-Based Key Management February 1993
Key Management1993年2月の証明書ベースのケント[4ページ]RFC1422
of the message.
メッセージについて。
3. Architecture
3. アーキテクチャ
3.1 Scope and Restrictions
3.1 範囲と制限
The architecture described below is intended to provide a basis for managing public-key cryptosystem values in support of privacy enhanced electronic mail in the Internet environment. The architecture describes procedures for registering certification authorities and users, for generating and distributing certificates, and for generating and distributing CRLs. RFC 1421 describes the syntax and semantics of header fields used to transfer certificates and to represent the DEK and MIC in this public-key context. Definitions of the algorithms, modes of use and associated identifiers are separated in RFC 1423 to facilitate the adoption of additional algorithms in the future. This document focuses on the management aspects of certificate-based, public-key cryptography for privacy enhanced mail.
以下で説明されたアーキテクチャがインターネット環境におけるプライバシーの高められた電子メールを支持して公開鍵暗号系値を管理する基礎を提供することを意図します。 アーキテクチャはCRLsを証明当局とユーザを登録して、証明書を生成して、配布して、生成して、分配するための手順について説明します。 RFC1421は証明書を移して、この公開鍵文脈にDEKとMICを表すのに使用されるヘッダーフィールドの構文と意味論について説明します。 アルゴリズムの定義、使用と関連識別子のモードは、将来追加アルゴリズムの採用を容易にするためにRFC1423で切り離されます。 このドキュメントはプライバシーの高められたメールのために証明書ベースの公開鍵暗号の管理局面に焦点を合わせます。
The proposed architecture imposes conventions for the certification hierarchy which are not strictly required by the X.509 recommendation nor by the technology itself. These conventions are motivated by several factors, primarily the need for authentication semantics compatible with automated validation and the automated determination of the policies under which certificates are issued.
提案されたアーキテクチャは証明階層構造のためのX.509推薦と技術自体によって厳密に必要とされないコンベンションを課します。 これらのコンベンションはいくつかの要素、主として自動化された合法化とのコンパチブル認証意味論の必要性、および証明書が発行される方針の自動化された決断で動機づけられています。
Specifically, the architecture proposes a system in which user (or mailing list) certificates represent the leaves in a certification hierarchy. This certification hierarchy is largely isomorphic to the X.500 directory naming hierarchy, with two exceptions: the IPRA forms the root of the tree (the root of the X.500 DIT is not instantiated as a node), and a number of Policy Certification Authorities (PCAs) form the "roots" of subtrees, each of which represents a different certification policy.
明確に、アーキテクチャはユーザ(または、メーリングリスト)証明書が証明階層構造で葉を表すシステムを提案します。 この証明階層構造は2つの例外でX.500ディレクトリ命名階層構造に主に同型です: IPRAは木の根を形成して(X.500 DITの根はノードとして例示されません)、多くのPolicy Certification Authorities(PCAs)が下位木の「ルーツ」を形成します。それはそれぞれ異なった証明方針を表します。
Not every level in the directory hierarchy need correspond to a certification authority. For example, the appearance of geographic entities in a distinguished name (e.g., countries, states, provinces, localities) does not require that various governments become certifying authorities in order to instantiate this architecture. However, it is anticipated that, over time, a number of such points in the hierarchy will be instantiated as CAs in order to simplify later transition of management to appropriate governmental authorities.
ディレクトリ階層構造のあらゆるレベルが証明権威に対応しなければならないというわけではありません。 例えば、分類名(例えば、国、州、州、場所)における、地理的な実体の外観は、様々な政府がこのアーキテクチャを例示するために当局を公認するようになるのを必要としません。 しかしながら、階層構造のそのような多くのポイントが政府の権威を当てるために管理の後の変遷を簡素化するために時間CAsとして例示されると予期されます。
These conventions minimize the complexity of validating user certificates, e.g., by making explicit the relationship between a
これらのコンベンションは例えば、aの間の関係を明白にすることによってユーザー証明書を有効にする複雑さを最小にします。
Kent [Page 5] RFC 1422 Certificate-Based Key Management February 1993
Key Management1993年2月の証明書ベースのケント[5ページ]RFC1422
certificate issuer and the user (via the naming hierarchy). Note that in this architecture, only PCAs may be certified by the IPRA, and every CA's certification path can be traced to a PCA, through zero or more CAs. If a CA is certified by more than one PCA, each certificate issued by a PCA for the CA must contain a distinct public component. These conventions result in a certification hierarchy which is a compatible subset of that permitted under X.509, with respect to both syntax and semantics.
発行人とユーザ(命名階層構造を通した)を証明してください。 このアーキテクチャでは、IPRAがPCAsだけを公認してもよくて、ゼロか、より多くのCAsを通してあらゆるCAの証明経路はPCAにたどることができることに注意してください。 カリフォルニアが1PCAによって公認されるなら、PCAによってカリフォルニアに発行された各証明書は異なった公共のコンポーネントを含まなければなりません。 これらのコンベンションはX.509の下で受入れられたそのコンパチブル部分集合である証明階層構造をもたらします、構文と意味論の両方に関して。
Although the key management architecture described in this document has been designed primarily to support privacy enhanced mail, this infrastructure also may, in principle, be used to support X.400 mail security facilities (as per 1988 X.411) and X.500 directory authentication facilities. Thus, establishment of this infrastructure paves the way for use of these and other OSI protocols in the Internet in the future. In the future, these certificates also may be employed in the provision of security services in other protocols in the TCP/IP and OSI suites as well.
本書では説明されたかぎ管理アーキテクチャは主としてプライバシーの高められたメールをサポートするように設計されていますが、このインフラストラクチャも、X.400メールがセキュリティ施設(1988X.411に従って)とX.500ディレクトリ認証施設であるとサポートするのに原則として使用されるかもしれません。 したがって、このインフラストラクチャの確立は将来、インターネットでこれらと他のOSIプロトコルの使用へ道を開きます。 将来、これらの証明書もまた、TCP/IPとOSIスイートの他のプロトコルへのセキュリティー・サービスの支給で使われるかもしれません。
3.2 Relation to X.509 Architecture
3.2 X.509アーキテクチャとの関係
CCITT 1988 Recommendation X.509, "The Directory - Authentication Framework", defines a framework for authentication of entities involved in a distributed directory service. Strong authentication, as defined in X.509, is accomplished with the use of public-key cryptosystems. Unforgeable certificates are generated by certification authorities; these authorities may be organized hierarchically, though such organization is not required by X.509. There is no implied mapping between a certification hierarchy and the naming hierarchy imposed by directory system naming attributes.
CCITT、1988Recommendation X.509、「ディレクトリ--、認証フレームワーク、」、分配されたディレクトリサービスにかかわる実体の認証のためにフレームワークを定義します。 X.509で定義される強い認証は公開鍵暗号系の使用で実行されます。Unforgeable証明書は証明当局によって作られます。 そのような組織はX.509によって必要とされませんが、これらの当局は階層的で組織化されるかもしれません。 属性を命名するディレクトリシステムによって課された証明階層構造と命名階層構造の間には、どんな暗示しているマッピングもありません。
This document interprets the X.509 certificate mechanism to serve the needs of PEM in the Internet environment. The certification hierarchy proposed in this document in support of privacy enhanced mail is intentionally a subset of that allowed under X.509. This certification hierarchy also embodies semantics which are not explicitly addressed by X.509, but which are consistent with X.509 precepts. An overview of the rationale for these semantics is provided in Section 1.
このドキュメントは、インターネット環境における、PEMの必要性に役立つようにX.509証明書メカニズムを解釈します。 本書ではプライバシーの高められたメールを支持して提案された証明階層構造は故意に、その部分集合が下のX.509を許容したということです。 また、この証明階層構造は意味論を具体化します(明らかに扱われませんが、X.509はX.509教訓と一致させています)。 これらの意味論のための原理の概要をセクション1に提供します。
3.3 Certificate Definition
3.3 証明書定義
Certificates are central to the key management architecture for X.509 and PEM. This section provides an overview of the syntax and a description of the semantics of certificates. Appendix A includes the ASN.1 syntax for certificates. A certificate includes the following contents:
X.509とPEMに、証明書はかぎ管理アーキテクチャに主要です。 このセクションは構文の概要と証明書の意味論の記述を提供します。 付録Aは証明書のためのASN.1構文を含んでいます。 証明書は以下のコンテンツを含んでいます:
Kent [Page 6] RFC 1422 Certificate-Based Key Management February 1993
Key Management1993年2月の証明書ベースのケント[6ページ]RFC1422
1. version
1. バージョン
2. serial number
2. 通し番号
3. signature (algorithm ID and parameters)
3. 署名(アルゴリズムIDとパラメタ)
4. issuer name
4. 発行人名
5. validity period
5. 有効期間
6. subject name
6. 対象の名前
7. subject public key (and associated algorithm ID)
7. 対象の公開鍵(そして、関連アルゴリズムID)
3.3.1 Version Number
3.3.1 バージョン番号
The version number field is intended to facilitate orderly changes in certificate formats over time. The initial version number for certificates used in PEM is the X.509 default which has a value of zero (0), indicating the 1988 version. PEM implementations are encouraged to accept later versions as they are endorsed by CCITT/ISO.
バージョンナンバーフィールドが時間がたつにつれて証明書形式における秩序だった変化を容易にすることを意図します。 PEMで使用される証明書の初期のバージョン番号は(0)がない値を持っているX.509デフォルトです、1988年のバージョンを示して。 それらがCCITT/ISOによって是認されるときPEM実装が後のバージョンを受け入れるよう奨励されます。
3.3.2 Serial Number
3.3.2 通し番号
The serial number field provides a short form, unique identifier for each certificate generated by an issuer. An issuer must ensure that no two distinct certificates with the same issuer DN contain the same serial number. (This requirement must be met even when the certification function is effected on a distributed basis and/or when the same issuer DN is certified under two different PCAs. This is especially critical for residential CAs certified under different PCAs.) The serial number is used in CRLs to identify revoked certificates, as described in Section 3.4.3.4. Although this attribute is an integer, PEM UA processing of this attribute need not involve any arithmetic operations. All PEM UA implementations must be capable of processing serial numbers at least 128 bits in length, and size-independent support serial numbers is encouraged.
通し番号分野は発行人によって作られた各証明書に縮約形、ユニークな識別子を供給します。 発行人は、同じ発行人DNがある2通の異なった証明書が同じ通し番号を含まないのを確実にしなければなりません。 (証明機能が分散ベースで作用して、同じ発行人DNが2異なったPCAsであることが公認さえされるとき、この必要条件を満たさなければなりません。 異なったPCAsの下で公認された住宅のCAsに、これは特に重要です。) 通し番号は、取り消された証明書を特定するのにセクション3.4.3で.4に説明されるようにCRLsで使用されます。 この属性は整数ですが、この属性のPEM UA処理はどんな四則演算にもかかわる必要はありません。 PEM UA実装は長さ、およびサイズから独立しているサポート通し番号で通し番号を少なくとも128ビット処理しながらできなければならないすべてが奨励されます。
3.3.3 Signature
3.3.3 署名
This field specifies the algorithm used by the issuer to sign the certificate, and any parameters associated with the algorithm. (The certificate signature is appended to the data structure, as defined by the signature macro in X.509. This algorithm identification information is replicated with the signature.) The signature is validated by the UA processing a certificate, in order to determine that the integrity of its contents have not been modified subsequent
この分野はアルゴリズムに関連している証明書、およびどんなパラメタにも署名するのに発行人によって使用されたアルゴリズムを指定します。 証明書署名をデータ構造に追加します、署名マクロによってX.509で定義されるように。(このアルゴリズム識別情報は署名で模写されます。) 署名は証明書を処理するUAによって有効にされます、コンテンツの保全が変更されていないことを決定するためにその後
Kent [Page 7] RFC 1422 Certificate-Based Key Management February 1993
Key Management1993年2月の証明書ベースのケント[7ページ]RFC1422
to signing by a CA (IPRA, or PCA). In this context, a signature is effected through the use of a Certificate Integrity Check (CIC) algorithm and a public-key encryption algorithm. RFC 1423 contains the definitions and algorithm IDs for signature algorithms employed in this architecture.
カリフォルニア(IPRA、またはPCA)のそばで署名するのに。 このような関係においては、Certificate Integrity Check(CIC)アルゴリズムと公開鍵暗号化アルゴリズムの使用で署名は作用します。 RFC1423はこのアーキテクチャで使われた署名アルゴリズムのための定義とアルゴリズムIDを含んでいます。
3.3.4 Subject Name
3.3.4 対象の名前
A certificate provides a representation of its subject's identity in the form of a Distinguished Name (DN). The fundamental binding ensured by the key management architecture is that between the public component and the user's identity in this form. A distinguished name is an X.500 directory system concept and if a user is already registered in an X.500 directory, his distinguished name is defined via that registration. Users who are not registered in a directory should keep in mind likely directory naming structure (schema) when selecting a distinguished name for inclusion in a certificate.
証明書はDistinguished Name(DN)の形における、対象のアイデンティティの表現を提供します。 かぎ管理アーキテクチャによって確実にされた基本的な結合はこのフォームでの公共のコンポーネントとユーザのアイデンティティの間のそれです。 分類名はX.500ディレクトリシステム概念です、そして、ユーザがX.500ディレクトリに既に登録されるなら、彼の分類名はその登録で定義されます。 証明書での包含のために分類名を選択するとき、ディレクトリに登録されないユーザはありそうなディレクトリ命名構造(図式)を覚えておくべきです。
3.3.5 Issuer Name
3.3.5 発行人名
A certificate provides a representation of its issuer's identity, in the form of a Distinguished Name. The issuer identification is used to select the appropriate issuer public component to employ in performing certificate validation. (If an issuer (CA) is certified by multiple PCAs, then the issuer DN does not uniquely identify the public component used to sign the certificate. In such circumstances it may be necessary to attempt certificate validation using multiple public components, from certificates held by the issuer under different PCAs. If the 1992 version of a certificate is employed, the issuer may employ distinct issuer UIDs in the certificates it issues, to further facilitate selection of the right issuer public component.) The issuer is the certifying authority (IPRA, PCA or CA) who vouches for the binding between the subject identity and the public key contained in the certificate.
証明書はDistinguished Nameの形における、発行人のアイデンティティの表現を提供します。 発行人識別は、証明書合法化を実行する際に雇用への適切な発行人公共のコンポーネントを選択するのに使用されます。 (発行人(カリフォルニア)が複数のPCAsによって公認されるなら、発行人DNは唯一証明書に署名するのに使用される公共のコンポーネントを特定しません。 そのような事情では、複数の公共のコンポーネントを使用する証明書合法化を試みるのが必要であるかもしれません、異なったPCAsの下に発行人によって保持された証明書から。 1992年の証明書のバージョンが採用しているなら、発行人は、さらに正しい発行人の公共のコンポーネントの選択を容易にするのにそれが発行する証明書で異なった発行人UIDsを使うかもしれません。) 発行人は対象のアイデンティティと証明書に含まれた公開鍵の間の結合を保証する公認権威(IPRA、PCAまたはカリフォルニア)です。
3.3.6 Validity Period
3.3.6 有効期間
A certificate carries a pair of date and time indications, indicating the start and end of the time period over which a certificate is intended to be used. The duration of the interval may be constant for all user certificates issued by a given CA or it might differ based on the nature of the user's affiliation. For example, an organization might issue certificates with shorter intervals to temporary employees versus permanent employees. It is recommended that the UTCT (Coordinated Universal Time) values recorded here specify granularity to no more than the minute, even though finer granularity can be expressed in the format. (Implementors are warned that no DER is defined for UTCT in X.509, thus transformation between
証明書は1組の日時のしるしを載せます、証明書が使用されることを意図する期間の始めと終わりを示して。 与えられたカリフォルニアによって発行されたすべてのユーザー証明書に、間隔の持続時間が一定であるかもしれませんか、またはそれはユーザの提携の自然に基づいて異なるかもしれません。 例えば、組織は臨時従業員対正社員により短い間隔がある証明書を発行するかもしれません。 ここに記録されたUTCT(協定世界時)値が分だけまで粒状を指定するのは、お勧めです、形式で、よりすばらしい粒状を言い表すことができますが。 (作成者はDERが全く間にその結果、X.509、変換におけるUTCTのために定義されないのに注意されます。
Kent [Page 8] RFC 1422 Certificate-Based Key Management February 1993
Key Management1993年2月の証明書ベースのケント[8ページ]RFC1422
local and transfer syntax must be performed carefully, e.g., when computing the hash value for a certificate. For example, a UTCT value which includes explict, zero values for seconds would not produce the same hash value as one in which the seconds were omitted.) It also recommended that all times be expressed as Greenwich Mean Time (Zulu), to simplify comparisons and avoid confusion relating to daylight savings time. Note that UTCT expresses the value of a year modulo 100 (with no indication of century), hence comparisons involving dates in different centuries must be performed with care.
例えば、証明書のためにハッシュ値を計算するとき、慎重に地方と転送構文を実行しなければなりません。 例えば、explictを含んでいるUTCT値であり、数秒間の値がないのは秒が省略されたものと同じハッシュ値を生産しないでしょう。) また、それは、すべての回が比較を簡素化して、日光貯蓄時間まで関係する混乱を避けるためにグリニッジ標準時(ズールー族)として言い表されることを勧めました。 慎重に実行されて、そのUTCTがしたがって、法100(世紀のしるしのない)、異なった世紀に日付にかかわる比較がそうであるに違いない1年に値を言い表すことに注意してください。
The longer the interval, the greater the likelihood that compromise of a private component or name change will render it invalid and thus require that the certificate be revoked. Once revoked, the certificate must remain on the issuer's CRL (see Section 3.4.3.4) until the validity interval expires. PCAs may impose restrictions on the maximum validity interval that may be elected by CAs operating in their certification domain (see Appendix B).
間隔が長ければ長いほど、個人的なコンポーネントか改名の感染が、それを無効にして、その結果、証明書が取り消されるのを必要とするという見込みは、よりすばらしいです。 一度取り消されて、証明書は発行人のCRLに残らなければなりません。(正当性間隔までの.4が)吐き出すセクション3.4.3を見てください。 PCAsは彼らの証明ドメインで作動するCAsによって選出されるかもしれない最大の正当性間隔に制限を課すかもしれません(Appendix Bを見てください)。
3.3.7 Subject Public Key
3.3.7 対象の公開鍵
A certificate carries the public component of its associated subject, as well as an indication of the algorithm, and any algorithm parameters, with which the public component is to be used. This algorithm identifier is independent of that which is specified in the signature field described above. RFC 1423 specifies the algorithm identifiers which may be used in this context.
証明書は関連対象の公共の部品を載せます、アルゴリズムのしるし、およびどんなアルゴリズムパラメタと同様に。公共のコンポーネントはパラメタで使用されていることです。 このアルゴリズム識別子は上で説明された署名分野で指定されるそれから独立しています。 RFC1423はこのような関係においては使用されるかもしれないアルゴリズム識別子を指定します。
3.4 Roles and Responsibilities
3.4 役割と責任
One way to explain the architecture proposed by this document is to examine the roles which are defined for various entities in the architecture and to describe what is required of each entity in order for the proposed system to work properly. The following sections identify four types of entities within this architecture: users and user agents, the Internet Policy Registration Authority, Policy Certification Authorities, and other Certification Authorities. For each type of entity, this document specifies the procedures which the entity must execute as part of the architecture and the responsibilities the entity assumes as a function of its role in the architecture.
アーキテクチャがこのドキュメントで提案したと説明する1つの方法は、アーキテクチャの様々な実体のために定義される役割を調べて、提案されたシステムが適切に扱うように各実体が何に要求されるかを説明することです。 以下のセクションはこのアーキテクチャの中で4つのタイプの実体を特定します: ユーザ、ユーザエージェント(インターネットPolicy Registration Authority)Policy Certification Authorities、および他のCertification Authorities。 それぞれのタイプの実体として、このドキュメントは実体がアーキテクチャの一部として実行しなければならない手順と実体がアーキテクチャでの役割の機能として負う責任を指定します。
3.4.1 Users and User Agents
3.4.1 ユーザとユーザエージェント
The term User Agent (UA) is taken from CCITT X.400 Message Handling Systems (MHS) Recommendations, which define it as follows: "In the context of message handling, the functional object, a component of MHS, by means of which a single direct user engages in message
用語Userエージェント(UA)はCCITT X.400 Message Handling Systems(MHS)推薦から連れて行かれます:(推薦は以下の通りそれを定義します)。 「メッセージハンドリングの文脈、機能目標、MHSの部品。」部品によって、独身のダイレクトユーザはメッセージに従事しています。
Kent [Page 9] RFC 1422 Certificate-Based Key Management February 1993
Key Management1993年2月の証明書ベースのケント[9ページ]RFC1422
handling." In the Internet environment, programs such as rand mh and Gnu emacs rmail are UAs. UAs exchange messages by calling on a supporting Message Transfer Service (MTS), e.g., the SMTP mail relays used in the Internet.
「取り扱い。」 インターネット環境で、底ならし革mhやGnu emacs rmailなどのプログラムはUAsです。 UAsは、サポートMessage Transfer Service(MTS)(例えばインターネットで使用されるSMTPメール中継)を訪問することによって、メッセージを交換します。
3.4.1.1 Generating and Protecting Component Pairs
3.4.1.1 コンポーネントペアを生成して、保護すること。
A UA process supporting PEM must protect the private component of its associated entity (e.g., a human user or a mailing list) from disclosure, though the means by which this is effected is a local matter. It is essential that the user take all available precautions to protect his private component as the secrecy of this value is central to the security offered by PEM to that user. For example, the private component might be stored in encrypted form, protected with a locally managed symmetric encryption key (e.g., using DES). The user would supply a password or passphrase which would be employed as a symmetric key to decrypt the private component when required for PEM processing (either on a per message or per session basis). Alternatively, the private component might be stored on a diskette which would be inserted by the user whenever he originated or received PEM messages. Explicit zeroing of memory locations where this component transiently resides could provide further protection. Other precautions, based on local operating system security facilities, also should be employed.
PEMをサポートするUAプロセスは公開から関連実体(例えば、人間のユーザかメーリングリスト)の個人的なコンポーネントを保護しなければなりません、これが作用している手段が地域にかかわる事柄ですが。 ユーザがこの価値の秘密保持がPEMによってそのユーザに提供されたセキュリティに主要であるときに彼の個人的なコンポーネントを保護するためにすべての利用可能な注意を払うのは、不可欠です。 例えば、個人的なコンポーネントは局所的に管理された左右対称の暗号化キー(例えば、DESを使用する)で保護された暗号化されたフォームに保存されるかもしれません。 ユーザはPEM処理(1メッセージあたりのaかセッション基礎あたりの)に必要であると個人的なコンポーネントを解読するのに対称鍵として使われるパスワードかパスフレーズを提供するでしょう。 あるいはまた、個人的なコンポーネントは彼がPEMメッセージを溯源したか、または受け取ったときはいつも、ユーザによって挿入されるディスケットの上に保存されるかもしれません。 このコンポーネントがはかなくある記憶域の明白なゼロはさらなる保護を提供するかもしれません。 また、地方のオペレーティングシステムセキュリティ施設に基づいて、他の注意は使われるべきです。
It is recommended that each user employ ancillary software (not otherwise associated with normal UA operation) or hardware to generate his personal public-key component pair. Software for generating user component pairs will be available as part of the reference implementation of PEM distributed freely in the U.S. portion of the Internet. It is critically important that the component pair generation procedure be effected in as secure a fashion as possible, to ensure that the resulting private component is unpredictable. Introduction of adequate randomness into the component pair generation procedure is potentially the most difficult aspect of this process and the user is advised to pay particular attention to this aspect. (Component pairs employed in public-key cryptosystems tend to be large integers which must be "randomly" selected subject to mathematical constraints imposed by the cryptosystem. Input(s) used to seed the component pair generation process must be as unpredictable as possible. An example of a poor random number selection technique is one in which a pseudo-random number generator is seeded solely with the current date and time. An attacker who could determine approximately when a component pair was generated could easily regenerate candidate component pairs and compare the public component to the user's public component to detect when the corresponding private component had been found.)
各ユーザが彼の個人的な公開鍵コンポーネント組を生成するのに付属のソフトウェア(そうでなければ、通常のUA操作には、交際しない)かハードウェアを使うのは、お勧めです。 ユーザコンポーネント組を生成するためのソフトウェアはインターネットの米国の部分で自由に分配されたPEMの参照実装の一部として利用可能になるでしょう。 できるだけ安全なファッションでコンポーネント組世代手順が結果として起こる個人的なコンポーネントが予測できないのを保証するために作用するのは、批判的に重要です。 コンポーネント組世代手順への適切な偶発性の導入はこのプロセスの潜在的に最も難しい局面です、そして、ユーザがこの局面に関する特別の注意を向けるようにアドバイスされます。 (公開鍵暗号系で雇われたコンポーネント組は、数学を条件とした暗号系によって課された「手当たりしだいに」選択された規制であるに違いない大きい整数である傾向があります。 コンポーネント組発生経過に種を蒔くのに使用される入力はできるだけ予測できるはずがありません。 貧しい乱数選択のテクニックに関する例は疑似乱数生成器が唯一現在の日時で種を蒔かれるものです。 コンポーネント組がいつ頃に生成されたかを決心できた攻撃者は、対応する個人的なコンポーネントがいつ見つけられたかを検出するために容易に候補コンポーネント組を作り直して、ユーザの公共のコンポーネントに公共のコンポーネントをたとえることができました。)
Kent [Page 10] RFC 1422 Certificate-Based Key Management February 1993
Key Management1993年2月の証明書ベースのケント[10ページ]RFC1422
There is no requirement imposed by this architecture that anyone other than the user, including any certification authority, have access to the user's private component. Thus a user may retain his component pair even if his certificate changes, e.g., due to rollover in the validity interval or because of a change of certifying authority. Even if a user is issued a certificate in the context of his employment, there is generally no requirement that the employer have access to the user's private component. The rationale is that any messages signed by the user are verifiable using his public component. In the event that the corresponding private component becomes unavailable, any ENCRYPTED messages directed to the user would be indecipherable and would require retransmission.
どんな証明権威も含むユーザ以外のだれでもユーザの個人的なコンポーネントに近づく手段を持っているというこのアーキテクチャによって課された要件が全くありません。 したがって、彼の証明書が変化しても、ユーザは彼のコンポーネント組を保有するかもしれません、例えば、正当性間隔か公認権威の変化によるロールオーバーのため。 彼の雇用の文脈の証明書をユーザに発行しても、一般に、雇い主がユーザの個人的なコンポーネントに近づく手段を持っているという要件が全くありません。 原理はユーザによって署名されたどんなメッセージも彼の公共のコンポーネントを使用することで証明可能であるということです。 対応する個人的なコンポーネントが入手できなくなる場合、ユーザに向けられたどんなENCRYPTEDメッセージも、判読不可能であるだろう、「再-トランスミッション」を必要とするでしょう。
Note that if the user stores messages in ENCRYPTED form, these messages also would become indecipherable in the event that the private component is lost or changed. To minimize the potential for loss of data in such circumstances messages can be transformed into MIC-ONLY or MIC-CLEAR form if cryptographically-enforced confidentiality is not required for the messages stored within the user's computer. Alternatively, these transformed messages might be forwarded in ENCRYPTED form to a (trivial) distribution list which serves in a backup capacity and for which the user's employer holds the private component.
ユーザがENCRYPTEDフォームにメッセージを格納するなら、個人的なコンポーネントをなくすか、または変える場合これらのメッセージも判読不可能になることに注意してください。 そのような事情メッセージでデータの喪失の可能性を最小にするのをミックだけに変えることができますか、または暗号で実施された秘密性はユーザのコンピュータの中に格納されたメッセージに必要でないなら、ミック-CLEARが形成します。 あるいはまた、ENCRYPTEDフォームでバックアップ容量で勤めて、ユーザの雇い主が個人的なコンポーネントを支える(些細)の発送先リストにこれらの変成しているメッセージを転送するかもしれません。
A user may possess multiple certificates which may embody the same or different public components. For example, these certificates might represent a current and a former organizational user identity and a residential user identity. It is recommended that a PEM UA be capable of supporting a user who possess multiple certificates, irrespective of whether the certificates associated with the user contain the same or different DNs or public components.
ユーザには、同じであるか異なった公共のコンポーネントを具体化するかもしれない複数の証明書があるかもしれません。 例えば、これらの証明書は現在のユーザアイデンティティ、前の組織的なユーザアイデンティティ、および住宅のユーザアイデンティティを表すかもしれません。 PEM UAが複数の証明書を持っているユーザを支持できるのは、お勧めです、ユーザに関連している証明書が同じであるか異なったDNsか公共のコンポーネントを含んでいるかどうかの如何にかかわらず。
3.4.1.2 User Registration
3.4.1.2 ユーザ登録
Most details of user registration are a local matter, subject to policies established by the user's CA and the PCA under which that CA has been certified. In general a user must provide, at a minimum, his public component and distinguished name to a CA, or a representative thereof, for inclusion in the user's certificate. (The user also might provide a complete certificate, minus the signature, as described in RFC 1424.) The CA will employ some means, specified by the CA in accordance with the policy of its PCA, to validate the user's claimed identity and to ensure that the public component provided is associated with the user whose distinguished name is to be bound into the certificate. (In the case of PERSONA certificates, described below, the procedure is a bit different.) The certifying authority generates a certificate containing the user's distinguished name and public component, the authority's
ユーザ登録のほとんどの詳細がそのカリフォルニアが公認されたユーザのカリフォルニアとPCAによって確立された方針を条件とした地域にかかわる事柄です。 一般に、ユーザは提供しなければなりません、カリフォルニア、またはそれの代表への彼の最小の分類名、公共のコンポーネント、および分類名で、ユーザの証明書での包含のために。 (ユーザもRFC1424で説明されるように署名を引いて完全な証明書を提供するかもしれません。) カリフォルニアはユーザの要求されたアイデンティティを有効にするのにPCAの方針によると、カリフォルニアによって指定されたいくつかの手段を使うでしょう、そして、公共のコンポーネントが提供されたのを保証するのは証明書に縛られる分類名がことであるユーザに関連しています。 (以下で説明されたPERSONA証明書の場合では、手順は少し異なっています。) 公認権威はユーザの分類名と公共のコンポーネントを含む証明書、権威のものを発生させます。
Kent [Page 11] RFC 1422 Certificate-Based Key Management February 1993
Key Management1993年2月の証明書ベースのケント[11ページ]RFC1422
distinguished name and other information (see Section 3.3) and signs the result using the private component of the authority.
分類名、他の情報(セクション3.3を見る)とサインは権威の個人的な成分を使用する結果をそうします。
3.4.1.3 CRL Management
3.4.1.3 CRL管理
Mechanisms for managing a UA certificate cache are, in typical standards parlance, a local matter. However, proper maintenance of such a cache is critical to the correct, secure operation of a PEM UA and provides a basis for improved performance. Moreover, use of a cache permits a PEM UA to operate in the absence of directories (and in circumstances where directories are inaccessible). The following discussion provides a paradigm for one aspect of cache management, namely the processing of CRLs, the functional equivalent of which must be embodied in any PEM UA implementation compliant with this document. The specifications for CRLs used with PEM are provided in Section 3.5.
典型的な規格話法で、UA証明書キャッシュを管理するためのメカニズムは地域にかかわる事柄です。 しかしながら、そのようなキャッシュの適切な維持は、PEM UAの正しくて、安全な操作に重要であり、向上した性能の基礎を提供します。 そのうえ、キャッシュの使用は、PEM UAがディレクトリ(そしてディレクトリがアクセスできない事情で)がないとき作動することを許可します。 以下の議論はすなわち、キャッシュ管理の1つの局面、CRLsの処理にパラダイムを提供します。このドキュメントによる対応することのどんなPEM UA実現にもその機能的な同等物を表現しなければなりません。 PEMと共に使用されるCRLsのための仕様をセクション3.5に提供します。
X.500 makes provision for the storage of CRLs as directory attributes associated with CA entries. Thus, when X.500 directories become widely available, UAs can retrieve CRLs from directories as required. In the interim, the IPRA will coordinate with PCAs to provide a robust database facility which will contain CRLs issued by the IPRA, by PCAs, and by all CAs. Access to this database will be provided through mailboxes maintained by each PCA. Every PEM UA must provide a facility for requesting CRLs from this database using the mechanisms defined in RFC 1424. Thus the UA must include a configuration parameter which specifies one or more mailbox addresses from which CRLs may be retrieved. Access to the CRL database may be automated, e.g., as part of the certificate validation process (see Section 3.6) or may be user directed. Responses to CRL requests will employ the PEM header format specified in RFC 1421 for CRL propagation. As noted in RFC 1421, every PEM UA must be capable of processing CRLs distributed via such messages. This message format also may be employed to support a "push" (versus a "pull") model of CRL distribution, i.e., to support unsolicited distribution of CRLs.
X.500はカリフォルニアのエントリーに関連しているディレクトリ属性としてCRLsの格納に備えます。 したがって、X.500ディレクトリが広く利用可能になると、UAsは必要に応じてディレクトリからCRLsを検索できます。 その間、IPRAは、IPRA、PCAs、およびすべてのCAsによって発行されたCRLsを含む強健なデータベース機能を提供するためにPCAsと共に調整するでしょう。 各PCAによって維持されたメールボックスを通してこのデータベースへのアクセスを提供するでしょう。 あらゆるPEM UAがこのデータベースからRFC1424で定義されたメカニズムを使用することでCRLsを要求するのに施設を提供しなければなりません。 したがって、UAはCRLsが検索されるかもしれない1つ以上のメールボックスアドレスを指定する設定パラメータを含まなければなりません。 CRLデータベースへのアクセスは、例えば、証明書合法化の過程(セクション3.6を見る)の一部として自動化されているかもしれないか、指示されたユーザであるかもしれません。 CRL要求への応答はRFC1421でCRL伝播に指定されたPEMヘッダー形式を使うでしょう。 RFC1421に述べられるように、あらゆるPEM UAはそのようなメッセージで分配された処理CRLsができなければなりません。 このメッセージ・フォーマットも、すなわち、CRLsの求められていない分配を支持するためにCRL分配の「プッシュ」(「牽引力」に対する)モデルをサポートするのに使われるかもしれません。
CRLs received by a PEM UA must be validated (A CRL is validated in much the same manner as a certificate, i.e., the CIC (see RFC 1113) is calculated and compared against the decrypted signature value obtained from the CRL. See Section 3.6 for additional details related to validation of certificates.) prior to being processed against any cached certificate information. Any cache entries which match CRL entries should be marked as revoked, but it is not necessary to delete cache entries marked as revoked nor to delete subordinate entries. In processing a CRL against the cache it is important to recall that certificate serial numbers are unique only for each issuer and that multiple, distinct CRLs may be issued under the same CA DN (signed using different private components), so care
PEM UAによって受け取られたCRLsを有効にしなければなりません。(CRLが証明書への似たり寄ったりの方法で有効にされて、すなわち、CIC(RFC1113を見る)は、CRLから得られた解読された署名値に対して計算されて、比較されます。 証明書の合法化に関連する追加詳細に関してセクション3.6を見てください。) どんなキャッシュされた証明書情報に対して処理される前に。 CRLエントリーに合っているどんなキャッシュエントリーも取り消されるように示されるべきですが、取り消されるように示されるキャッシュエントリーを削除して、下位のエントリーを削除するのは必要ではありません。 キャッシュに対してCRLを処理する際に、各発行人だけに、証明書通し番号がユニークであり、複数の、そして、異なったCRLsが同じCA DN(異なった個人的なコンポーネントを使用することで、サインされる)の下で発行されたかもしれないと思い出すのが重要であるので、気にかけてください。
Kent [Page 12] RFC 1422 Certificate-Based Key Management February 1993
Key Management1993年2月の証明書ベースのケント[12ページ]RFC1422
must be exercised in effecting this cache search. (This situation may arise either because an organizational CA is certified by multiple PCAs, or because multiple residential CAs are certified under different PCAs.)
このキャッシュ検索に作用するのに訓練しなければなりません。 (組織的なカリフォルニアが複数のPCAsによって公認されるか、または複数の住宅のCAsが異なったPCAsの下で公認されるので、この状況は起こるかもしれません。)
This procedure applies to cache entries associated with PCAs and CAs, as well as user entries. The UA also must retain each CRL to screen incoming messages to detect use of revoked certificates carried in PEM message headers. Thus a UA must be capable of processing and retaining CRLs issued by the IPRA (which will list revoked PCA certificates), by any PCA (which will list revoked CA certificate issued by that PCA), and by any CA (which will list revoked user or subordinate CA certificates issued by that CA).
この手順はPCAsとCAsに関連しているキャッシュエントリー、およびユーザエントリーに適用されます。 UAも、PEMメッセージヘッダーで運ばれた取り消された証明書の使用を検出する入力メッセージを上映するために各CRLを保有しなければなりません。 したがって、CRLsがIPRA(どれが記載するかがPCA証明書を取り消した)の近くと、そして、どんなPCA(どれが記載するかがそのPCAによって発行されたカリフォルニア証明書を取り消した)の近くとも、そして、どんなカリフォルニアでも発行した処理であってUAは保有できなければなりません(どれが記載するかがユーザかそのカリフォルニアによって発行された下位のカリフォルニア証明書を取り消しました)。
3.4.1.4 Facilitating Interoperation
3.4.1.4 Interoperationを容易にすること。
In the absence of ubiquitous directory services or knowledge (acquired through out-of-band means) that a recipient already possesses the necessary issuer certificates, it is recommended that an originating (PEM) UA include sufficient certificates to permit validation of the user's public key. To this end every PEM UA must be capable of including a full (originator) certification path, i.e., including the user's certificate (using the "Originator-Certificate" field) and every superior (CA/PCA) certificate (using "Issuer- Certificate" fields) back to the IPRA, in a PEM message. A PEM UA may send less than a full certification path, e.g., based on analysis of a recipient list, but a UA which provides this sort of optimization must also provide the user with a capability to force transmission of a full certification path.
受取人には必要な発行人証明書が既にあるという遍在している電話番号案内か知識(バンドの外を通した手段を取得する)がないとき、由来している(PEM)UAがユーザの公開鍵の合法化を可能にすることができるくらいの証明書を含んでいるのは、お勧めです。 すなわち、ユーザの証明書(「創始者証明書」分野を使用する)とあらゆる優れた(カリフォルニア/PCA)証明書を含んでいて(「発行人証明書」分野を使用して)、このためにあらゆるPEM UAが完全な(創始者)証明経路をIPRAに含めて戻すことができなければなりません、PEMメッセージで。 PEM UAは例えば、受取人リストの分析に基づいて完全な証明経路ほど発信しないかもしれませんが、また、この種類の最適化を提供するUAは完全な証明経路の送信を強制する能力をユーザに提供しなければなりません。
Optimization for the transmitted originator certification path may be effected by a UA as a side effect of the processing performed during message submission. When an originator submits an ENCRYPTED message (as per RFC 1421, his UA must validate the certificates of the recipients (see Section 3.6). In the course of performing this validation the UA can determine the minimum set of certificates which must be included to ensure that all recipients can process the received message. Submission of a MIC-ONLY or MIC-CLEAR message (as per RFC 1421) does not entail validation of recipient certificates and thus it may not be possible for the originator's UA to determine the minimum certificate set as above.
処理の副作用がメッセージ提案の間働いたとき、伝えられた創始者証明道のための最適化はUAによって作用されるかもしれません。 創始者がENCRYPTEDを提出したら通信してください。RFC1421に従って、彼のUAは受取人の証明書を有効にしなければなりません(セクション3.6を見てください)。(この合法化を実行することの間に、UAは、含まなければならない最小のセットの証明書が、すべての受取人が受信されたメッセージを処理できるのを保証することを決定できます; ミックだけかミック-CLEARメッセージ(RFC1421に従って)の服従は受取人証明書の合法化を伴いません、そして、その結果、創始者のUAが、最小の証明書が同じくらい上にセットしたことを決定するのは、可能でないかもしれません。
3.4.2 The Internet Policy Registration Authority (IPRA)
3.4.2 インターネット方針登録局(IPRA)
The IPRA acts as the root of the certification hierarchy for the Internet community. The public component of the IPRA forms the foundation for all certificate validation within this hierarchy. The IPRA will be operated under the auspices of the Internet Society, an
IPRAはインターネットコミュニティのために証明階層構造の根として機能します。 IPRAの公共の部品はこの階層構造の中ですべての証明書合法化の基礎を形成します。 IPRAはインターネット協会の前兆で操作されるでしょう。
Kent [Page 13] RFC 1422 Certificate-Based Key Management February 1993
Key Management1993年2月の証明書ベースのケント[13ページ]RFC1422
international, non-profit organization. The IPRA certifies all PCAs, ensuring that they agree to abide by the Internet-wide policy established by the IPRA. This policy, and the services provided by the IPRA, are detailed below.
国際的である、民間非営利組織。 彼らが、IPRAによって確立されたインターネット全体の方針を守るのに同意するのを確実にして、IPRAはすべてのPCAsを公認します。 この方針、およびIPRAによって提供されたサービスは以下で詳細です。
3.4.2.1 PCA Registration
3.4.2.1 PCA登録
The IPRA certifies only PCAs, not CAs or users. Each PCA must file with the IPRA a description of its proposed policy. This document will be published as an informational RFC. A copy of the document, signed by the IPRA (in the form of a PEM MIC-ONLY message) will be made available via electronic mail access by the IPRA. This convention is adopted so that every Internet user has a reference point for determining the policies associated with the issuance of any certificate which he may encounter. The existence of a digitally signed copy of the document ensures the immutability of the document. Authorization of a PCA to operate in the Internet hierarchy is signified by the publication of the policy document, and the issuance of a certificate to the PCA, signed by the IPRA. An outline for PCA policy statements is contained in Section 3.4.3 of this document.
IPRAはCAsかユーザではなく、PCAsだけを公認します。 各PCAはIPRAと共に提案された方針の記述をファイルしなければなりません。 このドキュメントは情報のRFCとして発表されるでしょう。 ドキュメントのコピー、IPRA(PEM MICだけメッセージの形の)によってサインされて、IPRAによる電子メールアクセスで利用可能に作られるでしょう。 このコンベンションが採用されるので、すべてのインターネットユーザには、彼が遭遇するどんな証明書の発行にも関連している方針を決定するための基準点があります。 ドキュメントのデジタルにサインされたコピーの存在はドキュメントの不変性を確実にします。 インターネット階層構造で操作するPCAの認可は方針ドキュメントの公表、および証明書の発行によってIPRAによってサインされたPCAに意味されています。 PCA施政方針のためのアウトラインはこの.3通のセクション3.4ドキュメントに含まれています。
As part of registration, each PCA will be required to execute a legal agreement with the IPRA, and to pay a fee to defray the costs of operating the IPRA. Each a PCA must specify its distinguished name. The IPRA will take reasonable precautions to ensure that the distinguished name claimed by a PCA is legitimate, e.g., requiring the PCA to provide documentation supporting its claim to a DN. However, the certification of a PCA by the IPRA does not constitute a endorsement of the PCA's claim to this DN outside of the context of this certification system.
登録の一部として、各PCAが、IPRAとの法的な協定を執行して、IPRAを操作するコストを負担するために謝礼するのに必要でしょう。 それぞれ、PCAは分類名を指定しなければなりません。 IPRAはPCAによって要求された分類名が確実に正統になるようにするために合理的な注意を払うでしょう、例えば、PCAがドキュメンテーションを提供するのが必要であるのがDNにクレームを支持して。 しかしながら、IPRAによるPCAの証明はこの認証システムの文脈の外でPCAのクレームの裏書きをこのDNに構成しません。
3.4.2.2 Ensuring the Uniqueness of Distinguished Names
3.4.2.2 分類名のユニークさを確実にすること。
A fundamental requirement of this certification scheme is that certificates are not issued to distinct entities under the same distinguished name. This requirement is important to the success of distributed management for the certification hierarchy. The IPRA will not certify two PCAs with the same distinguished name and no PCA may certify two CAs with the same DN. However, since PCAs are expected to certify organizational CAs in widely disjoint portions of the directory namespace, and since X.500 directories are not ubiquitous, a facility is required for coordination among PCAs to ensure the uniqueness of CA DNs. (This architecture allows multiple PCAs to certify residential CAs and thus multiple, distinct residential CAs with identical DNs may come into existence, at least until such time as civil authorities assume responsibilities for such certification. Thus, on an interim basis, the architecture explicitly accommodates the potential for duplicate residential CA
この証明計画の基本的な要件は証明書が同じ分類名の下で別個の物に発行されないということです。 証明階層構造に、この要件は分散管理の成功に重要です。 IPRAは同じ分類名で2PCAsを公認しないでしょう、そして、どんなPCAも同じDNと共に2CAsを公認してはいけません。 しかしながら、PCAsが組織的なCAsを公認すると予想されて、ディレクトリ名前空間の部分が中で広くばらばらになって、X.500ディレクトリが遍在していないので、PCAsの中のコーディネートがカリフォルニアDNsのユニークさを確実にするのに施設が必要です。 複数のPCAsがこの構造で住宅のCAsを公認できます、そして、その結果、同じDNsと複数の、そして、異なった住宅のCAsは生まれるかもしれません、少なくとも民間当局が、そのような証明への責任であると仮定するような時間まで。(その結果、当座ベースでは、構造は明らかに写しの住宅のカリフォルニアの可能性を収容します。
Kent [Page 14] RFC 1422 Certificate-Based Key Management February 1993
Key Management1993年2月の証明書ベースのケント[14ページ]RFC1422
DNs.)
DNs。)
In support of the uniqueness requirement, the IPRA will establish and maintain a database to detect potential, unintended duplicate certification of CA distinguished names. This database will be made accessible to all PCAs via an email interface. Each entry in this database will consist of a 4-tuple. The first element in each entry is a hash value, computed on a canonical, ASN.1 encoded representation of a CA distinguished name. The second element contains the subjectPublicKey that appears in the CA's certificate. The third element is the distinguished name of the PCA which registered the entry. The fourth element consists of the date and time at which the entry was made, as established by the IPRA. This database structure provides a degree of privacy for CAs registered by PCAs, while providing a facility for ensuring global uniqueness of CA DNs certified in this scheme.
ユニークさの要件を支持して、IPRAは検出するデータベースを潜在的に確立して、維持するでしょう、カリフォルニア分類名の故意でない写し証明。 このデータベースをメールインタフェースを通してすべてのPCAsにアクセスしやすくするでしょう。 このデータベースにおける各エントリーは4-tupleから成るでしょう。 各エントリーにおける最初の要素はカリフォルニア分類名の正準なASN.1のコード化された表現のときに計算されたハッシュ値です。 2番目の要素はCAの証明書に現れるsubjectPublicKeyを含んでいます。 3番目の要素はエントリーを登録したPCAの分類名です。 4番目の要素はエントリーがIPRAによって設立されるようにされた日時から成ります。 このデータベース構造はこの計画で公認されたカリフォルニアDNsのグローバルなユニークさを確実にするのに施設を提供している間にPCAsによって登録されたCAsに1段階のプライバシーを供給します。
In order to avoid conflicts, a PCA should query the database using a CA DN hash value as a search key, prior to certifying a CA. The database will return any entries which match the query, i.e., which have the same CA DN. The PCA can use the information contained in any returned entries to determine if any PCAs should be contacted to resolve possible DN conflicts. If no potential conflicts appear, a PCA can then submit a candidate entry, consisting of the first three element values, plus any entries returned by the query. The database will register this entry, supplying the time and date stamp, only if two conditions are met: (1) the first two elements (the CA DN hash and the CA subjectPublicKey) of the candidate entry together must be unique and, (2) any other entries included in the submission must match what the current database would return if the query corresponding to the candidate entry were submitted.
摩擦を避けるために、PCAはカリフォルニアを公認する前に主要な検索としてCA DNハッシュ値を使用することでデータベースについて質問するはずです。 データベースはすなわち質問に合っているどんなエントリーも返すでしょう(同じCA DNを持っています)。 PCAは何かPCAsが可能なDN闘争を解決するために連絡されるべきであるかどうか決定するためにどんな返されたエントリーにも保管されていた情報を使用できます。 どんな潜在的闘争も現れないなら、PCAは候補エントリーを提出できます、最初の3つの要素値、および質問で返されたどんなエントリーからも成って。 2つの条件が満たされる場合にだけタイムスタンプを供給して、データベースはこのエントリーを登録するでしょう: (1) (2) 一緒に候補エントリーの最初の2つの要素(CA DN細切れ肉料理とカリフォルニアsubjectPublicKey)がユニークであるに違いありません、そして、候補エントリーに対応する質問を提出したなら、服従に含まれていたいかなる他のエントリーも現在のデータベースが返すものに合わなければなりません。
If the database detects a conflicting entry (failure of case 1 above), or if the submission indicates that the PCA's perception of possible conflicting entries is not current (failure of case 2), the submission is rejected and the database will return the potential conflicting entry (entries). If the submission is successful, the database will return the timestamped new entry. The database does not, in itself, guarantee uniqueness of CA DNs as it allows for two DNs associated with different public components to be registered. Rather, it is the responsibility of PCAs to coordinate with one another whenever the database indicates a potential DN conflict and to resolve such conflicts prior to certification of CAs. Details of the protocol used to access the database will be provided in another document.
データベースが闘争エントリー(ケース1上の失敗)を検出するか、または服従が、PCAの可能な闘争エントリーの認知がよく見られないのを(ケース2の失敗)示すなら、服従は拒絶されます、そして、データベースはエントリー(エントリー)を潜在的闘争に返すでしょう。 服従がうまくいくと、データベースはtimestamped新しいエントリーを返すでしょう。 異なった公共のコンポーネントに関連している2DNsが登録されるのを許容するようにデータベースは本来カリフォルニアDNsのユニークさを保証しません。 むしろ、データベースが潜在的DN闘争を示すときはいつも、お互いと共に調整して、CAsの証明の前にそのような闘争を解決するのは、PCAsの責任です。 データベースにアクセスするのに使用されるプロトコルの詳細は別のドキュメントに明らかにされるでしょう。
As noted earlier, a CA may be certified under more than one PCA, e.g., because the CA wants to issue certificates under two different
より早く注意されるように、カリフォルニアは1PCAの下で公認されるかもしれません、例えば、カリフォルニアが2の下において異なった証明書を発行したがっているので
Kent [Page 15] RFC 1422 Certificate-Based Key Management February 1993
Key Management1993年2月の証明書ベースのケント[15ページ]RFC1422
policies. If a CA is certified by multiple different PCAs, the CA must employ a different public key pair for each PCA. In such circumstances the certificate issued to the CA by each PCA will contain a different subjectPublicKey and thus will represent a different entry in this database. The same situation may arise if multiple, equivalent residential CAs are certified by different PCAs.
方針。 カリフォルニアが複数の異なったPCAsによって公認されるなら、カリフォルニアは各PCAのために異なった公開鍵組を雇わなければなりません。 そのような事情では、各PCAによってカリフォルニアに発行された証明書は、異なったsubjectPublicKeyを含んで、その結果、このデータベースにおける異なったエントリーを表すでしょう。 複数の、そして、同等な住宅のCAsが異なったPCAsによって公認されるなら、同じ状況は起こるかもしれません。
To complete the strategy for ensuring uniqueness of DNs, there is a DN subordination requirement levied on CAs. In general, CAs are expected to sign certificates only if the subject DN in the certificate is subordinate to the issuer (CA) DN. This ensures that certificates issued by a CA are syntactically constrained to refer to subordinate entities in the X.500 directory information tree (DIT), and this further limits the possibility of duplicate DN registration. CAs may sign certificates which do not comply with this requirement if the certificates are "cross-certificates" or "reverse certificates" (see X.509) used with applications other than PEM.
DNsのユニークさを確実にするための戦略を完成するために、CAsに徴収されたDN従属要件があります。 一般に、証明書の対象のDNが発行人(カリフォルニア)DNに下位である場合にだけ、CAsが証明書にサインすると予想されます。 これは、カリフォルニアによって発行された証明書がX.500ディレクトリ情報木(DIT)の下位の実体について言及するのがシンタクス上抑制されるのを確実にします、そして、さらに、写しDN登録の可能性を制限します。 CAsは証明書が「交差している証明書」かPEM以外のアプリケーションと共に使用される「逆の証明書」(X.509を見る)であるならこの要件を応じない証明書と契約するかもしれません。
The IPRA also will establish and maintain a separate database to detect potential duplicate certification of (residential) user distinguished names. Each entry in this database will consist of 4- tuple as above, but the first components is the hash of a residential user DN and the third component is the DN of the residential CA DN which registered the user. This structure provides a degree of privacy for users registered by CAs which service residential users while providing a facility for ensuring global uniqueness of user DNs certified under this scheme. The same database access facilities are provided as described above for the CA database. Here it is the responsibility of the CAs to coordinate whenever the database indicates a potential conflict and to resolve the conflict prior to (residential) user certification.
IPRAも、(住宅)のユーザ分類名の潜在的写し証明を検出するために別々のデータベースを確立して、維持するでしょう。 最初のコンポーネントは住宅のユーザDNの細切れ肉料理です、そして、このデータベースにおける各エントリーは上の4tupleから成るでしょうが、3番目のコンポーネントはユーザを登録した住宅のCA DNのDNです。 この構造はこの計画の下で公認されたユーザDNsのグローバルなユニークさを確実にするのに施設を提供している間に住宅のユーザにサービスを提供するCAsによって登録されたユーザに1段階のプライバシーを提供します。 カリフォルニアデータベースのために上で説明されるように同じデータベースアクセス施設を提供します。 ここで、データベースが潜在的闘争を示すときはいつも、調整して、(住宅)のユーザ証明の前に対立を解決するのは、CAsの責任です。
3.4.2.3 Accuracy of Distinguished Names
3.4.2.3 分類名の精度
As noted above, the IPRA will make a reasonable effort to ensure that PCA DNs are accurate. The procedures employed to ensure the accuracy of a CA distinguished name, i.e., the confidence attached to the DN/public component binding implied by a certificate, will vary according to PCA policy. However, it is expected that every PCA will make a good faith effort to ensure the legitimacy of each CA DN certified by the PCA. Part of this effort should include a check that the purported CA DN is consistent with any applicable national standards for DN assignment, e.g., NADF recommendations within North America [5,9].
上で述べたように、IPRAはPCA DNsが確実に正確になるようにするための妥当な努力をするでしょう。 PCA方針によると、カリフォルニア分類名の精度を確実にするのに使われた手順(すなわち、証明書によって含意されたDN/公共のコンポーネント結合に付けられた信用)は異なるでしょう。 しかしながら、あらゆるPCAがPCAによって公認されたそれぞれのCA DNの合法性を確実にするための誠実の努力をすると予想されます。 この努力の一部がDN課題においてどんな適切な国家規格とも一致していた状態で主張されたCA DNがあるチェックを含むべきです、例えば、北アメリカ[5、9]の中のNADF推薦。
Kent [Page 16] RFC 1422 Certificate-Based Key Management February 1993
Key Management1993年2月の証明書ベースのケント[16ページ]RFC1422
3.4.2.4 Distinguished Name Conventions
3.4.2.4 分類名コンベンション
A few basic DN conventions are included in the IPRA policy. The IPRA will certify PCAs, but not CAs nor users. PCAs will certify CAs, but not users. These conventions are required to allow simple certificate validation within PEM, as described later. Certificates issued by CAs (for use with PEM) will be for users or for other CAs, either of which must have DNs subordinate to that of the issuing CA.
いくつかの基本的なDNコンベンションがIPRA方針に含まれています。 IPRAはPCAs、しかし、どんなCAsもユーザも公認しないでしょう。 PCAsはユーザではなく、CAsを公認するでしょう。 これらのコンベンションは後で説明されるようにPEMの中で簡単な証明書合法化を許さなければなりません。 CAs(PEMとの使用のための)によって発行された証明書はユーザか他のCAsのためになるでしょう。もの、そのどちらかがDNsを発行カリフォルニアのものに下位にしなければなりません。
The attributes employed in constructing DNs will be specified in a list maintained by the IANA, to provide a coordinated basis for attribute identification for all applications employing DNs. This list will initially be populated with attributes taken from X.520. This document does not impose detailed restrictions on the attributes used to identify different entities to which certificates are issued, but PCAs may impose such restrictions as part of their policies. PCAs, CAs and users are urged to employ only those DN attributes which have printable representations, to facilitate display and entry.
DNsを組み立てる際に使われた属性はDNsを使うすべてのアプリケーションのための属性識別の連携基礎を提供するためにIANAによって維持されたリストで指定されるでしょう。 このリストは初めは、X.520から属性を取っていて居住されるでしょう。 このドキュメントは証明書が発行される異なった実体を特定するのに使用される属性に詳細な制限を課しませんが、PCAsはそれらの方針の一部のような制限を課すかもしれません。 PCAs、CAs、およびユーザが表示とエントリーを容易にするために印刷可能な表現を持っているそれらのDN属性だけを使うよう促されます。
3.4.2.5 CRL Management
3.4.2.5 CRL管理
Among the procedures articulated by each PCA in its policy statement are procedures for the maintenance and distribution of CRLs by the PCA itself and by its subordinate CAs. The frequency of issue of CRLs may vary according to PCA-specific policy, but every PCA and CA must issue a CRL upon inception to provide a basis for uniform certificate validation procedures throughout the Internet hierarchy. The IPRA will maintain a CRL for all the PCAs it certifies and this CRL will be updated monthly. Each PCA will maintain a CRL for all of the CAs which it certifies and these CRLs will be updated in accordance with each PCA's policy. The format for these CRLs is that specified in Section 3.5.2 of the document.
それぞれによって明確に話された手順の中では、施政方針におけるPCAはPCA自身とその下位のCAsによるCRLsのメンテナンスと分配のために手順です。 PCA-特定保険証券によると、CRLsの問題の頻度は異なるかもしれませんが、あらゆるPCAとカリフォルニアが、インターネット階層構造中で一定の証明書合法化手順の基礎を提供するために始まりでCRLを発行しなければなりません。 IPRAはそれが公認するすべてのPCAsのためにCRLを維持するでしょう、そして、毎月このCRLをアップデートするでしょう。 各PCAはそれが公認するCAsのすべてのためにCRLを維持するでしょう、そして、各PCAの方針によると、これらのCRLsをアップデートするでしょう。 これらのCRLsのための形式は.2通のセクション3.5ドキュメントでそんなに指定されています。
In the absence of ubiquitous X.500 directory services, the IPRA will require each PCA to provide, for its users, robust database access to CRLs for the Internet hierarchy, i.e., the IPRA CRL, PCA CRLs, and CRLs from all CAs. The means by which this database is implemented is to be coordinated between the IPRA and PCAs. This database will be accessible via email as specified in RFC 1424, both for retrieval of (current) CRLs by any user, and for submission of new CRLs by CAs, PCAs and the IPRA. Individual PCAs also may elect to maintain CRL archives for their CAs, but this is not required by this policy.
遍在しているX.500電話番号案内がないとき、IPRAは、各PCAが提供するのを必要とするでしょう、すなわち、すべてのCAsからのユーザ、インターネット階層構造のためのCRLsへの体力を要しているデータベースアクセス、IPRA CRL、PCA CRLs、およびCRLsのために。 このデータベースが実行される手段はIPRAとPCAsの間で調整されることです。 このデータベースはどんなユーザによる(現在)のCRLsの検索、およびCAs、PCAs、およびIPRAによる新しいCRLsの服従のためにRFC1424での指定されるとしてのメールでもアクセス可能になるでしょう。 個々のPCAsも、それらのCAsのためのCRLアーカイブを維持するのを選ぶかもしれませんが、これはこの方針によって必要とされません。
3.4.2.6 Public Key Algorithm Licensing Issues
3.4.2.6 公開鍵アルゴリズムライセンシング問題
This certification hierarchy is architecturally independent of any specific digital signature (public key) algorithm. Some algorithms,
建築上、この証明階層構造はどんな特定のデジタル署名(公開鍵)アルゴリズムからも独立しています。 いくつかのアルゴリズム
Kent [Page 17] RFC 1422 Certificate-Based Key Management February 1993
Key Management1993年2月の証明書ベースのケント[17ページ]RFC1422
employed for signing certificates and validating certificate signatures, are patented in some countries. The IPRA will not grant a license to any PCA for the use of any signature algorithm in conjunction with the management of this certification hierarchy. The IPRA will acquire, for itself, any licenses needed for it to sign certificates and CRLs for PCAs, for all algorithms which the IPRA supports. Every PCA will be required to represent to the IPRA that the PCA has obtained any licenses required to issue (sign) certificates and CRLs in the environment(s) which the PCA will serve.
署名証明書と証明書を有効にするのに署名を使って、いくつかの国で特許をとられます。 IPRAはどんな署名アルゴリズムの使用のためにもこの証明階層構造の管理に関連してどんなPCAにも鑑札を下付しないでしょう。 IPRAはそれ自体のためにPCAsのために証明書とCRLsにサインするのに必要であるどんなライセンスも習得するでしょう、IPRAが支持するすべてのアルゴリズムのために。 あらゆるPCAによる必要であることで、それをIPRAに表すために、PCAがPCAが役立つ環境で証明書とCRLsを発行すること(サインする)に必要である免許を取得したということでしょう。
For example, the RSA cryptosystem is patented in the United States and thus any PCA operating in the U.S. and using RSA to sign certificates and CRLs must represent that it has a valid license to employ the RSA algorithm in this fashion. In contrast, a PCA employing RSA and operating outside of the U.S. would represent that it is exempt from these licensing constraints.
例えば、RSA暗号系は合衆国とその結果、米国で作動するどんなPCAにも特許をとられます、そして、証明書とCRLsがそれを表さなければならないというサインにRSAを使用して、それにはこんなやり方でRSAアルゴリズムを使う有効なライセンスがあります。 対照的に、それがそうであるRSAを使うPCAと米国の外部が表す作動はこれらから認可規制から免除しています。
3.4.3 Policy Certification Authorities
3.4.3 方針証明当局
The policy statement submitted by a prospective PCA must address the topics in the following outline. Additional policy information may be contained in the statement, but PCAs are requested not to use these statements as advertising vehicles.
将来のPCAによって提出された施政方針は以下のアウトラインの話題を記述しなければなりません。 追加方針情報は声明に含まれるかもしれませんが、PCAsが乗り物の広告を出すとしてこれらの声明を使用しないよう要求されています。
1. PCA Identity- The DN of the PCA must be specified. A postal address, an Internet mail address, and telephone (and optional fax) numbers must be provided for (human) contact with the PCA. The date on which this statement is effective, and its scheduled duration must be specified.
1. PCA Identity PCAのDNを指定しなければなりません。 郵便の宛先、インターネット郵便の宛先、および電話(そして、任意のファックス)番号をPCAとの(人間)の接触に提供しなければなりません。 この声明が有効であって、その予定されている持続時間である日付を指定しなければなりません。
2. PCA Scope- Each PCA must describe the community which the PCA plans to serve. A PCA should indicate if it will certify organizational, residential, and/or PERSONA CAs. There is not a requirement that a single PCA serve only one type of CA, but if a PCA serves multiple types of CAs, the policy statement must specify clearly how a user can distinguish among these classes. If the PCA will operate CAs to directly serve residential or PERSONA users, it must so state.
2. PCA Scope各PCAはPCAが役立つのを計画している共同体について説明しなければなりません。 PCAは組織的であって、住宅で公認するだろうか、そして、そして/または、PERSONA CAsを示すはずです。 独身のPCAが1つのタイプのカリフォルニアだけに役立つという要件がありませんが、PCAがCAsの複数のタイプに役立つなら、施政方針は明確にユーザがこれらのクラスでどう区別できるかを指定しなければなりません。 したがって、それは、PCAであるなら直接サーブ住宅へのCAsかPERSONAユーザを手術すると述べなければなりません。
3. PCA Security & Privacy- Each PCA must specify the technical and procedural security measures it will employ in the generation and protection of its component pair. If any security requirements are imposed on CAs certified by the PCA these must be specified as well. A PCA also must specify what measures it will take to protect the privacy of any information collected in the course of certifying CAs. If the PCA operates one or more CAs directly, to serve residential or PERSONA users, then this statement on privacy measures applies to these CAs as well.
3. PCA Security&Privacy各PCAはそれがコンポーネント組の世代と保護で使う技術的で手続き上の安全策を指定しなければなりません。 何かセキュリティ要件がPCAによって公認されたCAsに課されるなら、また、これらを指定しなければなりません。 PCAも、それが始めるどんな測定が何かCAsを公認することの間に集められた情報のプライバシーを保護するかを指定しなければなりません。 PCAが住宅かPERSONAユーザに役立つように直接1CAsを操作するなら、プライバシー測定に関するこの声明はまた、これらのCAsに適用されます。
Kent [Page 18] RFC 1422 Certificate-Based Key Management February 1993
Key Management1993年2月の証明書ベースのケント[18ページ]RFC1422
4. Certification Policy- Each PCA must specify the policy and procedures which govern its certification of CAs and how this policy applies transitively to entities (users or subordinate CAs) certified by these CAs. For example, a PCA must state what procedure is employed to verify the claimed identity of a CA, and the CA's right to use a DN. Similarly, if any requirements are imposed on CAs to validate the identity of users, these requirements must be specified. Since all PCAs are required to cooperate in the resolution of potential DN conflicts, each PCA is required to specify the procedure it will employ to resolve such conflicts. If the PCA imposes a maximum validity interval for the CA certificates it issues, and/or for user (or subordinate CA) certificates issued by the CAs it certifies, then these restrictions must be specified.
4. それぞれ証明Policy PCAは方針と、CAsの証明を治める手順とこの方針がどう移行的に適用されるかをこれらのCAsによって公認された実体(ユーザか下位のCAs)に指定しなければなりません。 例えば、PCAは、どんな手順がカリフォルニアの要求されたアイデンティティ、およびDNを使用するCAの権利について確かめるのに使われるかを述べなければなりません。 同様に、何か要件がユーザのアイデンティティを有効にするためにCAsに課されるなら、これらの要件を指定しなければなりません。 すべてのPCAsが潜在的DN闘争の解決に協力するのに必要であるので、各PCAがそれがそのような闘争を解決するのに使う手順を指定するのに必要です。 PCAがそれが発行するカリフォルニア証明書、それが公認するCAsによって発行されたユーザ(または、下位のカリフォルニア)証明書のために最大の正当性間隔を課すなら、これらの制限を指定しなければなりません。
5. CRL Management- Each PCA must specify the frequency with which it will issue scheduled CRLs. It also must specify any constraints it imposes on the frequency of scheduled issue of CRLs by the CAs it certifies, and by subordinate CAs. Both maximum and minimum constraints should be specified. Since the IPRA policy calls for each CRL issued by a CA to be forwarded to the cognizant PCA, each PCA must specify a mailbox address to which CRLs are to be transmitted. The PCA also must specify a mailbox address for CRL queries. If the PCA offers any additional CRL management services, e.g., archiving of old CRLs, then procedures for invoking these services must be specified. If the PCA requires CAs to provide any additional CRL management services, such services must be specified here.
5. CRL Management各PCAはそれが予定されているCRLsを発行する頻度を指定しなければなりません。 また、それはそれが公認するCAs、および下位のCAsでCRLsの予定されている問題の頻度に課すどんな規制も指定しなければなりません。 最大のものと同様に最小の規制は指定されるべきです。 IPRA方針が、カリフォルニアによって発行された各CRLが認識力があるPCAに送られるように求めるので、各PCAはCRLsが伝えられることになっているメールボックスアドレスを指定しなければなりません。 PCAもCRL質問のためのメールボックスアドレスを指定しなければなりません。 PCAがどんな追加CRL経営指導、例えば、古いCRLsの格納も提供するなら、これらのサービスを呼び出すための手順を指定しなければなりません。 PCAが、CAsがどんな追加CRL経営指導も提供するのを必要とするなら、ここでそのようなサービスを指定しなければなりません。
6. Naming Conventions- If the PCA imposes any conventions on DNs used by the CAs it certifies, or by entities certified by these CAs, these conventions must be specified. If any semantics are associated with such conventions, these semantics must be specified.
6. PCAがそれが公認するCAs、またはこれらのCAsによって公認された実体によって使用されるDNsに何かコンベンションを課すならConventionsを命名して、これらのコンベンションを指定しなければなりません。 何か意味論がそのようなコンベンションに関連しているなら、これらの意味論を指定しなければなりません。
7. Business Issues- If a legal agreement must be executed between a PCA and the CAs it certifies, reference to that agreement must be noted, but the agreement itself ought not be a part of the policy statement. Similarly, if any fees are charged by the PCA this should be noted, but the fee structure per se ought not be part of this policy statement.
7. 法的な協定であるならPCAとそれが公認するCAsの間でビジネスIssuesを実行しなければなりませんが、その協定の参照に注意しなければなりませんが、協定自体は施政方針の一部ではありません。 同様に、何か料金がPCAによって請求されるなら、これは注意されるべきですが、そういうものの料金体系はこの施政方針の一部ではありません。
8. Other- Any other topics the PCA deems relevant to a statement of its policy can be included. However, the PCA should be aware that a policy statement is considered to be an immutable, long lived document and thus considerable care should be exercised in deciding what material is to be included in the statement.
8. 別に、PCAが方針の声明に関連していると考えるいかなる他の話題も含むことができます。 しかしながら、PCAは施政方針が不変の、そして、長い間送られたドキュメントであると考えられるのを意識しているべきです、そして、その結果、どんな材料が声明に含まれるかことであるかと決めるのにかなりの注意が訓練されるべきです。
Kent [Page 19] RFC 1422 Certificate-Based Key Management February 1993
Key Management1993年2月の証明書ベースのケント[19ページ]RFC1422
3.4.4 Certification Authorities
3.4.4 証明当局
In X.509 the term "certification authority" is defined as "an authority trusted by one or more users to create and assign certificates". X.509 imposes few constraints on CAs, but practical implementation of a worldwide certification system requires establishment of technical and procedural conventions by which all CAs are expected to abide. Such conventions are established throughout this document. All CAs are required to maintain a database of the DNs which they have certified and to take measures to ensure that they do not certify duplicate DNs, either for users or for subordinate CAs.
X.509では、「証明権威」という用語は「証明書を作成して、割り当てると1人以上のユーザによって信じられた権威」と定義されます。 X.509はわずかな規制しかCAsに課しませんが、世界的な認証システムの実用的な実現はすべてのCAsがとどまると予想される技術的で手続き上のコンベンションを設立に要求します。 そのようなコンベンションはこのドキュメント中に設立されます。 すべてのCAsが、彼らが公認したDNsに関するデータベースを維持して、ユーザか下位のCAsのために写しDNsを公認しないのを保証する対策を実施するのに必要です。
It is critical that the private component of a CA be afforded a high level of security, otherwise the authenticity guarantee implied by certificates signed by the CA is voided. Some PCAs may impose stringent requirements on CAs within their purview to ensure that a high level of security is afforded the certificate signing process, but not all PCAs are expected to impose such constraints.
カリフォルニアの個人的なコンポーネントに高いレベルのセキュリティを都合するのが批判的である、さもなければ、カリフォルニアによってサインされた証明書によって含意された信憑性保証は欠如します。 いくつかのPCAsが、高いレベルのセキュリティに証明書サインアップ過程を提供しますが、そのような規制を課すとすべてのPCAsを予想するというわけではないのを保証するために彼らの範囲の中で厳しい要件をCAsに課すかもしれません。
3.4.4.1 Organizational CAs
3.4.4.1 組織的なCAs
Many of the CAs certified by PCAs are expected to represent organizations. A wide range of organizations are encompassed by this model: commercial, governmental, educational, non-profit, professional societies, etc. The common thread is that the entities certified by these CAs have some form of affiliation with the organization. The object classes for organizations, organizational units, organizational persons, organizational roles, etc., as defined in X.521, form the models for entities certified by such CAs. The affiliation implied by organizational certification motivates the DN subordination requirement cited in Section 3.4.2.4.
PCAsによって公認されたCAsの多くが組織を代表することが期待されます。 さまざまな組織がこのモデルによって成就されます: 商業の、そして、政府の、そして、教育的で、非営利の専門家の学会など 共通のテーマによるこれらのCAsによって公認された実体が組織による何らかの形式の提携を持っているということです。 組織、組織的なユニット、組織的な人々、組織上の任務などのためのX.521で定義される物のクラスはそのようなCAsによって公認された実体のためのモデルを形成します。 組織的な証明で含意された提携はセクション3.4.2で.4に引用されたDN従属要件を動機づけます。
As an example, an organizational user certificate might contain a subject DN of the form: C = "US" SP = "Massachusetts" L = "Cambridge" O = "Bolt Beranek and Newman" OU = "Communications Division" CN = "Steve Kent". The issuer of this certificate might have a DN of the form: C = "US" SP = "Massachusetts" L = "Cambridge" O= "Bolt Beranek and Newman". Note that the organizational unit attribute is omitted from the issuer DN, implying that there is no CA dedicated to the "Communications Division".
例として、組織的なユーザー証明書は形式の対象のDNを含むかもしれません: 「通信課」「ボルトBeranekとニューマン」「米国」C=SP=「マサチューセッツ」L=「ケンブリッジ」O=OU=CNは「スティーブ・ケント」と等しいです。 この証明書の発行人には、形式のDNがあるかもしれません: 「米国」C=SP=「マサチューセッツ」L=「ケンブリッジ」Oは「ボルトBeranekとニューマン」と等しいです。 組織的なユニットが結果と考える注意は発行人DNから省略されます、「通信課」に捧げられたカリフォルニアが全くないのを含意して。
3.4.4.2 Residential CAs
3.4.4.2 住宅のCAs
Users may wish to obtain certificates which do not imply any organizational affiliation but which do purport to accurately and uniquely identify them. Such users can be registered as residential persons and the DN of such a user should be consistent with the
ユーザは少しの組織的な所属も含意しませんが、正確に唯一それらを特定することを意味する証明書を入手したがっているかもしれません。 そのようなユーザはユーザが一致しているべきであるそのようなものの住宅の人々とDNの登録が済むことができます。
Kent [Page 20] RFC 1422 Certificate-Based Key Management February 1993
Key Management1993年2月の証明書ベースのケント[20ページ]RFC1422
attributes of the corresponding X.521 object class. Over time we anticipate that such users will be accommodated by civil government entities who will assume electronic certification responsibility at geographically designated points in the naming hierarchy. Until civil authorities are prepared to issue certificates of this form, residential user CAs will accommodate such users.
対応するX.521物のクラスの属性。 時間がたつにつれて、私たちは、そのようなユーザが地理的に指定されたポイントで命名階層構造で電子認証責任を負う民間政府の法人によって設備されると予期します。 民間当局がこの形式の証明書を発行する用意ができているまで、住宅のユーザCAsはそのようなユーザを収容するでしょう。
Because residential CAs may be operated under the auspices of multiple PCAs, there is a potential for the same residential CA DN to be assumed by several distinct entities. This represents the one exception to the rule articulated throughout this document that no two entities may have the same DN. This conflict is tolerated so as to allow residential CAs to be established offering different policies. Two requirements are levied upon residential CAs as a result: (1) residential CAs must employ the residential DN conflict detection database maintained by the IPRA, and (2) residential CAs must coordinate to ensure that they do not assign duplicate certificate serial numbers.
住宅のCAsが複数のPCAsの前兆で操作されるかもしれないので、同じ住宅のCA DNがいくつかの別個の物によって想定される可能性があります。 これはいいえtwo、実体には同じDNがあるかもしれないというこのドキュメント中で明確に話された規則への1つの例外を表します。 この闘争は、異なった方針を提供しながら住宅のCAsが設立されるのを許容するために黙認されます。 2つの要件がその結果、住宅のCAsに徴収されます: (1) (2) 住宅のCAsはIPRAによって維持された住宅のDN闘争検出データベースを使わなければなりません、そして、住宅のCAsは彼らが写し証明書通し番号を割り当てないのを保証するために調整しなければなりません。
As an example, a residential user certificate might include a subject name of the form: C = "US" SP = "Massachusetts" L = "Boston" PA = "19 North Square" CN = "Paul Revere." The issuer of that certificate might have a DN of the form: C = "US" SP = "Massachusetts" L = "Boston". Note that the issuer DN is superior to the subject DN, as required by the IPRA policy described earlier.
例として、住宅のユーザー証明書はフォームの対象の名前を含むかもしれません: 「ボストン」「米国」C=SP=「マサチューセッツ」L=PA=「19の北の正方形」CNは「ポールリビア」と等しいです。 その証明書の発行人には、形式のDNがあるかもしれません: 「米国」C=SP=「マサチューセッツ」Lは「ボストン」と等しいです。 発行人DNが必要に応じて対象のDNよりさらに早く説明されたIPRA方針で優れていることに注意してください。
3.4.4.3 PERSONA CAs
3.4.4.3 人格CAs
One or more CAs will be established to accommodate users who wish to conceal their identities while making use of PEM security features, e.g., to preserve the anonymity offered by "arbitrary" mailbox names in the current mail environment. In this case the certifying authority is explicitly NOT vouching for the identity of the user. All such certificates are issued under a PERSONA CA, subordinate to a PCA with a PERSONA policy, to warn users explicitly that the subject DN is NOT a validated user identity. To minimize the possibility of syntactic confusion with certificates which do purport to specify an authenticated user identity, a PERSONA certificate is issued as a form of organizational user certificate, not a residential user certificate. There are no explicit, reserved words used to identify PERSONA user certificates.
1CAsが、PEMセキュリティ機能を利用している間に氏名を秘したがっているユーザを収容して、例えば現在のメール環境における「任意」のメールボックス名によって提供された匿名を保存するために設立されるでしょう。 この場合、公認権威は明らかにユーザのアイデンティティを保証していません。 そのようなすべての証明書が、対象のDNが有効にされたユーザアイデンティティでないと明らかにユーザに警告するためにPERSONA方針でPERSONA CAの下で発行されていて、PCAに下位です。 認証されたユーザアイデンティティを指定することを意味する証明書への構文の混乱の可能性を最小にするために、住宅のユーザー証明書ではなく、組織的なユーザー証明書のフォームとしてPERSONA証明書を発行します。 PERSONAユーザー証明書を特定するのに使用されるどんな明白なリザーブドワードもありません。
A CA issuing PERSONA certificates must institute procedures to ensure that it does not issue the same subject DN to multiple users (a constraint required for all certificates of any type issued by any CA). There are no requirements on an issuer of PERSONA certificates to maintain any other records that might bind the true identity of the subject to his certificate. However, a CA issuing such
PERSONAに証明書を発行するカリフォルニアは、同じ対象DNを複数のユーザに発行しないのを保証するために手順を設けなければなりません(規制がどんなカリフォルニアによっても発行されたどんなタイプのすべての証明書にも必要です)。 対象の本当のアイデンティティを彼の証明書に縛るかもしれないいかなる他の記録も保守するというPERSONA証明書の発行人に関する要件が全くありません。 しかしながら、そのようなものを発行するカリフォルニア
Kent [Page 21] RFC 1422 Certificate-Based Key Management February 1993
Key Management1993年2月の証明書ベースのケント[21ページ]RFC1422
certificates must establish procedures (not specified in this document) in order to allow the holder of a PERSONA certificate to request that his certificate be revoked (i.e., listed on a CRL).
証明書は、PERSONA証明書の所有者が、彼の証明書が取り消されるよう(すなわち、CRLに記載されています)要求するのを許容するために、手順(本書では指定されない)を確立しなければなりません。
As an example, a PERSONA user certificate might include a subject DN of the form: C = "US" SP = "Massachusetts" L = "Boston" O = "Pseudonyms R US" CN = "Paul Revere." The issuer of this certificate might have a DN of the form: C = "US" SP = "Massachusetts" L = "Boston" O = "Pseudonyms R US". Note the differences between this PERSONA user certificate for "Paul Revere" and the corresponding residential user certificate for the same common name.
例として、PERSONAユーザー証明書は形式の対象のDNを含むかもしれません: 「匿名R米国」「米国」C=SP=「マサチューセッツ」L=「ボストン」O=CNは「ポールリビア」と等しいです。 この証明書の発行人には、形式のDNがあるかもしれません: 「米国」C=SP=「マサチューセッツ」L=「ボストン」Oは「匿名R米国」と等しいです。 「ポールリビア」のためのこのPERSONAユーザー証明書と同じ一般名のための対応する住宅のユーザー証明書の違いに注意してください。
3.4.4.4 CA Responsibilities for CRL Management
3.4.4.4 CRL管理へのカリフォルニア責任
As X.500 directory servers become available, CRLs should be maintained and accessed via these servers. However, prior to widespread deployment of X.500 directories, this document adopts some additional requirements for CRL management by CAs and PCAs. As per X.509, each CA is required to maintain a CRL (in the format specified by this document in Appendix A) which contains entries for all certificates issued and later revoked by the CA. Once a certificate is entered on a CRL it remains there until the validity interval expires. Each PCA is required to maintain a CRL for revoked CA certificates within its domain. The interval at which a CA issues a CRL is not fixed by this document, but the PCAs may establish minimum and maximum intervals for such issuance.
X.500ディレクトリサーバが利用可能になるとき、これらのサーバで、CRLsは維持されて、アクセスされるべきです。 しかしながら、X.500ディレクトリの広範囲の展開の前に、このドキュメントはCAsとPCAsによるCRL管理のためにいくつかの追加要件を採用します。 X.509に従って、各カリフォルニアが、すべての証明書のためのエントリーを含むCRL(Appendix Aのこのドキュメントによって指定された形式の)が発行して、後でカリフォルニアのそばで取り消したと主張するのに必要です。 証明書がいったんCRLに入力されると、正当性間隔が期限が切れるまで、それはそこに残っています。 各PCAが、取り消されたカリフォルニア証明書のためにドメインの中でCRLを維持するのに必要です。 カリフォルニアがCRLを発行する間隔はこのドキュメントによって修理されていませんが、PCAsはそのような発行のために最小の、そして、最大の間隔を確立するかもしれません。
As noted earlier, each PCA will provide access to a database containing CRLs issued by the IPRA, PCAs, and all CAs. In support of this requirement, each CA must supply its current CRL to its PCA in a fashion consistent with CRL issuance rules imposed by the PCA and with the next scheduled issue date specified by the CA (see Section 3.5.1). CAs may distribute CRLs to subordinate UAs using the CRL processing type available in PEM messages (see RFC 1421). CAs also may provide access to CRLs via the database mechanism described in RFC 1424 and alluded to immediately above.
より早く注意されるように、各PCAはIPRA、PCAs、およびすべてのCAsによって発行されたCRLsを含むデータベースへのアクセスを提供するでしょう。 この要件を支持して、各カリフォルニアはPCAによって課されるCRL発行規則とカリフォルニアによって指定される次の予定されている問題期日と一致したファッションで現在のCRLをPCAに供給しなければなりません(セクション3.5.1を見てください)。 CAsは、PEMメッセージに手があいているCRL処理タイプを使用することでUAsを下位に置かせるためにCRLsを分配するかもしれません(RFC1421を見てください)。 CAsもRFC1424で説明されて、すぐに上で暗示されたデータベースメカニズムでCRLsへのアクセスを提供するかもしれません。
3.5 Certificate Revocation
3.5 証明書取消し
3.5.1 X.509 CRLs
3.5.1 X.509 CRLs
X.509 states that it is a CA's responsibility to maintain: "a time- stamped list of the certificates it issued which have been revoked." There are two primary reasons for a CA to revoke a certificate, i.e., suspected compromise of a private component (invalidating the corresponding public component) or change of user affiliation (invalidating the DN). The use of Certificate Revocation Lists (CRLs) as defined in X.509 is one means of propagating information
X.509は、それが維持するCAの責任であると述べます: 「それが発行した取り消された証明書の時間の押し込まれたリスト。」 ユーザ提携のカリフォルニアが証明書、すなわち、個人的なコンポーネント(対応する公共のコンポーネントを無効にする)の疑われた感染を取り消すか、または変化する2つのプライマリ理由があります(DNを無効にして)。 X.509の定義されるとしてのCertificate Revocation Lists(CRLs)の使用は情報を伝播する1つの手段です。
Kent [Page 22] RFC 1422 Certificate-Based Key Management February 1993
Key Management1993年2月の証明書ベースのケント[22ページ]RFC1422
relative to certificate revocation, though it is not a perfect mechanism. In particular, an X.509 CRL indicates only the age of the information contained in it; it does not provide any basis for determining if the list is the most current CRL available from a given CA.
それは証明書取消しに比例した完全なメカニズムではありませんが。 特に、X.509 CRLはそれに含まれた情報の時代だけを示します。 それはリストが与えられたカリフォルニアから利用可能な最も現在のCRLであるかどうか決定するどんな基礎も提供しません。
The proposed architecture establishes a format for a CRL in which not only the date of issue, but also the next scheduled date of issue is specified. Adopting this convention, when the next scheduled issue date arrives a CA (Throughout this section, when the term "CA" is employed, it should be interpreted broadly, to include the IPRA and PCAs as well as organizational, residential, and PERSONA CAs.) will issue a new CRL, even if there are no changes in the list of entries. In this fashion each CA can independently establish and advertise the frequency with which CRLs are issued by that CA. Note that this does not preclude CRL issuance on a more frequent basis, e.g., in case of some emergency, but no system-wide mechanisms are architected for alerting users that such an unscheduled issuance has taken place. This scheduled CRL issuance convention allows users (UAs) to determine whether a given CRL is "out of date," a facility not available from the (1988) X.509 CRL format.
提案されたアーキテクチャは発行日だけではなく、次の予定されている発行日も指定されるCRLのために形式を確立します。 次の予定されている問題期日が来るときのこのコンベンションを採用して、カリフォルニア(「カリフォルニア」という用語が採用しているとき、このセクション中では、それは組織的で、住宅と同様にIPRAとPCAs、および人格CAsを含むように露骨に解釈されるべきです。)は新しいCRLを発行するでしょう、エントリーのリストにおける変化が全くなくても。 こんなやり方で各カリフォルニアは、独自に、CRLsがそのカリフォルニアによって発行される頻度を確立して、広告を出すことができます。 これが例えば、より頻繁ベース何らかの非常時の場合にCRL発行を排除しませんが、どんなシステム全体のメカニズムもそのような予定外の発行が行われたとユーザに警告するためにarchitectedされないことに注意してください。 ユーザ(UAs)は、この予定されているCRL発行コンベンションで与えられたCRLが「時代遅れであるかどうか」と決心できます、(1988)X.509 CRL形式から利用可能でない施設。
The description of CRL management in the text and the format for CRLs specified in X.509 (1988) are inconsistent. For example, the latter associates an issuer distinguished name with each revoked certificate even though the text states that a CRL contains entries for only a single issuer (which is separately specified in the CRL format). The CRL format adopted for PEM is a (simplified) format consistent with the text of X.509, but not identical to the accompanying format. The ASN.1 format for CRLs used with PEM is provided in Appendix A.
テキストにおける、CRL管理の記述とX.509(1988)で指定されたCRLsのための形式は無節操です。 例えば、テキストは、CRLがただ一つの発行人(別々にCRL形式で指定される)だけのためのエントリーを含むと述べますが、後者はそれぞれの取り消された証明書に発行人分類名を関連づけます。 PEMのために採用されたCRL形式はX.509のテキストと一致しましたが、付随の形式と同じでない(簡易型)の形式です。 PEMと共に使用されるCRLsのためのASN.1形式をAppendix Aに提供します。
X.509 also defines a syntax for the "time-stamped list of revoked certificates representing other CAs." This syntax, the "AuthorityRevocationList" (ARL) allows the list to include references to certificates issued by CAs other than the list maintainer. There is no syntactic difference between these two lists except as they are stored in directories. Since PEM is expected to be used prior to widespread directory deployment, this distinction between ARLs and CRLs is not syntactically significant. As a simplification, this document specifies the use the CRL format defined below for revocation both of user and of CA certificates.
また、X.509は「他のCAsを表す取り消された証明書の時間で押し込まれたリスト」のために構文を定義します。 この構文、"AuthorityRevocationList"(ARL)で、リストはリスト維持装置以外のCAsによって発行された証明書の指示するものを含むことができます。 それら以外に、ディレクトリに保存されたこれらの2つのリストの間には、どんな構文の違いもありません。 広範囲のディレクトリ展開の前にPEMが使用されると予想されて、ARLsとCRLsのこの区別はシンタクス上重要ではありません。 簡素化として、このドキュメントはCRL形式がユーザとカリフォルニア証明書の取消しのために以下で定義した使用を指定します。
3.5.2 PEM CRL Format
3.5.2 PEM CRL形式
Appendix A contains the ASN.1 description of CRLs specified by this document. This section provides an informal description of CRL components analogous to that provided for certificates in Section 3.3.
付録Aはこのドキュメントによって指定されたCRLsのASN.1記述を含んでいます。 このセクションはセクション3.3の証明書に提供されたそれへの類似のCRLの部品の非公式の記述を提供します。
Kent [Page 23] RFC 1422 Certificate-Based Key Management February 1993
Key Management1993年2月の証明書ベースのケント[23ページ]RFC1422
1. signature (signature algorithm ID and parameters)
1. 署名(署名アルゴリズムIDとパラメタ)
2. issuer
2. 発行人
3. last update
3. アップデート
4. next update
4. 次のアップデート
5. revoked certificates
5. 取り消された証明書
The "signature" is a data item completely analogous to the signature data item in a certificate. Similarly, the "issuer" is the DN of the CA which signed the CRL. The "last update" and "next update" fields contain time and date values (UTCT format) which specify, respectively, when this CRL was issued and when the next CRL is scheduled to be issued. Finally, "revoked certificates" is a sequence of ordered pairs, in which the first element is the serial number of the revoked certificate and the second element is the time and date of the revocation for that certificate.
「署名」は証明書の署名データ項目への完全に類似のデータ項目です。 同様に、「発行人」はCRLに署名したカリフォルニアのDNです。 「アップデート」と「次のアップデート」分野はこのCRLがいつ発行されたか、そして、いつ次のCRLが発行される予定であるかをそれぞれ指定する日時の値(UTCT形式)を含んでいます。 最終的に、「取り消された証明書」は順序対の系列です。(その順序対で、最初の要素は取り消された証明書の通し番号であり、2番目の要素はその証明書のための取消しの日時です)。
The semantics for this second element are not made clear in X.509. For example, the time and date specified might indicate when a private component was thought to have been compromised or it may reflect when the report of such compromise was reported to the CA.
この2番目の要素のための意味論はX.509で明らかにされません。 そのような感染のレポートがカリフォルニアに報告されたとき、例えば、指定された日時が、いつ個人的なコンポーネントが感染されたと考えられたかを示すかもしれませんか、またはそれは反射するかもしれません。
For uniformity, this document adopts the latter convention, i.e., the revocation date specifies the time and date at which a CA formally acknowledges a report of a compromise or a change or DN attributes. As with certificates, it is recommended that the UTCT values be of no finer granularity than minutes and that all values be stated in terms of Zulu.
一様性のために、このドキュメントは後者のコンベンションを採用します、すなわち、取消し日付がカリフォルニアが正式に感染、変化またはDN属性のレポートを承認する日時を指定します。 証明書のように、UTCT値が数分よりすばらしい粒状がないそうであり、すべての値がズールー族に関して述べられているのは、お勧めです。
3.6 Certificate Validation
3.6 証明書合法化
3.6.1 Validation Basics
3.6.1 合法化基礎
Every UA must contain the public component of the IPRA as the root for its certificate validation database. Public components associated with PCAs must be identified as such, so that the certificate validation process described below can operate correctly. Whenever a certificate for a PCA is entered into a UA cache, e.g., if encountered in a PEM message encapsulated header, the certificate must NOT be entered into the cache automatically. Rather, the user must be notified and must explicitly direct the UA to enter any PCA certificate data into the cache. This precaution is essential because introduction of a PCA certificate into the cache implies user recognition of the policy associated with the PCA.
あらゆるUAが証明書合法化データベースのための根としてIPRAの公共の部品を含まなければなりません。 そういうものとしてPCAsに関連している公共のコンポーネントを特定しなければなりません、以下で説明された証明書合法化プロセスが正しく作動できるように。 例えば、ヘッダーであるとカプセル化されたPEMメッセージで遭遇するならPCAのための証明書がUAキャッシュに入力されるときはいつも、自動的に証明書をキャッシュに入力してはいけません。 むしろ、ユーザは、通知しなければならなくて、あらゆるPCA証明書データをキャッシュに入力するようにUAに明らかに向けなければなりません。 キャッシュへのPCA証明書の導入がPCAに関連している方針のユーザ認識を含意するので、この注意は不可欠です。
Kent [Page 24] RFC 1422 Certificate-Based Key Management February 1993
Key Management1993年2月の証明書ベースのケント[24ページ]RFC1422
Validating a certificate begins with verifying that the signature affixed to the certificate is valid, i.e., that the hash value computed on the certificate contents matches the value that results from decrypting the signature field using the public component of the issuer. In order to perform this operation the user must possess the public component of the issuer, either via some integrity-assured channel, or by extracting it from another (validated) certificate. In order to rapidly terminate this recursive validation process, we recommend each PCA sign certificates for all CAs within its domain, even CAs which are certified by other, superior CAs in the certification hierarchy.
証明書に付けられた署名が有効であり、すなわち、証明書コンテンツで計算されたハッシュ値が発行人の公共のコンポーネントを使用することで署名分野を解読するので結果として生じる値に合っていることを確かめるのに証明書を有効にするのは始まります。 この操作を実行するために、ユーザには発行人の公共のコンポーネントが別の(有効にされます)証明書から保全で確実なチャンネルでそれを抽出することによって、なければなりません。 急速にこの再帰的な合法化プロセスを終えるために、私たちは、各PCAがドメイン(証明階層構造の他の、そして、優れたCAsによって公認されるCAsさえ)の中のすべてのCAsのための証明書に署名することを勧めます。
The public component needed to validate certificates signed by the IPRA is made available to each user as part of the registration or via the PEM installation process. Thus a user will be able to validate any PCA certificate immediately. CAs are certified by PCAs, so validation of a CA certificate requires processing a validation path of length two. User certificates are issued by CAs (either immediately subordinate to PCAs or subordinate to other CAs), thus validation of a user certificate may require three or more steps. Local caching of validated certificates by a UA can be used to speed up this process significantly.
IPRAによって署名された証明書を有効にするのに必要である公共のコンポーネントを登録の一部かPEMインストールプロセスを通して各ユーザにとって利用可能にします。 したがって、ユーザはすぐに、どんなPCA証明書も有効にすることができるでしょう。 CAsがPCAsによって公認されるので、カリフォルニア証明書の合法化は、合法化経路を処理するのを長さtwoを要求します。 ユーザー証明書は(他のCAsへのすぐにPCAsへの下位か下位)のCAsによって発行されます、その結果、ユーザー証明書の合法化は3ステップ以上を必要とするかもしれません。 このプロセスをかなり加速するのにUAによる有効にされた証明書の地方のキャッシュを使用できます。
Consider the situation in which a user receives a privacy enhanced message from an originator with whom the recipient has never previously corresponded, and assume that the message originator includes a full certification path in the PEM message header. First the recipient can use the IPRA's public component to validate a PCA certificate contained in an Issuer-Certificate field. Using the PCA's public component extracted from this certificate, the CA certificate in an Issuer-Certificate field also can be validated. This process cam be repeated until the certificate for the originator, from the Originator-Certificate field, is validated.
ユーザが受取人が以前に一度も文通したことがない創始者からプライバシーの高められたメッセージを受け取る状況を考えてください、そして、メッセージ創始者がPEMメッセージヘッダーの完全な証明経路を入れると仮定してください。 まず最初に、受取人は、Issuer-証明書分野に保管されていたPCA証明書を有効にするのにIPRAの公共のコンポーネントを使用できます。 この証明書から抽出されたPCAの公共のコンポーネントを使用して、Issuer-証明書分野のカリフォルニア証明書も有効にすることができます。 このプロセスカムは、創始者のためにOriginator-証明書分野から証明書まで繰り返されて、有効にされます。
Having performed this certificate validation process, the recipient can extract the originator's public component and use it to decrypt the content of the MIC-Info field. By comparing the decrypted contents of this field against the MIC computed locally on the message the user verifies the data origin authenticity and integrity of the message. It is recommended that implementations of privacy enhanced mail cache validated public components (acquired from incoming mail) to speed up this process. If a message arrives from an originator whose public component is held in the recipient's cache (and if the cache is maintained in a fashion that ensures timely incorporation of received CRLs), the recipient can immediately employ that public component without the need for the certificate validation process described here. (For some digital signature algorithms, the processing required for certificate validation is considerably faster
この証明書合法化プロセスを実行したので、受取人は、創始者の公共のコンポーネントを抽出して、MIC-インフォメーション分野の内容を解読するのにそれを使用できます。 メッセージで局所的に計算されたMICに対してこの分野の解読されたコンテンツを比較することによって、ユーザはメッセージのデータ発生源の信憑性と保全について確かめます。 プライバシーの高められたメールキャッシュの実装がこのプロセスを加速するために、公共のコンポーネント(入って来るメールから、取得する)を有効にしたのは、お勧めです。 メッセージが公共のコンポーネントが受取人のキャッシュで保持される創始者から到着するなら(キャッシュが容認されたCRLsのタイムリーな編入を確実にするファッションで維持されるなら)、受取人はすぐに、ここで説明された証明書合法化プロセスの必要性なしでその公共のコンポーネントを使うことができます。 (いくつかのデジタル署名アルゴリズムにおいて、証明書合法化に必要である処理はかなり速いです。
Kent [Page 25] RFC 1422 Certificate-Based Key Management February 1993
Key Management1993年2月の証明書ベースのケント[25ページ]RFC1422
than that involved in signing a certificate. Use of such algorithms serves to minimize the computational burden on UAs.)
証明書に署名するのにかかわるそれより。 そのようなアルゴリズムの使用は、UAsでコンピュータの負担を最小にするのに役立ちます。)
3.6.2 Display of Certificate Validation Data
3.6.2 証明書合法化データのディスプレイ
PEM provides authenticated identities for message recipients and originators expressed in the form of distinguished names. Mail systems in which PEM is employed may employ identifiers other than DNs as the primary means of identifying recipients or originators. Thus, in order to benefit from these authentication facilities, each PEM implementation must employ some means of binding native mail system identifiers to distinguished names in a fashion which does not undermine this basic PEM functionality.
PEMは分類名の形で言い表されたメッセージ受取人と創始者に認証されたアイデンティティを提供します。 PEMが採用しているメールシステムは受取人か創始者を特定するプライマリ手段としてのDNs以外の識別子を使うかもしれません。 したがって、これらの認証施設の利益を得るために、それぞれのPEM実装はこの基本的なPEMが機能性であると弱体化させないファッションによる分類名への拘束力がある固有のメールシステム識別子のいくつかの手段を使わなければなりません。
For example, if a human user interacts directly with PEM, then the full DN of the originator of any message received using PEM should be displayed for the user. Merely displaying the PEM-protected message content, containing an originator name from the native mail system, does not provide equivalent security functionality and could allow spoofing. If the recipient of a message is a forwarding agent such as a list exploder or mail relay, display of the originator's DN is not a relevant requirement. In all cases the essential requirement is that the ultimate recipient of a PEM message be able to ascertain the identity of the originator based on the PEM certification system, not on unauthenticated identification information, e.g., extracted from the native message system.
例えば、人間のユーザが直接PEMと対話するなら、ユーザのためにPEMを使用することで受け取られたどんなメッセージの創始者の完全なDNも表示するべきです。 固有のメールシステムからの創始者名を含んでいて、単にPEMによって保護されたメッセージ内容を表示するのは、同等なセキュリティの機能性を前提としないで、だますのを許容するかもしれません。 メッセージの受取人がリスト発破器かメール中継などの小口運送業者であるなら、創始者のDNのディスプレイは関連要件ではありません。 すべての場合では、必須の条件はPEMメッセージの究極の受取人がオンであるのではなく、PEM認証システムに基づいている創始者のアイデンティティが識別情報を非認証したのを確かめるのにおいて有能であって、例えば、固有のメッセージシステムから抽出されているということです。
Conversely, for the originator of an ENCRYPTED message, it is important that recipient identities be linked to the DNs as expressed in PEM certificates. This can be effected in a variety of ways by the PEM implementation, e.g., by display of recipient DNs upon message submission or by a tightly controlled binding between local aliases and the DNs. Here too, if the originator is a forwarding process this linkage might be effected via various mechanisms not applicable to direct human interaction. Again, the essential requirement is to avoid procedures which might undermine the authentication services provided by PEM.
逆に、ENCRYPTEDメッセージの創始者には、受取人のアイデンティティがPEM証明書で言い表されるようにDNsにリンクされるのは、重要です。 これはPEM実装、例えば、メッセージ提案の受取人DNsのディスプレイまたはローカルの別名とDNsの間のしっかり制御された結合によるさまざまな方法で作用できます。 ここで、創始者であるなら、また、推進は人間の交流を指示するのにおいて適切でない様々なメカニズムを通した作用していて、このリンケージがそうするかもしれないプロセスですか? 一方、必須の条件は認証がPEMによって提供されたサービスであると弱体化させるかもしれない手順を避けることです。
As described above, it is a local matter how and what certification information is displayed for a human user in the course of submission or delivery of a PEM message. Nonetheless all PEM implementations must provide a user with the ability to display a full certification path for any certificate employed in PEM upon demand. Implementors are urged to not overwhelm the user with certification path information which might confuse him or distract him from the critical information cited above.
上で説明されるように、どのように、PEMメッセージの服従か配送の間に人間のユーザのためにどんな証明情報を表示するかは、地域にかかわる事柄です。 それにもかかわらず、すべてのPEM実装が要求に応じてPEMで使われたどんな証明書のためにも完全な証明経路を表示する能力をユーザに提供しなければなりません。 彼を混乱させるかもしれない証明経路情報でユーザを圧倒しない、または作成者が上で引用された重要情報から彼をそらさないよう促されます。
Kent [Page 26] RFC 1422 Certificate-Based Key Management February 1993
Key Management1993年2月の証明書ベースのケント[26ページ]RFC1422
3.6.3 Validation Procedure Details
3.6.3 合法化手順の詳細
Every PEM implementation is required to perform the following validation steps for every public component employed in the submission of an ENCRYPTED PEM message or the delivery of an ENCRYPTED, MIC-ONLY, or MIC-CLEAR PEM message. Each public component may be acquired from an internal source, e.g., from a (secure) cache at the originator/recipient or it may be obtained from an external source, e.g., the PEM header of an incoming message or a directory. The following procedures applies to the validation of certificates from either type of source.
あらゆるPEM実装が、ENCRYPTED PEMメッセージの服従かENCRYPTED、ミックだけ、またはミック-CLEAR PEMメッセージの配送で使われたあらゆる公共のコンポーネントのための以下の合法化ステップを実行するのに必要です。 例えば、内部のソース、創始者/受取人の(安全)のキャッシュからそれぞれの公共のコンポーネントを取得するかもしれませんか、または外部電源(例えば、入力メッセージかディレクトリのPEMヘッダー)からそれを得るかもしれません。 以下の手順はどちらかのタイプの源からの証明書の合法化に適用されます。
Validation of a public component involves constructing a certification path between the component and the public component of the IPRA. The validity interval for every certificate in this path must be checked. PEM software must, at a minimum, warn the user if any certificate in the path fails the validity interval check, though the form of this warning is a local matter. For example, the warning might indicate which certificate in the path had expired. Local security policy may prohibit use of expired certificates.
公共のコンポーネントの合法化は、IPRAのコンポーネントと公共の部品の間の証明経路を構成することを伴います。 この経路のあらゆる証明書のための正当性間隔をチェックしなければなりません。 最小限で、PEMソフトウェアは、何か経路の証明書が正当性間隔チェックに失敗するかどうかとユーザに警告しなければなりません、この警告のフォームは地域にかかわる事柄ですが。 例えば、警告は、経路のどの証明書が期限が切れたかを示すかもしれません。 ローカルの安全保障政策は満期の証明書の使用を禁止するかもしれません。
Each certificate also must be checked against the current CRL from the certificate's issuer to ensure that revoked certificates are not employed. If the UA does not have access to the current CRL for any certificate in the path, the user must be warned. Again, the form of the warning is a local matter. For example, the warning might indicate whether the CRL is unavailable or, if available but not current, the CRL issue date should be displayed. Local policy may prohibit use of a public component which cannot be checked against a current CRL, and in such cases the user should receive the same information provided by the warning indications described above.
取り消された証明書が採用していないのを保証するために現在のCRLに対して証明書の発行人から各証明書もチェックしなければなりません。 UAが経路のどんな証明書のためにも現在のCRLに近づく手段を持っていないなら、ユーザに注意しなければなりません。 一方、警告のフォームは地域にかかわる事柄です。 例えば、警告が、CRLが入手できないかどうかを示すかもしれませんか、または利用可能ですが、現在でないなら、CRL問題日付を表示するべきです。 ローカルの方針は現在のCRLに対してチェックできない公共のコンポーネントの使用を禁止するかもしれません、そして、そのような場合ユーザは上で説明された警告指摘で提供された同じ情報を受け取るべきです。
If any revoked certificates are encountered in the construction of a certification path, the user must be warned. The form of the warning is a local matter, but it is recommended that this warning be more stringent than those previously alluded to above. For example, this warning might display the issuer and subject DNs from the revoked certificate and the date of revocation, and then require the user to provide a positive response before the submission or delivery process may proceed. In the case of message submission, the warning might display the identity of the recipient affected by this validation failure and the user might be provided with the option to specify that this recipient be dropped from recipient list processing without affecting PEM processing for the remaining recipients. Local policy may prohibit PEM processing if a revoked certificate is encountered in the course of constructing a certification path.
何か取り消された証明書が証明経路の構造で遭遇するなら、ユーザに注意しなければなりません。 警告のフォームは地域にかかわる事柄ですが、この警告が以前に上で暗示されたものより厳しいのは、お勧めです。 例えば、服従か配送過程が続くかもしれない前に、この警告は、取り消された証明書と取消しの期日から発行人と対象のDNsを表示して、次に、ユーザが積極的な応答を提供するのを必要とするかもしれません。 メッセージ提案の場合では、警告はこの合法化失敗で影響を受ける受取人のアイデンティティを表示するかもしれません、そして、この受取人が残っている受取人のために受取人リスト処理からPEM処理に影響しないで下げられると指定するためにオプションをユーザに提供するかもしれません。 証明経路を構成することの間に取り消された証明書が遭遇するなら、ローカルの方針はPEM処理を禁止するかもしれません。
Note that in order to comply with these validation procedures, a
これら合法化手順、aに従うためにそれに注意してください。
Kent [Page 27] RFC 1422 Certificate-Based Key Management February 1993
Key Management1993年2月の証明書ベースのケント[27ページ]RFC1422
certificate cache must maintain all of the information contained in a certificate, not just the DNs and the public component. For example the serial number and validity interval must be associated with the cache entry to comply with the checks described above. Also note that these procedures apply to human interaction in message submission and delivery and are not directly applicable to forwarding processes. When non human interaction is involved, a compliant PEM implementation must provide parameters to enable a process to specify whether certificate validation will succeed or fail if any of the conditions arise which would result in warnings to a human user.
証明書キャッシュはDNsと公共のコンポーネントだけではなく、証明書に含まれた情報のすべてを維持しなければなりません。 例えば、通し番号と正当性間隔は、上で説明されるチェックに応じるためにキャッシュエントリーに関連していなければなりません。 また、これらの手順がメッセージ提案と配送における人間の交流に適用して、直接推進プロセスに適切でないことに注意してください。 非人間の交流がかかわるとき、対応するPEM実装は警告をもたらす状態のどれかが起こると、証明書合法化が成功するか、または失敗することにかかわらずプロセスが指定するのを可能にするパラメタを人間のユーザに提供しなければなりません。
Finally, in the course of validating certificates as described above, one additional check must be performed: the subject DN of every certificate must be subordinate to the certificate issuer DN, except if the issuer is the IPRA or a PCA (hence another reason to distinguish the IPRA and PCA entries in a certificate cache). This requirement is levied upon all PEM implementations as part of maintaining the certification hierarchy constraints defined in this document. Any certificate which does not comply with these requirements is considered invalid and must be rejected in PEM submission or delivery processing. The user must be notified of the nature of this fatal error.
最終的に、上で説明されるように証明書を有効にすることの間に、1つの追加チェックを実行しなければなりません: あらゆる証明書の対象のDNは証明書発行人DNに下位であるに違いありません、発行人がIPRAであるか、そして、PCA(証明書キャッシュにおけるしたがって、IPRAを区別する別の理由とPCAエントリー)を除いて。 この要件は本書では定義された証明階層構造規制を維持する一部としてすべてのPEM実装に徴収されます。 これらの要件に従わないどんな証明書も、無効であると考えられて、PEM服従か配送処理で拒絶しなければなりません。 この致命的な誤りの本質についてユーザに通知しなければなりません。
Kent [Page 28] RFC 1422 Certificate-Based Key Management February 1993
Key Management1993年2月の証明書ベースのケント[28ページ]RFC1422
A. Appendix A: ASN.1 Syntax for Certificates and CRLs
A。 付録A: 証明書とCRLsのためのASN.1構文
A.1 Certificate Syntax
A.1証明書構文
The X.509 certificate format is defined by the following ASN.1 syntax:
X.509証明書書式は以下のASN.1構文で定義されます:
Certificate ::= SIGNED SEQUENCE{
version [0] Version DEFAULT v1988,
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name,
validity Validity,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo}
以下を証明してください:= 系列であると署名されます。バージョン[0]バージョンDEFAULT v1988(serialNumber CertificateSerialNumber、署名AlgorithmIdentifier、発行人Name、正当性Validity)はName、subjectPublicKeyInfo SubjectPublicKeyInfoをかけます。
Version ::= INTEGER {v1988(0)}
バージョン:、:= 整数v1988(0)
CertificateSerialNumber ::= INTEGER
CertificateSerialNumber:、:= 整数
Validity ::= SEQUENCE{
notBefore UTCTime,
notAfter UTCTime}
正当性:、:= 系列notBefore UTCTime、notAfter UTCTime
SubjectPublicKeyInfo ::= SEQUENCE{
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING}
SubjectPublicKeyInfo:、:= 系列アルゴリズムAlgorithmIdentifier、subjectPublicKey BIT STRING
AlgorithmIdentifier ::= SEQUENCE{
algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL}
AlgorithmIdentifier:、:= 系列アルゴリズムOBJECT IDENTIFIER、パラメタANY DEFINED BYアルゴリズムOPTIONAL
The components of this structure are defined by ASN.1 syntax defined in the X.500 Series Recommendations. RFC 1423 provides references for and the values of AlgorithmIdentifiers used by PEM in the subjectPublicKeyInfo and the signature data items. It also describes how a signature is generated and the results represented. Because the certificate is a signed data object, the distinguished encoding rules (see X.509, section 8.7) must be applied prior to signing.
この構造の部品はX.500 Series Recommendationsで定義されたASN.1構文で定義されます。 RFC1423は参照を提供して、subjectPublicKeyInfoのPEMによって使用されたAlgorithmIdentifiersの値、署名が発生しているまた. それが説明する署名データ項目、および結果は表しました。 証明書が署名しているデータ・オブジェクトであるので、署名の前に顕著な符号化規則(X.509を見てください、セクション8.7)を適用しなければなりません。
Kent [Page 29] RFC 1422 Certificate-Based Key Management February 1993
Key Management1993年2月の証明書ベースのケント[29ページ]RFC1422
A.2 Certificate Revocation List Syntax
A.2証明書失効リスト構文
The following ASN.1 syntax, derived from X.509 and aligned with the suggested format in recently submitted defect reports, defines the format of CRLs for use in the PEM environment.
最近提出された不具合報告でX.509から得られて、提案された形式に並べられた以下のASN.1構文はPEM環境における使用のためにCRLsの書式を定義します。
CertificateRevocationList ::= SIGNED SEQUENCE{
signature AlgorithmIdentifier,
issuer Name,
lastUpdate UTCTime,
nextUpdate UTCTime,
revokedCertificates
SEQUENCE OF CRLEntry OPTIONAL}
CertificateRevocationList:、:= 系列であると署名されます。署名AlgorithmIdentifier、発行人Name、lastUpdate UTCTime、nextUpdate UTCTime、revokedCertificates SEQUENCE OF CRLEntry OPTIONAL
CRLEntry ::= SEQUENCE{
userCertificate SerialNumber,
revocationDate UTCTime}
CRLEntry:、:= 系列userCertificate SerialNumber、revocationDate UTCTime
References
参照
[1] CCITT Recommendation X.411 (1988), "Message Handling Systems:
Message Transfer System: Abstract Service Definition and
Procedures".
[1] CCITT推薦X.411(1988)、「メッセージハンドリングシステム:」 メッセージ転送システム: 「抽象的なサービス定義と手順。」
[2] CCITT Recommendation X.509 (1988), "The Directory -
Authentication Framework".
[2] CCITT推薦X.509(1988)、「ディレクトリ--認証、フレームワーク、」
[3] CCITT Recommendation X.520 (1988), "The Directory - Selected
Attribute Types".
[3] CCITT推薦X.520(1988)、「ディレクトリ--属性を選択するのはタイプします」。
[4] NIST Special Publication 500-183, "Stable Agreements for Open
Systems Interconnection Protocols," Version 4, Edition 1,
December 1990.
[4] NISTの特別な公表500-183、「開放型システム間相互接続プロトコルのための安定した協定」、バージョン4、版1、1990年12月。
[5] North American Directory Forum, "A Naming Scheme for c=US", RFC
1255, NADF, September 1991.
[5] 北米のディレクトリフォーラム、「cの命名体系は米国と等しい」RFC1255、NADF、1991年9月。
[6] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part
I: Message Encryption and Authentication Procedures", RFC 1421,
DEC, February 1993.
[6] リン、J.、「インターネット電子メールのためのプライバシー増進:」 部分I: 「メッセージ暗号化と認証手順」、RFC1421、12月、2月1993
[7] Balenson, D., "Privacy Enhancement for Internet Electronic Mail:
Part III: Algorithms, Modes, and Identifiers", RFC 1423, TIS,
February 1993.
[7]Balenson、D.、「インターネット電子メールのためのプライバシー増進:」 パートIII: 「アルゴリズム、モード、および識別子」、RFC1423、TIS、2月1993日
[8] Balaski, B., "Privacy Enhancement for Internet Electronic Mail:
Part IV: Notary, Co-Issuer, CRL-Storing and CRL-Retrieving
Services", RFC 1424, RSA Laboratories, February 1993.
[8]Balaski、B.、「インターネット電子メールのためのプライバシー増進:」 パートIV: 「公証人、共同発行人、CRL-保存、およびCRL-検索サービス」、RFC1424、RSA研究所、2月1993
Kent [Page 30] RFC 1422 Certificate-Based Key Management February 1993
Key Management1993年2月の証明書ベースのケント[30ページ]RFC1422
[9] North American Directory Forum, "NADF Standing Documents: A Brief
Overview", RFC 1417, NADF, February 1993.
[9] 北米のディレクトリフォーラム、「NADF地位は以下を記録します」。 「簡潔な概要」、RFC1417、NADF、1993年2月。
Patent Statement
特許声明
This version of Privacy Enhanced Mail (PEM) relies on the use of patented public key encryption technology for authentication and encryption. The Internet Standards Process as defined in RFC 1310 requires a written statement from the Patent holder that a license will be made available to applicants under reasonable terms and conditions prior to approving a specification as a Proposed, Draft or Internet Standard.
Privacy Enhancedメール(PEM)のこのバージョンは特許をとられた公開鍵暗号技術の認証と暗号化の使用に依存します。 RFC1310で定義されるインターネットStandards ProcessはPatent所有者からのProposed、DraftまたはインターネットStandardとして仕様を承認する前に無理のない条件と条件のもとでライセンスを応募者にとって利用可能にするという書かれた声明を必要とします。
The Massachusetts Institute of Technology and the Board of Trustees of the Leland Stanford Junior University have granted Public Key Partners (PKP) exclusive sub-licensing rights to the following patents issued in the United States, and all of their corresponding foreign patents:
リーランドスタンフォードジュニア大学のTrusteesのマサチューセッツ工科大学とBoardは合衆国で発行された以下の特許への権利、およびそれらの対応する外国特許のすべてをPublic Key Partners(PKP)の排他的なサブ認可に与えました:
Cryptographic Apparatus and Method
("Diffie-Hellman")............................... No. 4,200,770
暗号の装置とメソッド(「ディフィー-ヘルマン」)… No.4,200,770
Public Key Cryptographic Apparatus
and Method ("Hellman-Merkle").................... No. 4,218,582
公開鍵の暗号の装置とメソッド(「ヘルマン-Merkle」)… No.4,218,582
Cryptographic Communications System and
Method ("RSA")................................... No. 4,405,829
暗号の通信網とメソッド("RSA")… No.4,405,829
Exponential Cryptographic Apparatus
and Method ("Hellman-Pohlig").................... No. 4,424,414
指数の暗号の装置とメソッド(「ヘルマン-Pohlig」)… No.4,424,414
These patents are stated by PKP to cover all known methods of practicing the art of Public Key encryption, including the variations collectively known as El Gamal.
これらの特許はPublic Key暗号化の芸術を実施するすべての知られているメソッドをカバーするためにPKPによって述べられています、El Gamalとして一括して知られている変化を含んでいて。
Public Key Partners has provided written assurance to the Internet Society that parties will be able to obtain, under reasonable, nondiscriminatory terms, the right to use the technology covered by these patents. This assurance is documented in RFC 1170 titled "Public Key Standards and Licenses". A copy of the written assurance dated April 20, 1990, may be obtained from the Internet Assigned Number Authority (IANA).
公共のKey Partnersはパーティーが妥当なnondiscriminatory諸条件でこれらの特許でカバーされた技術を使用する権利を得ることができるというインターネット協会への書かれた保証を提供しました。 この保証は「公開鍵規格とライセンス」と題をつけられたRFC1170に記録されます。 ISOCの機関の一つで(IANA)から書かれた1990年4月20日付けの保証のコピーを入手するかもしれません。
The Internet Society, Internet Architecture Board, Internet Engineering Steering Group and the Corporation for National Research Initiatives take no position on the validity or scope of the patents and patent applications, nor on the appropriateness of the terms of the assurance. The Internet Society and other groups mentioned above
インターネット協会、インターネット・アーキテクチャ委員会、インターネットEngineering Steering Group、およびNational Research Initiativesのための社は特許と特許出願の正当性か範囲の上と、そして、保証に関する諸条件の適切さの上の立場を全く取りません。 前記のようにインターネット協会と他のグループ
Kent [Page 31] RFC 1422 Certificate-Based Key Management February 1993
Key Management1993年2月の証明書ベースのケント[31ページ]RFC1422
have not made any determination as to any other intellectual property rights which may apply to the practice of this standard. Any further consideration of these matters is the user's own responsibility.
この規格の習慣に申請されるかもしれないいかなる他の知的所有権に関しても少しの決断もしていません。 これらの件のどんなさらなる考慮もユーザの自己の責任です。
Security Considerations
セキュリティ問題
This entire document is about security.
この全体のドキュメントはセキュリティに関するものです。
Author's Address
作者のアドレス
Steve Kent BBN Communications 50 Moulton Street Cambridge, MA 02138
スティーブ・ケントBBN Communications50モールトン・通りケンブリッジ、MA 02138
Phone: (617) 873-3988 EMail: kent@BBN.COM
以下に電話をしてください。 (617) 873-3988 メールしてください: kent@BBN.COM
Kent [Page 32]
ケント[32ページ]
一覧
スポンサーリンク
