RFC1114 日本語訳
1114 Privacy enhancement for Internet electronic mail: Part II -certificate-based key management. S.T. Kent, J. Linn. August 1989. (Format: TXT=69661 bytes) (Obsoleted by RFC1422) (Status: HISTORIC)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group S. Kent
Request for Comments: 1114 BBNCC
J. Linn
DEC
IAB Privacy Task Force
August 1989
コメントを求めるワーキンググループS.ケント要求をネットワークでつないでください: 1114 BBNCC J.リン1989年12月のIABプライバシー特別委員会8月
Privacy Enhancement for Internet Electronic Mail:
Part II -- Certificate-Based Key Management
インターネット電子メールのためのプライバシー増進: パートII--証明書ベースのKey Management
STATUS OF THIS MEMO
このメモの状態
This RFC suggests a draft standard elective protocol for the Internet community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このRFCはインターネットコミュニティのために草稿規格選挙のプロトコルを勧めて、改良のために議論と提案を要求します。 このメモの分配は無制限です。
ACKNOWLEDGMENT
承認
This RFC is the outgrowth of a series of IAB Privacy Task Force meetings and of internal working papers distributed for those meetings. We would like to thank the members of the Privacy Task Force for their comments and contributions at the meetings which led to the preparation of this RFC: David Balenson, Curt Barker, Matt Bishop, Morrie Gasser, Russ Housley, Dan Nessett, Mike Padlipsky, Rob Shirey, and Steve Wilbur.
このRFCは一連のIAB Privacy Task Forceミーティングとそれらのミーティングのために配布された内部の働く書類の派生物です。 このRFCの準備につながったミーティングで彼らのコメントと貢献についてPrivacy Task Forceのメンバーに感謝申し上げます: デヴィッドBalenson、そっけないバーカー、ラスHousley、ダンNessett、マイクPadlipsky、ロブShirey、およびマットスティーブ・ウィルバー司教(モーリー・ガッサー)。
Table of Contents
目次
1. Executive Summary 2 2. Overview of Approach 3 3. Architecture 4 3.1 Scope and Restrictions 4 3.2 Relation to X.509 Architecture 7 3.3 Entities' Roles and Responsibilities 7 3.3.1 Users and User Agents 8 3.3.2 Organizational Notaries 9 3.3.3 Certification Authorities 11 3.3.3.1 Interoperation Across Certification Hierarchy Boundaries 14 3.3.3.2 Certificate Revocation 15 3.4 Certificate Definition and Usage 17 3.4.1 Contents and Use 17 3.4.1.1 Version Number 18 3.4.1.2 Serial Number 18 3.4.1.3 Subject Name 18 3.4.1.4 Issuer Name 19 3.4.1.5 Validity Period 19 3.4.1.6 Subject Public Component 20
1. 要約2 2。 アプローチ3 3の概要。 アーキテクチャ4 3.1の範囲と制限、4、3.2関係、X.509アーキテクチャ7 3.3の実体の役割と責任7 3.3人の.1人のユーザとユーザエージェント8 3.3.2人の組織的な公証人9 3.3.3証明当局11 3.3.3、証明階層構造限界の向こう側の.1Interoperation、14、3; 3.3.2 取消し15 3.4証明書定義と3.4の用法17.1内容を証明してください、そして、17 3.4.1.1バージョンNo.18 3.4.1.2通し番号18 3.4の.1の.3の対象の名18の3.4.1.4発行人名19の3.4.1.5有効期間19 3.4の.1の.6の対象の公共のコンポーネント20を使用してください。
Kent & Linn [Page 1] RFC 1114 Mail Privacy: Key Management August 1989
ケントとリン[1ページ]RFC1114はプライバシーを郵送します: Key Management1989年8月
3.4.1.7 Certificate Signature 20 3.4.2 Validation Conventions 20 3.4.3 Relation with X.509 Certificate Specification 22 NOTES 24
3.4.1.7 X.509証明書仕様22注意24との証明書署名20 3.4.2合法化コンベンション20 3.4.3関係
1. Executive Summary
1. 要約
This is one of a series of RFCs defining privacy enhancement mechanisms for electronic mail transferred using Internet mail protocols. RFC-1113 (the successor to RFC 1040) 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-1115 specifies algorithms for use in processing privacy-enhanced messages, as called for in RFC-1113. This RFC defines a supporting key management architecture and infrastructure, based on public-key certificate techniques, to provide keying information to message originators and recipients. A subsequent RFC, the fourth in this series, will provide detailed specifications, paper and electronic application forms, etc. for the key management infrastructure described herein.
これはインターネットメールプロトコルを使用することで移された電子メールのためにプライバシーエンハンスメカニズムを定義する一連のRFCsの1つです。 RFC-1113(RFC1040の後継者)はプロトコル拡大と現像処理をRFC-822メール・メッセージに定めます、適当な暗号化キーが必要な前提条件として創始者と受取人によって持たれているなら。 RFC-1115はRFC-1113で求められるようにプライバシーで高められたメッセージを処理することにおける使用のためのアルゴリズムを指定します。 このRFCは、メッセージ創始者と受取人に情報を合わせながら提供するために公開鍵証明書のテクニックに基づくサポートの主要な管理体系とインフラストラクチャを定義します。 その後のRFC(このシリーズにおける4番目)は仕様詳細を提供するでしょう、とかぎ管理インフラストラクチャのための紙と電子応用学フォームなどはここに説明しました。
The key management architecture described in this RFC is compatible with the authentication framework described in X.509. The major contributions of this RFC lie not in the specification of computer communication protocols or algorithms but rather in procedures and conventions for the key management infrastructure. This RFC incorporates numerous conventions to facilitate near term implementation. Some of these conventions may be superceded in time as the motivations for them no longer apply, e.g., when X.500 or similar directory servers become well established.
このRFCで説明されたかぎ管理アーキテクチャはX.509で説明される認証フレームワークと互換性があります。 かぎ管理インフラストラクチャのためのむしろ手順とコンベンションにはこのRFCの主要な貢献がコンピュータ通信プロトコルかアルゴリズムの仕様にあるのではなく、あります。 このRFCは、短期間実装を容易にするために多数のコンベンションを法人組織にします。 それらに関する動機がもう適用されないとき、これらのコンベンションのいくつかが時間内にスーパー割譲されるかもしれません、例えば、X.500か同様のディレクトリサーバが確固とするようになると。
The RSA cryptographic algorithm, covered in the U.S. by patents administered through RSA Data Security, Inc. (hereafter abbreviated RSADSI) has been selected for use in this key management system. This algorithm has been selected because it provides all the necessary algorithmic facilities, is "time tested" and is relatively efficient to implement in either software or hardware. It is also the primary algorithm identified (at this time) for use in international standards where an asymmetric encryption algorithm is required. Protocol facilities (e.g., algorithm identifiers) exist to permit use of other asymmetric algorithms if, in the future, it becomes appropriate to employ a different algorithm for key management. However, the infrastructure described herein is specific to use of the RSA algorithm in many respects and thus might be different if the underlying algorithm were to change.
RSA暗号アルゴリズム、米国でRSA Data Securityを通して管理された特許でカバーされて、Inc.(今後簡略化されたRSADSI)はこのかぎ管理システムにおける使用のために選択されました。 それがすべての必要なアルゴリズムの施設を提供して、「長い年月をかけて検証され」て、ソフトウェアかハードウェアのどちらかで実装するために比較的効率的であるので、このアルゴリズムは選択されました。 また、それは非対称の暗号化アルゴリズムが必要であるところで(このとき)世界規格における使用のために特定されたプライマリアルゴリズムです。 かぎ管理のための異なったアルゴリズムを使うのが将来適切になるなら、プロトコル施設(例えば、アルゴリズム識別子)は、他の非対称のアルゴリズムの使用を可能にするために存在しています。 しかしながら、ここに説明されたインフラストラクチャは、あらゆる点でRSAアルゴリズムの使用に特定であり、その結果、基本的なアルゴリズムが変化するなら、異なっているでしょうに。
Current plans call for RSADSI to act in concert with subscriber organizations as a "certifying authority" in a fashion described
ファッションによる「公認権威」が説明したように現在のプランは、RSADSIが加入者組織と共に一致した行動を取るように求めます。
Kent & Linn [Page 2] RFC 1114 Mail Privacy: Key Management August 1989
ケントとリン[2ページ]RFC1114はプライバシーを郵送します: Key Management1989年8月
later in this RFC. RSADSI will offer a service in which it will sign a certificate which has been generated by a user and vouched for either by an organization or by a Notary Public. This service will carry a $25 biennial fee which includes an associated license to use the RSA algorithm in conjunction with privacy protection of electronic mail. Users who do not come under the purview of the RSA patent, e.g., users affiliated with the U.S. government or users outside of the U.S., may make use of different certifying authorities and will not require a license from RSADSI. Procedures for interacting with these other certification authorities, maintenance and distribution of revoked certificate lists from such authorities, etc. are outside the scope of this RFC. However, techniques for validating certificates issued by other authorities are contained within the RFC to ensure interoperability across the resulting jurisdictional boundaries.
このRFCで、より遅く。 RSADSIはそれが組織かNotary Publicによってユーザによって作られて、保証された証明書に署名するサービスを提供するでしょう。 このサービスは電子メールのプライバシー保護に関連してRSAアルゴリズムを使用する関連ライセンスを含んでいる25ドルの二年に一度の料金を運ぶでしょう。 RSA特許の範囲に該当しないユーザ(例えば米国の外で米国政府かユーザに所属したユーザ)が、当局を公認しながら異なることの使用をするかもしれなくて、RSADSIからライセンスを必要としないでしょう。 そのような当局から取り消された証明書リストのこれらの他の証明当局、メインテナンス、および分配と対話するための手順、このRFCの範囲の外になどがあります。 しかしながら、他の当局によって発行された証明書を有効にするためのテクニックは、結果として起こる司法権の境界の向こう側に相互運用性を確実にするためにRFCの中に含まれています。
2. Overview of Approach
2. アプローチの概要
This RFC defines a key management architecture based on the use of public-key certificates, in support of the message encipherment and authentication procedures defined in RFC-1113. In the proposed architecture, a "certification authority" representing an organization applies a digital signature to a collection of data consisting of a user's public component, various information that serves to identify the user, and the identity of the organization whose signature is affixed. (Throughout this RFC we have adopted the terms "private component" and "public component" to refer to the quantities which are, respectively, kept secret and made publically 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.) This establishes a binding between these user credentials, the user's public component and the organization which vouches for this binding. The resulting signed, data item is called a certificate. The organization identified as the certifying authority for the certificate is the "issuer" of that certificate.
このRFCは公開鍵証明書の使用に基づくかぎ管理アーキテクチャを定義します、RFC-1113で定義されたメッセージ暗号文と認証手順を支持して。 提案されたアーキテクチャでは、組織を代表する「証明権威」はユーザの公共のコンポーネントから成るデータの収集、ユーザを特定するのに役立つ様々な情報、および署名が付けられる組織のアイデンティティにデジタル署名を適用します。 このRFC中では、私たちは、非対称の暗号系でそれぞれ秘密にされて、publicallyに利用可能にされる量について言及するために用語「個人的なコンポーネント」と「公共のコンポーネント」を採用しました。(このコンベンションは左右対称の暗号系で前の量かキーを参照するために「秘密鍵」という用語の使用から起こる可能な混乱を避けるために採用されます。) これはこの結合を保証するこれらのユーザ資格証明書の間の結合、ユーザの公共のコンポーネント、および組織を確立します。 結果になることは署名して、データ項目は証明書と呼ばれます。 証明書のための公認権威として特定された組織はその証明書の「発行人」です。
In signing the certificate, the certification authority vouches for the user's identification, especially as it relates to the user's affiliation with the organization. The digital signature is affixed on behalf of that organization and is in a form which can be recognized by all members of the privacy-enhanced electronic mail community. Once generated, certificates can be stored in directory servers, transmitted via unsecure message exchanges, or distributed via any other means that make certificates easily accessible to message originators, without regard for the security of the transmission medium.
証明書に署名する際に、証明権威はユーザの識別を保証します、特に組織によるユーザの提携に関連するとき。 デジタル署名は、その組織を代表して付けられて、プライバシーで高められた電子メール共同体のすべてのメンバーが認めることができるフォームにあります。 いったん生成されると、証明書をディレクトリサーバで保存するか、unsecure交換処理で伝えられるか、または証明書をメッセージ創始者には容易にアクセスしやすくするいかなる他の手段でも配布できます、トランスミッション媒体のセキュリティへの尊敬なしで。
Kent & Linn [Page 3] RFC 1114 Mail Privacy: Key Management August 1989
ケントとリン[3ページ]RFC1114はプライバシーを郵送します: Key Management1989年8月
Prior to sending an encrypted message, 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 (described later) or is itself distributed in a certificate to which this validation procedure is applied recursively.
暗号化メッセージを送る前に、創始者は、各受取人への証明書を入手しなければならなくて、これらの証明書を有効にしなければなりません。 簡潔に、合法化は証明書におけるデジタル署名をチェックすることによって、実行されます、個人的なコンポーネントが証明書に署名するのに使用された発行人の公共のコンポーネントを使用して。 発行人の公共のコンポーネントは、バンド手段(後で説明される)からのいくつかを通して利用可能に作られているか、またはこの合法化手順が再帰的に適用される証明書で分配されます。
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) that is used to encrypt the message itself.
受取人への証明書がいったん有効にされると、証明書に含まれた公共のコンポーネントは、メッセージ自体を暗号化するのに使用されるデータ暗号化キー(DEK)を暗号化するのに抽出されて、使用されます。
The resulting encrypted DEK is incorporated into the X-Key-Info field of the message header. Upon receipt of an encrypted message, a recipient employs his secret component to decrypt this field, extracting the DEK, and then uses this DEK to decrypt the message.
結果として起こる暗号化されたDEKはメッセージヘッダーのX主要なインフォメーション分野に組み入れられます。 暗号化メッセージを受け取り次第、受取人は、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 secret component of his public-key pair, and includes the resulting value in the message header in the X-MIC- Info field. The certificate of the originator is also included in the header in the X-Certificate field as described in RFC-1113, 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, 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 of the message.
発生源認証をメッセージの保全とデータに提供するために、創始者は、メッセージの保全がコード(MIC)であると生成して、彼の公開鍵組の秘密のコンポーネントを使用することでMICに署名して(暗号化します)、X-MICインフォメーション分野のメッセージヘッダーで結果として起こる値を入れます。 また、創始者の証明書はRFC-1113で説明されるようにX-証明書分野のヘッダーに含まれています、遍在しているディレクトリサービスがないとき合法化を容易にするために。 プライバシーの高められたメッセージを受け取り次第、受取人は、創始者の証明書を有効にして、証明書から公共のコンポーネントを抽出して、MICを回収すること(解読する)にその値を使用します。 回復しているMICは、メッセージの保全とデータ発生源の信憑性について確かめるために局所的に計算されたMICに対して比較されます。
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 (see RFC-1113) in the Internet environment. The architecture describes procedures for ordering certificates from issuers, for generating and distributing certificates, and for "hot listing" of revoked certificates. Concurrent with the issuance of this RFC, RFC 1040 has been updated and reissued as RFC-1113 to describe the syntax and semantics of new or revised header fields used to transfer certificates, represent the DEK and MIC in this public-key context, and to segregate algorithm definitions into a separate RFC to facilitate the addition of other algorithms in the future. This RFC focuses on the management aspects of certificate-
以下で説明されたアーキテクチャがプライバシーの高められた電子メールを支持してインターネット環境で公開鍵暗号系値を管理する(RFC-1113を見ます)基礎を提供することを意図します。 アーキテクチャは発行人に証明書を注文する、証明書を生成して、配布する、および取り消された証明書の「熱いリスト」のために手順について説明します。 この公開鍵文脈と、隔離された人アルゴリズム定義へのDEKとMICはこのRFCの発行で同時発生であり、証明書を移すのに使用される新しいか改訂されたヘッダーフィールドの構文と意味論について説明するためにRFC-1113としてRFC1040をアップデートして、再発行したと将来他のアルゴリズムの追加を容易にする別々のRFCに表します。 このRFCは証明書の管理局面に焦点を合わせます。
Kent & Linn [Page 4] RFC 1114 Mail Privacy: Key Management August 1989
ケントとリン[4ページ]RFC1114はプライバシーを郵送します: Key Management1989年8月
based, public-key cryptography for privacy enhanced mail while RFC- 1113 addresses representation and processing aspects of such mail, including changes required by this key management technology.
RFC1113は、表現と処理がそのようなメールの局面であると扱いますが、プライバシーのための公開鍵暗号はメールを高めました、ベースでありこのかぎ管理技術によって必要とされた変化を含んでいて。
The proposed architecture imposes conventions for certification paths which are not strictly required by the X.509 recommendation nor by the technology itself. The decision to impose these conventions is based in part on constraints imposed by the status of the RSA cryptosystem within the U.S. as a patented algorithm, and in part on the need for an organization to assume operational responsibility for certificate management in the current (minimal) directory system infrastructure for electronic mail. Over time, we anticipate that some of these constraints, e.g., directory service availability, will change and the procedures specified in the RFC will be reviewed and modified as appropriate.
提案されたアーキテクチャはX.509推薦と技術自体によって厳密に必要とされない証明経路にコンベンションを課します。 これらのコンベンションを課すという決定は米国の中でRSA暗号系の状態によって特許をとられたアルゴリズムと、組織が電子メールのために現在(最小量の)のディレクトリシステムインフラストラクチャにおける証明書管理への操作上の責任を負う一部必要性に課された規制に一部基づいています。 時間がたつにつれて、私たちが、これらの規制のいくつか(例えば、ディレクトリサービスの有用性)が変化すると予期して、RFCで指定された手順は、適宜見直されて、変更されるでしょう。
At this time, we propose a system in which user certificates represent the leaves in a shallow (usually two tier) certification hierarchy (tree). Organizations which act as issuers are represented by certificates higher in the tree. This convention minimizes the complexity of validating user certificates by limiting the length of "certification paths" and by making very explicit the relationship between a certificate issuer and a user. Note that only organizations may act as issuers in the proposed architecture; a user certificate may not appear in a certification path, except as the terminal node in the path. 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.
このとき、私たちはユーザー証明書が浅い(通常2層)証明階層構造(木)で葉を表すシステムを提案します。 発行人として機能する組織は証明書によって木で、より高く代表されます。 このコンベンションは非常に明白な状態で「証明経路」の長さを制限して、作成でユーザー証明書を有効にする複雑さを最小にします。証明書発行人とユーザとの関係。 組織だけが提案されたアーキテクチャの発行人として機能するかもしれないことに注意してください。 経路の端末のノード以外に、ユーザー証明書は証明経路に現れないかもしれません。 これらのコンベンションはX.509の下で受入れられたそのコンパチブル部分集合である証明階層構造をもたらします、構文と意味論の両方に関して。
The RFC proposes that RSADSI act as a "co-issuer" of certificates on behalf of most organizations. This can be effected in a fashion which is "transparent" so that the organizations appear to be the issuers with regard to certificate formats and validation procedures. This is effected by having RSADSI generate and hold the secret components used to sign certificates on behalf of organizations. The motivation for RSADSI's role in certificate signing is twofold. First, it simplifies accounting controls in support of licensing, ensuring that RSADSI is paid for each certificate. Second, it contributes to the overall integrity of the system by establishing a uniform, high level of protection for the private-components used to sign certificates. If an organization were to sign certificates directly on behalf of its affiliated users, the organization would have to establish very stringent security and accounting mechanisms and enter into (elaborate) legal agreements with RSADSI in order to provide a comparable level of assurance. Requests by organizations to perform direct certificate signing will be considered on a case- by-case basis, but organizations are strongly urged to make use of the facilities proposed by this RFC.
RFCは、RSADSIが証明書の「共同発行人」としてほとんどの組織を代表して機能するよう提案します。 「透明な」ファッションでこれが作用できるので、組織は証明書形式と合法化手順に関する発行人であるように見えます。 RSADSIが、秘密のコンポーネントが組織を代表して証明書に署名するのに使用される生成して、ままにするのを持っていることによって、これは作用します。 証明書署名におけるRSADSIの役割に関する動機は二つです。 まず最初に、RSADSIが各証明書のために支払われるのを確実にして、それは認可を支持して会計管理を簡素化します。 2番目に、それは、ユニフォーム(証明書に署名するのに使用される個人的なコンポーネントのための高いレベルの保護)を設立することによって、システムの総合的な保全に貢献します。 組織が直接系列ユーザを代表して証明書に署名するなら、組織は、匹敵するレベルを保証を提供するために非常に厳しいセキュリティと会計機構を確立して、RSADSIとの(入念)の法的な協定に入らなければならないでしょうに。 組織によるダイレクト証明書署名を実行するという要求はケースによるケースベースで考えられるでしょうが、組織がこのRFCによって提案された施設を利用するよう強く促されます。
Kent & Linn [Page 5] RFC 1114 Mail Privacy: Key Management August 1989
ケントとリン[5ページ]RFC1114はプライバシーを郵送します: Key Management1989年8月
Note that the risks associated with disclosure of an organization's secret component are different from those associated with disclosure of a user's secret component. The former component is used only to sign certificates, never to encrypt message traffic. Thus the exposure of an organization's secret component could result in the generation of forged certificates for users affiliated with that organization, but it would not affect privacy-enhanced messages which are protected using legitimate certificates. Also note that any certificates generated as a result of such a disclosure are readily traceable to the issuing authority which holds this component, e.g., RSADSI, due to the non-repudiation feature of the digital signature. The certificate registration and signing procedures established in this RFC would provide non-repudiable evidence of disclosure of an organization's secret component by RSADSI. Thus this RFC advocates use of RSADSI as a co-issuer for certificates until such time as technical security mechanisms are available to provide a similar, system-wide level of assurance for (distributed) certificate signing by organizations.
組織の秘密のコンポーネントの公開に関連しているリスクがユーザの秘密のコンポーネントの公開に関連づけられたものと異なっていることに注意してください。 前のコンポーネントは、単に証明書に署名して、メッセージトラフィックを決して暗号化しないように使用されます。 したがって、組織の秘密のコンポーネントの暴露はその組織に所属するユーザへの偽造証券の世代で結果として生じることができましたが、それは正統の証明書を使用することで保護されるプライバシーで高められたメッセージに影響しないでしょう。 また、そのような公開の結果、作られたどんな証明書も容易にこのコンポーネントを保持する発行機関に起因していることに注意してください、例えば、RSADSI、デジタル署名の非拒否機能のため。 このRFCに確立された証明書登録と署名手順はRSADSIによる組織の秘密のコンポーネントの公開に関する非repudiable証拠を提供するでしょう。 したがって、技術的であるような時間までの証明書のための共同発行人セキュリティー対策が組織で(分配される)の証明書署名のための同様の、そして、システム全体のレベルを保証を提供するために利用可能であるときに、このRFCはRSADSIの使用を支持します。
We identify two classes of exceptions to this certificate signing paradigm. First, the RSA algorithm is patented only within the U.S., and thus it is very likely that certificate signing by issuers will arise outside of the U.S., independent of RSADSI. Second, the research that led to the RSA algorithm was sponsored by the National Science Foundation, and thus the U.S. government retains royalty-free license rights to the algorithm. Thus the U.S. government may establish a certificate generation facilities for its affiliated users. A number of the procedures described in this document apply only to the use of RSADSI as a certificate co-issuer; all other certificate generation practices lie outside the scope of this RFC.
私たちはこの証明書署名パラダイムへの2つのクラスの例外を特定します。 まず最初に、RSAアルゴリズムは米国だけの中で特許をとられます、そして、その結果、発行人で署名するその証明書が米国の外に起こるのは、非常にありそうです、RSADSIの如何にかかわらず。 2番目に、RSAアルゴリズムにつながった研究は国立科学財団によって後援されました、そして、その結果、米国政府はアルゴリズムへのロイヤリティのいらないライセンス権利を保有します。 したがって、米国政府は系列ユーザのために証明書世代施設を設立するかもしれません。 本書では説明された多くの手順が証明書共同発行人としてRSADSIの使用だけに適用されます。 他のすべての証明書世代、習慣はこのRFCの範囲の外に横たわっています。
This RFC specifies procedures by which users order certificates either directly from RSADSI or via a representative in an organization with which the user holds some affiliation (e.g., the user's employer or educational institution). Syntactic provisions are made which allow a recipient to determine, to some granularity, which identifying information contained in the certificate is vouched for by the certificate issuer. In particular, organizations will usually be vouching for the affiliation of a user with that organization and perhaps a user's role within the organization, in addition to the user's name. In other circumstances, as discussed in section 3.3.3, a certificate may indicate that an issuer vouches only for the user's name, implying that any other identifying information contained in the certificate may not have been validated by the issuer. These semantics are beyond the scope of X.509, but are not incompatible with that recommendation.
このRFCはユーザが直接RSADSIか代表を通したユーザがいくらかの提携(例えば、ユーザの雇い主か学園)を保持する組織における証明書を注文する手順を指定します。 受取人が、証明書に含まれたどの身元が分かる情報が証明書発行人によって保証されるかを何らかの粒状に決心できる構文の条項は作られています。 通常、特に、組織は組織の中でその組織と恐らくユーザの役割があるユーザの提携を保証するでしょう、ユーザの名前に加えて。 他の事情では、証明書は、セクション3.3.3で議論するように発行人がユーザの名前だけを保証するのを示すかもしれません、証明書に含まれたいかなる他の身元が分かる情報も発行人によって有効にされていないかもしれないのを含意して。 これらの意味論は、X.509の範囲を超えていますが、その推薦と両立しなくはありません。
The key management architecture described in this RFC has been
このRFCで説明されたかぎ管理アーキテクチャがありました。
Kent & Linn [Page 6] RFC 1114 Mail Privacy: Key Management August 1989
ケントとリン[6ページ]RFC1114はプライバシーを郵送します: Key Management1989年8月
designed to support privacy enhanced mail as defined in this RFC, RFC-1113, and their successors. Note that this infrastructure also supports X.400 mail security facilities (as per X.411) and thus paves the way for transition to the OSI/CCITT Message Handling System paradigm in the Internet in the future. The certificate issued to a user for the $25 biennial fee will grant to the user identified by that certificate a license from RSADSI to employ the RSA algorithm for certificate validation and for encryption and decryption operations in this electronic mail context. No use of the algorithm outside the scope defined in this RFC is authorized by this license as of this time. Expansion of the license to other Internet security applications is possible but not yet authorized. The license granted by this fee does not authorize the sale of software or hardware incorporating the RSA algorithm; it is an end-user license, not a developer's license.
プライバシーがこのRFCで定義される、高められたメールと、RFC-1113と、彼らの後継者であるとサポートするために、設計されています。 このインフラストラクチャがまた、X.400メールがセキュリティ施設(X.411に従って)であるとサポートして、その結果、将来インターネットでオウシ/CCITT Message Handling Systemパラダイムへの変遷へ道を開くことに注意してください。 二年に一度の料金がユーザに与える25ドルでユーザに発行された証明書は、この電子メール文脈で証明書合法化と暗号化と復号化操作のためのRSAアルゴリズムを使うためにRSADSIからその証明書によるライセンスを特定しました。 このRFCで定義された範囲の外のアルゴリズムの無駄は今回付けで、このライセンスによって認可されます。 他のインターネットセキュリティアプリケーションへのライセンスの拡張は、可能ですが、まだ認可されていません。 この料金によって与えられたライセンスはRSAアルゴリズムを取り入れるソフトウェアかハードウェアの販売を認可しません。 それは開発者のライセンスではなく、エンドユーザライセンスです。
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. The public-key certificate approach defined in X.509 has also been adopted in CCITT 1988 X.411 in support of the message handling application.
CCITT、1988Recommendation X.509、「ディレクトリ--、認証フレームワーク、」、分配されたディレクトリサービスにかかわる実体の認証のためにフレームワークを定義します。 X.509で定義される強い認証は公開鍵暗号系の使用で実行されます。Unforgeable証明書は証明当局によって作られます。 そのような組織はX.509によって必要とされませんが、これらの当局は階層的で組織化されるかもしれません。 属性を命名するディレクトリシステムによって課された証明階層構造と命名階層構造の間には、どんな暗示しているマッピングもありません。 また、X.509で定義された公開鍵証明書アプローチはメッセージハンドリングアプリケーションを支持してCCITT1988X.411で取られました。
This RFC interprets the X.509 certificate mechanism to serve the needs of privacy-enhanced mail in the Internet environment. The certification hierarchy proposed in this RFC in support of privacy enhanced mail is intentionally a subset of that allowed under X.509. In large part constraints have been levied in order to simplify certificate validation in the absence of a widely available, user- level directory service. The certification hierarchy proposed here also embodies semantics which are not explicitly addressed by X.509, but which are consistent with X.509 precepts. The additional semantic constraints have been adopted to explicitly address questions of issuer "authority" which we feel are not well defined in X.509.
このRFCは、インターネット環境における、プライバシーで高められたメールの必要性に役立つようにX.509証明書メカニズムを解釈します。 このRFCでプライバシーの高められたメールを支持して提案された証明階層構造は故意に、その部分集合が下のX.509を許容したということです。 主に規制は、広く利用可能なユーザのレベルディレクトリサービスがないとき証明書合法化を簡素化するために徴収されました。 また、ここで提案された証明階層構造は意味論を具体化します(明らかに扱われませんが、X.509はX.509教訓と一致させています)。 追加意味規制は、明らかによく定義されない私たちがX.509で感じる発行人「権威」の質問を扱うために採用されました。
3.3 Entities' Roles and Responsibilities
3.3 実体の役割と責任
One way to explain the architecture proposed by this RFC is to examine the various roles which are defined for various entities in
このRFCによって提案されたアーキテクチャが様々な実体のために定義される様々な役割を調べることであると説明するのにおいて、一方通行です。
Kent & Linn [Page 7] RFC 1114 Mail Privacy: Key Management August 1989
ケントとリン[7ページ]RFC1114はプライバシーを郵送します: Key Management1989年8月
the architecture and to describe what is required of each entity in order for the proposed system to work properly. The following sections identify three different types of entities within this architecture: users and user agents, organizational notaries, and certification authorities. For each class of entity we describe the (electronic and paper) procedures which the entity must execute as part of the architecture and what responsibilities the entity assumes as a function of its role in the architecture. Note that the infrastructure described here applies to the situation wherein RSADSI acts as a co-issuer of certificates, sharing the role of certification authority as described later. Other certifying authority arrangements may employ different procedures and are not addressed by this RFC.
そして、アーキテクチャ、提案されたシステムが適切に扱うように各実体が何に要求されるかを説明するために。 以下のセクションはこのアーキテクチャの中で3つの異なったタイプの実体を特定します: ユーザ、ユーザエージェント、組織的な公証人、および証明当局。 それぞれのクラスの実体のために、私たちはアーキテクチャの一部と実体がアーキテクチャでの役割の機能としてどんな責任を負うかとして実体が実行しなければならない(電子と紙)の手順について説明します。 ここで説明されたインフラストラクチャがRSADSIが証明書の共同発行人として機能させる状況に適用されることに注意してください、証明権威の役割を後述のように共有して。 他の公認している権威アレンジメントは、異なった手順を使うかもしれなくて、このRFCによって扱われません。
3.3.1 Users and User Agents
3.3.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 handling." UAs exchange messages by calling on a supporting Message Transfer Service (MTS).
用語Userエージェント(UA)はCCITT X.400 Message Handling Systems(MHS)推薦から連れて行かれます:(推薦は以下の通りそれを定義します)。 「メッセージハンドリングの文脈、機能目標、MHSの部品。」部品によって、独身のダイレクトユーザはメッセージハンドリングに従事しています。 UAsは、サポートMessage Transfer Service(MTS)を訪問することによって、メッセージを交換します。
A UA process supporting privacy-enhanced mail processing must protect the private component of its associated entity (ordinarily, a human user) from disclosure. We anticipate that a user will employ ancillary software (not otherwise associated with the UA) to generate his public/private component pair and to compute the (one-way) message hash required by the registration procedure. The public component, along with information that identifies the user, will be transferred to an organizational notary (see below) for inclusion in an order to an issuer. The process of generating public and private components is a local matter, but we anticipate Internet-wide distribution of software suitable for component-pair generation to facilitate the process. The mechanisms used to transfer the public component and the user identification information must preserve the integrity of both quantities and bind the two during this transfer.
プライバシーで高められたメールが処理であるとサポートするUAプロセスが関連実体の個人的なコンポーネントを保護しなければならない、(通常、人間のユーザ) 公開から。 私たちは、ユーザが彼の公共の、または、私設のコンポーネント組を生成して、登録手順によって必要とされた(一方向)のメッセージハッシュを計算するのに、付属のソフトウェア(そうでなければ、UAには、交際しない)を使うと予期します。 発行人へのオーダーでの包含のためにユーザを特定する情報と共に組織的な公証人(以下を見る)に公共のコンポーネントを移すでしょう。 公共の、そして、個人的なコンポーネントを生成するプロセスは地域にかかわる事柄ですが、私たちは、プロセスを容易にするためにコンポーネント組世代に適したソフトウェアのインターネット広範な分布を予期します。 メカニズムが以前はよく公共のコンポーネントを移していて、ユーザ登録名情報は、両方の量の保全を保持して、この転送の間、2を縛らなければなりません。
This proposal establishes two ways in which a user may order a certificate, i.e., through the user's affiliation with an organization or directly through RSADSI. In either case, a user will be required to send a paper order to RSADSI on a form described in a subsequent RFC and containing the following information:
この提案はユーザが証明書を注文するかもしれない2つの方法を確立します、すなわち、組織かRSADSI直接を通したユーザの提携で。 どちらの場合ではも、ユーザがその後のRFCで説明されて、以下の情報を含むフォームで紙の注文をRSADSIに送るのに必要でしょう:
1. Distinguished Name elements (e.g., full legal name,
organization name, etc.)
1. 顕著なName要素(例えば、完全な法的な名前、組織名など)
2. Postal address
2. 郵便の宛先
Kent & Linn [Page 8] RFC 1114 Mail Privacy: Key Management August 1989
ケントとリン[8ページ]RFC1114はプライバシーを郵送します: Key Management1989年8月
3. Internet electronic mail address
3. インターネット電子メールアドレス
4. A message hash function, binding the above information to the
user's public component
4. ユーザの公共のコンポーネントに上記の情報を縛るメッセージハッシュ関数
Note that the user's public component is NOT transmitted via this paper path. In part the rationale here is that the public component consists of many (>100) digits and thus is prone to error if it is copied to and from a piece of paper. Instead, a message hash is computed on the identifying information and the public component and this (smaller) message hash value is transmitted along with the identifying information. Thus the public component is transferred only via an electronic path, as described below.
ユーザの公共のコンポーネントがこの用紙搬送路を通って伝えられないことに注意してください。 ここの原理は、一部、公共のコンポーネントが多くの(>100)ケタから成るということであり、その結果、それが紙と1枚の紙からコピーされるなら、誤りに傾向があります。 代わりに、メッセージハッシュは身元が分かる情報と公共のコンポーネントで計算されます、そして、この(より小さい)のメッセージハッシュ値は身元が分かる情報と共に伝えられます。 したがって、以下で説明されるように電子経路を通してだけ公共のコンポーネントを移します。
If the user is not affiliated with an organization which has established its own "electronic notary" capability (an organization notary or "ON" as discussed in the next section), then this paper registration form must be notarized by a Notary Public. If the user is affiliated with an organization which has established one or more ONs, the paper registration form need not carry the endorsement of a Notary Public. Concurrent with the paper registration, the user must send the information outlined above, plus his public component, either to his ON, or directly to RSADSI if no appropriate ON is available to the user. Direct transmission to RSADSI of this information will be via electronic mail, using a representation described in a subsequent RFC. The paper registration must be accompanied by a check or money order for $25 or an organization may establish some other billing arrangement with RSADSI. The maximum (and default) lifetime of a certificate ordered through this process is two years.
ユーザがそれ自身の「電子公証人」能力(次のセクションで議論する組織の公証人か“ON")を確立した組織に所属しないなら、公証人はこの紙の登録用紙を公証しなければなりません。 ユーザが1ONsを設立した組織に所属するなら、紙の登録用紙はNotary Publicの裏書きを運ぶ必要はありません。 紙の登録で同時発生であり、ユーザには、どんな適切なONも利用可能でないなら、ユーザは彼のON、または、直接RSADSIへの上に概説された情報、および彼の公共のコンポーネントを送らなければなりません。 その後のRFCで説明された表現を使用して、電子メールを通してこの情報のRSADSIへの直線伝動があるでしょう。 25ドルでチェックか為替で紙の登録に伴わなければならない、さもなければ、組織はRSADSIとのある他の支払いアレンジメントを確立するかもしれません。 このプロセスを通して注文された証明書の最大(デフォルトとする)の寿命は2年です。
The transmission of ID information and public component from a user to his ON is a local matter, but we expect electronic mail will also be the preferred approach in many circumstances and we anticipate general distribution of software to support this process. Note that it is the responsibility of the user and his organization to ensure the integrity of this transfer by some means deemed adequately secure for the local computing and communication environment. There is no requirement for secrecy in conjunction with this information transfer, but the integrity of the information must be ensured.
ユーザから彼のONまでのID情報と公共のコンポーネントの送信は地域にかかわる事柄ですが、私たちはまた、電子メールが多くの事情で好ましい方法になって、このプロセスをサポートするためにソフトウェアの全般的な分布を予期すると予想します。 ローカルのコンピューティングと通信環境に安全であるとどうでも適切に考えられたこの転送の保全を確実にするのが、ユーザと彼の組織の責任であることに注意してください。 秘密保持のための要件は全くこの情報転送に関連していませんが、情報の保全を確実にしなければなりません。
3.3.2 Organizational Notaries
3.3.2 組織的な公証人
An organizational notary is an individual who acts as a clearinghouse for certificate orders originating within an administrative domain such as a corporation or a university. An ON represents an organization or organizational unit (in X.500 naming terms), and is assumed to have some independence from the users on whose behalf
組織的な公証人は会社か大学などの管理ドメインの中で起因する証明書命令のための情報センターとして務める個人です。 ONは組織か組織的なユニット(用語を命名するX.500の)を代表して、に代わってユーザからの何らかの独立を持っていると思われます。
Kent & Linn [Page 9] RFC 1114 Mail Privacy: Key Management August 1989
ケントとリン[9ページ]RFC1114はプライバシーを郵送します: Key Management1989年8月
certificates are ordered. An ON will be restricted through mechanisms implemented by the issuing authority, e.g., RSADSI, to ordering certificates properly associated with the domain of that ON. For example, an ON for BBN should not be able to order certificates for users affiliated with MIT or MITRE, nor vice versa. Similarly, if a corporation such as BBN were to establish ONs on a per- subsidiary basis (corresponding to organization units in X.500 naming parlance), then an ON for the BBN Communications subsidiary should not be allowed to order a certificate for a user who claims affiliation with the BBN Software Products subsidiary.
証明書は注文されます。 ONは発行機関によって実装されたメカニズムを通して制限されるでしょう、例えば、RSADSI、適切にそのONのドメインに関連している証明書を注文するのに。 例えば、BBNのためのONはMITかMITREに所属するユーザのために証明書を注文できないはずです、そして、逆もまた同様です。 同様に、BBNなどの会社がaであるならaにONsを設立することになっていた、-、補助の基礎(組織部隊に話法を命名するX.500で対応する)、そして、BBN Communications子会社のためのONはBBNソフト製品子会社による提携を要求するユーザのために証明書を注文できないはずです。
It can be assumed that the set of ONs changes relatively slowly and that the number of ONs is relatively small in comparison with the number of users. Thus a more extensive, higher assurance process may reasonably be associated with ON accreditation than with per-user certificate ordering. Restrictions on the range of information which an ON is authorized to certify are established as part of this more elaborate registration process. The procedures by which organizations and organizational units are established in the RSADSI database, and by which ONs are registered, will be described in a subsequent RFC.
ONsのセットが比較的ゆっくり変化して、ONsの数がユーザの数との比較で比較的少ないと思うことができます。 したがって、より大規模で、注文されるユーザー証明書より高い保証プロセスは合理的にON認可に関連しているかもしれません。 ONが公認するのが認可される情報の範囲における制限はこのより入念な登録手続の一部と書き立てられます。 組織と組織的なユニットがRSADSIデータベースに確立されて、ONsが示される手順、その後のRFCでは、説明されるでしょう。
An ON is responsible for establishing the correctness and integrity of information incorporated in an order, and will generally vouch for (certify) the accuracy of identity information at a granularity finer than that provided by a Notary Public. We do not believe that it is feasible to enforce uniform standards for the user certification process across all ONs, but we anticipate that organizations will endeavor to maintain high standards in this process in recognition of the "visibility" associated with the identification data contained in certificates. An ON also may constrain the validity period of an ordered certificate, restricting it to less than the default two year interval imposed by the RSADSI license agreement.
ONはオーダーに組み込んでいる情報の正当性と保全を確立するのに責任があって、一般に、Notary Publicによるそれが提供されたよりすばらしい粒状でアイデンティティ情報の精度を保証するでしょう(公認します)。 すべてのONsの向こう側にユーザ証明の過程の一定の規格を実施するのが可能であると信じていませんが、私たちは、組織が、「目に見えること」の認識におけるこの過程による高い規格を証明書に含まれている識別情報に関連しているのに維持するよう努力すると予期します。 ONも規則正しい証明書の有効期間を抑制するかもしれません、それを以下に制限してRSADSI許諾契約で課されたデフォルトの2年間の間隔より。
An ON participates in the certificate ordering process by accepting and validating identification information from a user and forwarding this information to RSADSI. The ON accepts the electronic ordering information described above (Distinguished Name elements, mailing address, public component, and message hash computed on all of this data) from a user. (The representation for user-to-ON transmission of this data is a local matter, but we anticipate that the encoding specified for ON-to-RSADSI representation of this data will often be employed.) The ON sends an integrity-protected (as described in RFC-1113) electronic message to RSADSI, vouching for the correctness of the binding between the public component and the identification data. Thus, to support this function, each ON will hold a certificate as an individual user within the organization which he represents. RSADSI will maintain a database which identifies the
RSADSIに受け入れて、ユーザからの識別情報を有効にして、この情報を転送することによって、ONは証明書注文過程に参加します。 ONはユーザから上で説明された電子注文情報(このデータのすべてで計算されたアドレス、公共のコンポーネント、およびメッセージ細切れ肉料理を郵送して、Name要素を区別する)を受け入れます。 (ユーザからONへのこのデータの伝達の表現は地域にかかわる事柄ですが、私たちは、ONからRSADSIへのこのデータの表現に指定されたコード化がしばしば使われると予期します。) ONは保全で保護された(RFC-1113で説明されるように)電子メッセージをRSADSIに送ります、公共のコンポーネントと識別情報の間の結合の正当性を保証して。 したがって、この機能をサポートするために、各ONは個々のユーザとして彼が代表する組織の中で証明書を所持するでしょう。 RSADSIがデータベースを維持する、どれ、特定
Kent & Linn [Page 10] RFC 1114 Mail Privacy: Key Management August 1989
ケントとリン[10ページ]RFC1114はプライバシーを郵送します: Key Management1989年8月
users who also act as ONs and the database will specify constraints on credentials which each ON is authorized to certify. The electronic mail representation for a user's certificate data in an ON message to RSADSI will be specified in a subsequent RFC.
また、ONsとデータベースとして務めるユーザが各ONが公認するのが認可される信任状で規制を指定するでしょう。 RSADSIへのONメッセージのユーザの証明書データの電子メール表現はその後のRFCで指定されるでしょう。
3.3.3 Certification Authorities
3.3.3 証明当局
In X.509 the term "certification authority" is defined as "an authority trusted by one or more users to create and assign certificates". This alternate expansion for the acronym "CA" is roughly equivalent to that contemplated as a "central authority" in RFC-1040 and RFC-1113. The only difference is that in X.509 there is no requirement that a CA be a distinguished entity or that a CA serve a large number of users, as envisioned in these RFCs. Rather, any user who holds a certificate can, in the X.509 context, act as a CA for any other user. As noted above, we have chosen to restrict the role of CA in this electronic mail environment to organizational entities, to simplify the certificate validation process, to impose semantics which support organizational affiliation as a basis for certification, and to facilitate license accountability.
X.509では、「証明権威」という用語は「証明書を作成して、割り当てると1人以上のユーザによって信じられた権威」と定義されます。 頭文字語のためのこの交互の拡大「カリフォルニア」はおよそRFC-1040とRFC-1113の「主要な権威」として熟考されたそれに同等です。 唯一の違いはカリフォルニアが顕著な実体であるかカリフォルニアが多くのユーザに役立つという要件が全くX.509では、ないということです、これらのRFCsで思い描かれるように。 むしろ、X.509文脈では、証明書を所持するどんなユーザもいかなる他のユーザのためのカリフォルニアとしても務めることができます。 上で述べたように、私たちは、組織的な実体へのこの電子メール環境におけるカリフォルニアの役割を制限して、証明書合法化の過程を簡素化して、意味論を課すのを選びました(証明、ライセンス責任を容易にする基礎として組織的な所属を支持します)。
In the proposed architecture, individuals who are affiliated with (registered) organizations will go through the process described above, in which they forward their certificate information to their ON for certification. The ON will, based on local procedures, verify the accuracy of the user's credentials and forward this information to RSADSI using privacy-enhanced mail to ensure the integrity and authenticity of the information. RSADSI will carry out the actual certificate generation process on behalf of the organization represented by the ON. Recall that it is the identity of the organization which the ON represents, not the ON's identity, which appears in the issuer field of the user certificate. Therefore it is the private component of the organization, not the ON, which is used to sign the user certificate.
提案された構造では、組織に所属する(登録されます)個人は上で説明された過程に直面するでしょう。(それらは証明のためにそれで自己の証明書情報を自己のONに転送します)。 ローカルの手順に基づいて、ONは、情報の保全と信憑性を確実にするのにプライバシーで高められたメールを使用することでユーザの信任状の精度について確かめて、この情報をRSADSIに転送するでしょう。 RSADSIはONによって代表された組織を代表して実際の証明書発生経過を行うでしょう。 それがONのアイデンティティではなく、ONが表す組織のアイデンティティであると思い出してください。(それは、ユーザー証明書の発行人分野に現れます)。 したがって、それはONではなく、組織の個人的なコンポーネントです。(ONは、ユーザー証明書にサインするのに使用されます)。
In order to carry out this procedure RSADSI will serve as the repository for the private components associated with certificates representing organizations or organizational units (but not individuals). In effect the role of CA will be shared between the organizational notaries and RSADSI. This shared role will not be visible in the syntax of the certificates issued under this arrangement nor is it apparent from the validation procedure one applies to these certificates. In this sense, the role of RSADSI as the actual signer of certificates on behalf of organizations is transparent to this aspect of system operation.
この手順を行うために、RSADSIは組織を代表する証明書に関連している個人的なコンポーネントか組織的なユニット(しかし、個人でない)倉庫として機能するでしょう。 事実上カリフォルニアの役割は組織的な公証人とRSADSIの間で共有されるでしょう。 この共有された役割はこのアレンジメントで発行された証明書の構文で目に見えないでしょう、そして、それは1つがこれらの証明書に適用する合法化手順から明らかではありません。 この意味で、組織を代表した証明書の実際の署名者としてのRSADSIの役割はシステム・オペレーションのこの局面に透明です。
If an organization were to carry out the certificate signing process locally, and thus hold the private component associated with its
組織が、局所的に証明書サインアップ過程を行って、その結果、個人的なコンポーネントが交際するままにするつもりであった、それ
Kent & Linn [Page 11] RFC 1114 Mail Privacy: Key Management August 1989
ケントとリン[11ページ]RFC1114はプライバシーを郵送します: Key Management1989年8月
organization certificate, it would need to contact RSADSI to discuss security safeguards, special legal agreements, etc. A number of requirements would be imposed on an organization if such an approach were persued. The organization would be required to execute additional legal instruments with RSADSI, e.g., to ensure proper accounting for certificates generated by the organization. Special software will be required to support the certificate signing process, distinct from the software required for an ON. Stringent procedural, physical, personnel and computer security safeguards would be required to support this process, to maintain a relatively high level of security for the system as a whole. Thus, at this time, it is not recommended that organizations pursue this approach although local certificate generation is not expressly precluded by the proposed architecture.
組織が証明する、それは、安全予防手段、特別な法的な協定などについて議論するためにRSADSIに連絡する必要があるでしょう。 そのようなアプローチがpersuedされるなら、多くの要件が組織に課されるでしょうに。 組織は、RSADSIと共に追加法律文書を実行して、例えば組織によって作られた証明書のための適切な会計を確実にしなければならないでしょう。 特別なソフトウェアが、ONに必要であるソフトウェアと異なった証明書サインアップ過程を支持するのに必要でしょう。 厳しい手続き上的、そして、物理的な人員とコンピュータセキュリティ安全装置は、この過程を支持して、全体でシステムのために比較的高いレベルのセキュリティを維持しなければならないでしょう。 このようにしてと、このとき、地方の証明書世代が提案された構造によって明白に排除されませんが、組織がこのアプローチを追求することが勧められません。
RSADSI has offered to operate a service in which it serves as a CA for users who are not affiliated with any organization or who are affiliated with an organization which has not opted to establish an organizational notary. To distinguish certificates issued to such "non-affiliated" users the distinguished string "Notary" will appear as the organizational unit name of the issuer of the certificate. This convention will be employed throughout the system. Thus not only RSADSI but any other organization which elects to provide this type of service to non-affiliated users may do so in a standard fashion. Hence a corporation might issue a certificate with the "Notary" designation to students hired for the summer, to differentiate them from full-time employees. At least in the case of RSADSI, the standards for verifying user credentials that carry this designation will be well known and widely recognized (e.g., Notary Public endorsement).
RSADSIは、組織的な公証人を証明するためにそれがどんな組織にも所属しないか、または選ばれていない組織に所属するユーザのためのカリフォルニアとして機能するサービスを操作すると申し出ました。 そのような「非系列」のユーザに発行された証明書を区別するために、顕著なストリング「公証人」は証明書の発行人の組織的なユニット名として現れるでしょう。 このコンベンションはシステム中で使われるでしょう。 したがって、RSADSIだけではなく、非系列のユーザに対するこのタイプのサービスを提供するのを選ぶいかなる他の組織も一般的なファッションでそうするかもしれません。 したがって、会社は「公証人」名称で常勤者と彼らを区別するために夏に雇われた学生に証明書を下付するかもしれません。 少なくともRSADSIの場合では、この名称を載せるユーザ信任状について確かめる規格は、よく知られて、広く認識されるでしょう(例えば、Notary Public裏書き)。
To illustrate this convention, consider the following examples. Employees of RSADSI will hold certificates which indicate "RSADSI" as the organization in both the issuer field and the subject field, perhaps with no organizational unit specified. Certificates obtained directly from RSADSI, by user's who are not affiliated with any ON, will also indicate "RSADSI" as the organization and will specify "Notary" as an organizational unit in the issuer field. However, these latter certificates will carry some other designation for organization (and, optionally, organizational unit) in the subject field. Moreover, an organization designated in the subject field for such a certificate will not match any for which RSADSI has an ON registered (to avoid possible confusion).
このコンベンションを例証するには、以下の例を考えてください。 RSADSIの従業員は組織として発行人分野と対象の分野の両方で"RSADSI"を示す証明書を保持するでしょう、恐らくどんな組織的なユニットも指定されていない状態で。 また、組織とウィルが組織的なユニットとして発行人分野で「公証人」を指定するとき、"RSADSI"は、直接RSADSIから証明書を入手して、ユーザのもので、だれがいるかがどんなONにも合併しなかったのを示すでしょう。 しかしながら、これらの後者の証明書は組織(そして、任意に組織的なユニット)のために対象の分野にある他の名称を載せるでしょう。 そのうえ、そのような証明書のために対象の分野で指定された組織はRSADSIがONを登録させる(可能な混乱を避ける)いずれにも合わないでしょう。
In all cases described above, when a certificate is generated RSADSI will send a paper reply to the ordering user, including two message hash functions:
全部で、証明書が発生しているRSADSIであることの上で説明されたケースは紙の回答を注文しているユーザに送るでしょう、2つのメッセージハッシュ関数を含んでいて:
Kent & Linn [Page 12] RFC 1114 Mail Privacy: Key Management August 1989
ケントとリン[12ページ]RFC1114はプライバシーを郵送します: Key Management1989年8月
1. a message hash computed on the user's identifying information
and public component (and sent to RSADSI in the registration
process), to guarantee its integrity across the ordering
process, and
そして1. 注文過程の向こう側に保全を保証するためにユーザの身元が分かる情報と公共のコンポーネント(そして、登録手続でRSADSIに発信する)の上で計算されたメッセージ細切れ肉料理。
2. a message hash computed on the public component of RSADSI, to
provide independent authentication for this public component
which is transmitted to the user via email (see below).
2. メッセージ細切れ肉料理は、メールでユーザに伝えられるこの公共のコンポーネントのための独立している認証を提供するためにRSADSIの公共の部品の上で計算されました(以下を見てください)。
RSADSI will send to the user via electronic mail (not privacy enhanced) a copy of his certificate, a copy of the organization certificate identified in the issuer field of the user's certificate, and the public component used to validate certificates signed by RSADSI. The "issuer" certificate is included to simplify the validation process in the absence of a user-level directory system; its distribution via this procedure will probably be phased out in the future. Thus, as described in RFC-1113, the originator of a message is encouraged, though not required, to include his certificate, and that of its issuer, in the privacy enhanced message header (X-Issuer-Certificate) to ensure that each recipient can process the message using only the information contained in this header. The organization (organizational unit) identified in the subject field of the issuer certificate should correspond to that which the user claims affiliation (as declared in the subject field of his certificate). If there is no appropriate correspondence between these fields, recipients ought to be suspicious of the implied certification path. This relationship should hold except in the case of "non-affiliated" users for whom the "Notary" convention is employed.
RSADSIは彼の証明書のコピー、ユーザの証明書の発行人分野で特定された組織証明書のコピー、および公共のコンポーネントがRSADSIによってサインされた証明書を有効にするのに使用した電子メール(高められなかったどんなプライバシーも)を通ってユーザに発信するでしょう。 「発行人」証明書はユーザレベルディレクトリシステムがないとき合法化の過程を簡素化するために含まれています。 この手順を通した分配は将来、たぶん段階的に廃止されるでしょう。 したがって、メッセージの創始者はRFC-1113で説明されるように奨励されます、各受取人がこのヘッダーに含まれた情報だけを使用することでメッセージを処理できるのを保証するのにプライバシーの高められたメッセージヘッダー(X発行人証明書)に彼の証明書、および発行人のものを含むのが必要ではありませんが。 発行人証明書の対象の分野で特定された組織(組織的なユニット)はユーザが提携であると主張するそれに対応するべきです(彼の証明書の対象の分野で宣言されるように)。 これらの分野の間には、どんな適切な通信もなければ、受取人は暗示している証明経路で不審に思っているべきです。 「公証人」コンベンションが採用している「非系列」のユーザのケースを除いて、この関係は成立するべきです。
In contrast, the issuer field of the issuer's certificate will specify "RSADSI" as the organization, i.e., RSADSI will certify all organizational certificates. This convention allows a recipient to validate any originator's certificate (within the RSADSI certification hierarchy) in just two steps. Even if an organization establishes a certification hierarchy involving organizational units, certificates corresponding to each unit can be certified both by RSADSI and by the organizational entity immediately superior to the unit in the hierarchy, so as to preserve this short certification path feature. First, the public component of RSADSI is employed to validate the issuer's certificate. Then the issuer's public component is extracted from that certificate and is used to validate the originator's certificate. The recipient then extracts the originator's public component for use in processing the X-Mic-Info field of the message (see and RFC-1113).
対照的に、発行人の証明書の発行人分野は組織として"RSADSI"を指定するでしょう、すなわち、RSADSIはすべての組織的な証明書を公認するでしょう。 このコンベンションで、受取人はちょうど2ステップでどんな創始者の証明書も有効にすることができます(RSADSI証明階層構造の中で)。 組織が組織的なユニットにかかわる証明階層構造を確立しても、RSADSIとすぐにユニットより階層構造に優れた組織的な実体で各ユニットに対応する証明書を公認できます、この短い証明経路機能を保存するために。 まず最初に、RSADSIの公共の部品は、発行人の証明書を有効にするのに使われます。 次に、発行人の公共のコンポーネントは、その証明書から抽出されて、創始者の証明書を有効にするのに使用されます。 そして、次に、受取人がメッセージのXミックインフォメーション分野を処理することにおける使用のために創始者の公共のコンポーネントを抽出する、(見る、RFC-1113)
The electronic representation used for transmission of the data items described above (between an ON and RSADSI) will be contained in a
上(ONとRSADSIの間で)で説明されたデータ項目の送信に使用される電子表現はaに含まれるでしょう。
Kent & Linn [Page 13] RFC 1114 Mail Privacy: Key Management August 1989
ケントとリン[13ページ]RFC1114はプライバシーを郵送します: Key Management1989年8月
subsequent RFC. To verify that the registration process has been successfully completed and to prepare for exchange of privacy- enhanced electronic mail, the user should perform the following steps:
その後のRFC。 登録手続が首尾よく完成したことを確かめて、プライバシーの高められた電子メールの交換の用意をするために、ユーザは以下のステップを実行するべきです:
1. extract the RSADSI public component, the issuer's certificate
and the user's certificate from the message
1. メッセージからRSADSIの公共の部品、発行人の証明書、およびユーザの証明書を抜粋してください。
2. compute the message hash on the RSADSI public component and
compare the result to the corresponding message hash that was
included in the paper receipt
2. RSADSIの公共の部品の上のメッセージ細切れ肉料理を計算してください、そして、紙の領収書に含まれていた対応するメッセージ細切れ肉料理と結果を比較してください。
3. use the RSADSI public component to validate the signature on
the issuer's certificate (RSADSI will be the issuer of this
certificate)
3. RSADSIの公共の部品を使用して、発行人の証明書の上に署名を有効にしてください。(RSADSIはこの証明書の発行人になるでしょう)
4. extract the organization public component from the validated
issuer's certificate and use this public component to
validate the user certificate
4. 有効にされた発行人の証明書から組織の公共のコンポーネントを抽出してください、そして、この公共のコンポーネントを使用して、ユーザー証明書を有効にしてください。
5. extract the identification information and public component
from the user's certificate, compute the message hash on it
and compare the result to the corresponding message hash
value transmitted via the paper receipt
5. ユーザの証明書から識別情報と公共のコンポーネントを抜粋してください、そして、それでメッセージ細切れ肉料理を計算してください、そして、紙の領収書で伝えられた対応するメッセージハッシュ値に結果をたとえてください。
For a user whose order was processed via an ON, successful completion of these steps demonstrates that the certificate issued to him matches that which he requested and which was certified by his ON. It also demonstrates that he possesses the (correct) public component for RSADSI and for the issuer of his certificate. For a user whose order was placed directly with RSADSI, this process demonstrates that his certificate order was properly processed by RSADSI and that he possesses the valid issuer certificate for the RSADSI Notary. The user can use the RSADSI public component to validate organizational certificates for organizations other than his own. He can employ the public component associated with his own organization to validate certificates issued to other users in his organization.
注文がONを通して処理されたユーザに関しては、これらのステップの無事終了は、彼に発行された証明書が彼が要求して、彼のONによって公認されたそれに合っているのを示します。 また、彼にはRSADSIと彼の証明書の発行人のための(正しい)の公共のコンポーネントがあるのは示されます。 注文が直接RSADSIに出されたユーザに関しては、この過程は彼の証明書注文がRSADSIによって適切に処理されて、彼にはRSADSI Notaryに、有効な発行人証明書があるのを示します。 ユーザは、彼自身のを除いた組織のための組織的な証明書を有効にするのにRSADSIの公共の部品を使用できます。 彼は、彼の組織で他のユーザに発行された証明書を有効にするのに彼自身の組織に関連している公共のコンポーネントを使うことができます。
3.3.3.1 Interoperation Across Certification Hierarchy Boundaries
3.3.3.1 証明階層構造限界の向こう側のInteroperation
In order to accommodate interoperation with other certification authorities, e.g., foreign or U.S. government CAs, two conventions will be adopted. First, all certifying authorities must agree to "cross-certify" one another, i.e., each must be willing to sign a certificate in which the issuer is that certifying authority and the subject is another certifying authority. Thus, RSADSI might generate a certificate in which it is identified as the issuer and a certifying authority for the U.S. government is indentified as the
他の証明当局、例えば、外国の、または、米国の政府CAsとinteroperationを収容するために、2つのコンベンションが採用されるでしょう。 まず最初に、当局を皆、公認するのは、お互いを「十字で公認すること」に同意しなければなりません、すなわち、それぞれが、権威を公認しながら、発行人がそれである権威と対象を公認する証明書にサインするのが、別のものであることを望んでいるに違いありません。 したがって、RSADSIはそれが米国政府のための発行人と公認権威としてindentifiedされるように特定される証明書を作るかもしれません。
Kent & Linn [Page 14] RFC 1114 Mail Privacy: Key Management August 1989
ケントとリン[14ページ]RFC1114はプライバシーを郵送します: Key Management1989年8月
subject. Conversely, that U.S. government certifying authority would generate a certificate in which it is the issuer and RSADSI is the subject. This cross-certification of certificates for "top-level" CAs establishes a basis for "lower level" (e.g., organization and user) certificate validation across the hierarchy boundaries. This avoids the need for users in one certification hierarchy to engage in some "out-of-band" procedure to acquire a public-key for use in validating certificates from a different certification hierarchy.
受けることがある。 逆に、権威を公認するその米国政府がそれが発行人であり、RSADSIが対象である証明書を作るでしょう。 「トップレベル」CAsのための証明書のこの相互認証は階層構造限界の向こう側に「下のレベル」(例えば、組織とユーザ)証明書合法化の基礎を確立します。 これは1つの証明階層構造のユーザが証明書を有効にすることにおける使用のために異なった証明階層構造から公開カギを取得することを「バンドの外」という何らかの手順に約束する必要性を避けます。
The second convention is that more than one X-Issuer-Certificate field may appear in a privacy-enhanced mail header. Multiple issuer certificates can be included so that a recipient can more easily validate an originator's certificate when originator and recipient are not part of a common CA hierarchy. Thus, for example, if an originator served by the RSADSI certification hierarchy sends a message to a recipient served by a U.S. government hierarchy, the originator could (optionally) include an X-Issuer-Certificate field containing a certificate issued by the U.S. government CA for RSADSI. In this fashion the recipient could employ his public component for the U.S. government CA to validate this certificate for RSADSI, from which he would extract the RSADSI public component to validate the certificate for the originator's organization, from which he would extract the public component required to validate the originator's certificate. Thus, more steps can be required to validate certificates when certification hierarchy boundaries are crossed, but the same basic procedure is employed. Remember that caching of certificates by UAs can significantly reduce the effort required to process messages and so these examples should be viewed as "worse case" scenarios.
2番目のコンベンションは1つ以上のX発行人証明書野原がプライバシーで高められたメールヘッダに現れるかもしれないということです。 創始者と受取人が一般的なカリフォルニア階層構造の一部でないときに、受取人が、より容易に創始者の証明書を有効にすることができるように、複数の発行人証明書を含むことができます。 このようにして、例えば、RSADSI証明階層構造によって役立たれる創始者が米国政府階層構造によって役立たれる受取人にメッセージを送るなら、創始者は(任意に)RSADSIのために米国政府カリフォルニアによって発行された証明書を含むX発行人証明書分野を入れるかもしれません。 米国政府カリフォルニアが彼が彼が創始者の証明書を有効にしなければならなかった公共のコンポーネントを抽出するだろう創始者の組織のための証明書を有効にするためにRSADSIの公共の部品を抽出するだろうRSADSIのためのこの証明書を有効にするのにこんなやり方で受取人は彼の公共のコンポーネントを使うことができました。 証明階層構造限界が交差しているとき、したがって、証明書を有効にするために、より多くのステップを必要とすることができますが、同じ基本的な手順は採用しています。 UAsによる証明書のキャッシュがこれらの例が「より悪いケース」シナリオとして見なされるべきであるためにメッセージを処理するのに必要である努力をかなり抑えることができるのを覚えていてください。
3.3.3.2 Certificate Revocation
3.3.3.2 証明書取消し
X.509 states that it is a CA's responsibility to maintain:
X.509は、それが維持するCAの責任であると述べます:
1. a time-stamped list of the certificates it issued which have
been revoked
1. それが発行した取り消された証明書の時間で押し込まれたリスト
2. a time-stamped list of revoked certificates representing
other CAs
2. 他のCAsを表す取り消された証明書の時間で押し込まれたリスト
There are two primary reasons for a CA to revoke a certificate, i.e., suspected compromise of a secret component (invalidating the corresponding public component) or change of user affiliation (invalidating the Distinguished Name). As described in X.509, "hot listing" is one means of propagating information relative to certificate revocation, though it is not a perfect mechanism. In particular, an X.509 Revoked Certificate List (RCL) indicates only the age of the information contained in it; it does not provide any
ユーザ提携のカリフォルニアが証明書、すなわち、秘密のコンポーネント(対応する公共のコンポーネントを無効にする)の疑われた妥協を取り消すか、または変化する2つの第一の理由があります(Distinguished Nameを無効にして)。 X.509で説明されるように、「熱いリスト」は証明書取消しに比例して情報を伝播する1つの手段です、それが完全なメカニズムではありませんが。 特に、X.509 Revoked Certificate List(RCL)はそれに含まれた情報の時代だけを示します。 それはいずれも提供しません。
Kent & Linn [Page 15] RFC 1114 Mail Privacy: Key Management August 1989
ケントとリン[15ページ]RFC1114はプライバシーを郵送します: Key Management1989年8月
basis for determining if the list is the most current RCL available from a given CA. To help address this concern, the proposed architecture establishes a format for an RCL in which not only the date of issue, but also the next scheduled date of issue is specified. This is a deviation from the format specified in X.509.
リストが与えられたカリフォルニアから利用可能な最も現在のRCLであるかどうか決定する基礎。 この関心を記述するのを助けるために、提案された構造は発行日だけではなく、次の予定されている発行日も指定されるRCLのために形式を確立します。 これはX.509で指定された形式からの逸脱です。
Adopting this convention, when the next scheduled issue date arrives a CA must issue a new RCL, 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 RCLs are issued by that CA. Note that this does not preclude RCL issuance on a more frequent basis, e.g., in case of some emergency, but no Internet-wide mechanisms are architected for alerting users that such an unscheduled issuance has taken place. This scheduled RCL issuance convention allows users (UAs) to determine whether a given RCL is "out of date," a facility not available from the standard RCL format.
次の予定されている問題期日が来るとき、このコンベンションを採用して、カリフォルニアは新しいRCLを発行しなければなりません、エントリーのリストにおける変化が全くなくても。 こんなやり方で各カリフォルニアは、独自に、RCLsがそのカリフォルニアによって発行される頻度を確立して、広告を出すことができます。 これが例えば、より頻繁ベース何らかの非常時の場合にRCL発行を排除しませんが、どんなインターネット全体のメカニズムもそのような予定外の発行が行われたとユーザに警告するためにarchitectedされないことに注意してください。 ユーザ(UAs)は、この予定されているRCL発行コンベンションで与えられたRCLが「時代遅れであるかどうか」と決心できます、標準のRCL形式から利用可能でない施設。
A recent (draft) version of the X.509 recommendation calls for each RCL to contain the serial numbers of certificates which have been revoked by the CA administering that list, i.e., the CA that is identified as the issuer for the corresponding revoked certificates. Upon receipt of a RCL, a UA should compare the entries against any cached certificate information, deleting cache entries which match RCL entries. (Recall that the certificate serial numbers are unique only for each issuer, so care must be exercised in effecting this cache search.) The UA should also retain the RCL to screen incoming messages to detect use of revoked certificates carried in these message headers. More specific details for processing RCL are beyond the scope of this RFC as they are a function of local certificate management techniques.
X.509推薦の最近の(草稿)バージョンは、各RCLがすなわち、そのリストを管理する対応のための発行人が証明書を取り消したので特定されるカリフォルニア(カリフォルニア)によって取り消された証明書の通し番号を含むように求めます。 RCLを受け取り次第、UAはどんなキャッシュされた証明書情報に対してエントリーを比較するはずです、RCLエントリーに合っているキャッシュエントリーを削除して。 (このキャッシュ検索に作用するのに注意を訓練しなければならないために各発行人だけに、証明書通し番号がユニークであると思い出してください。) また、UAは、これらのメッセージヘッダーで運ばれた取り消された証明書の使用を検出する入力メッセージを上映するためにRCLを保有するはずです。 処理RCLのための、より特定の詳細は、それらがローカルの証明書管理技術の機能であるので、このRFCの範囲を超えています。
In the architecture defined by this RFC, a RCL will be maintained for each CA (organization or organizational unit), signed using the private component of that organization (and thus verifiable using the public component of that organization as extracted from its certificate). The RSADSI Notary organizational unit is included in this collection of RCLs. CAs operated under the auspices of the U.S. government or foreign CAs are requested to provide RCLs conforming to these conventions, at least until such time as X.509 RCLs provide equivalent functionality, in support of interoperability with the Internet community. An additional, "top level" RCL, will be maintained by RSAD-SI, and should be maintained by other "top level" CAs, for revoked organizational certificates.
このRFCによって定義された構造では、RCLはその組織の個人的なコンポーネントを使用することでサインされた各カリフォルニア(組織か組織的なユニット)に維持されるでしょう(その結果、証明可能な使用は証明書から抽出されるその組織の公共のコンポーネントをそうします)。 RSADSI Notaryの組織的なユニットはRCLsのこの収集に含まれています。 米国政府の前兆で操作されたCAsか外国CAsがこれらのコンベンションに従うRCLsを提供するよう要求されています、少なくともX.509 RCLsが同等な機能性を提供することインターネットコミュニティがある相互運用性を支持したそのような時間まで。 追加していて、「先端平らな」RCL、RSAD-SIによって維持されて、他の「トップレベル」CAsによって維持されるはずです、取り消された組織的な証明書のために。
The hot listing procedure (expect for this top level RCL) will be effected by having an ON from each organization transmit to RSADSI a list of the serial numbers of users within his organization, to be hot listed. This list will be transmitted using privacy-enhanced
各組織からのONに熱くなるように彼の組織の中でユーザの通し番号のリストをRSADSIに伝えさせることによって、熱いリスト手順(このトップレベルRCLのために、予想する)は記載されていた状態で作用するでしょう。 伝えられた使用がプライバシーによって高められたなら、このリストはそうするでしょう。
Kent & Linn [Page 16] RFC 1114 Mail Privacy: Key Management August 1989
ケントとリン[16ページ]RFC1114はプライバシーを郵送します: Key Management1989年8月
mail to ensure authenticity and integrity and will employ representation conventions to be provided in a subsequent RFC. RSADSI will format the RCL, sign it using the private component of the organization, and transmit it to the ON for dissemination, using a representation defined in a subsequent RFC. Means for dissemination of RCLs, both within the administrative domain of a CA and across domain boundaries, are not specified by this proposal. However, it is anticipated that each hot list will also be available via network information center databases, directory servers, etc.
信憑性と保全を確実にするために郵送して、その後のRFCに供給するのに表現コンベンションを使うでしょう。 RSADSIはRCLをフォーマットして、組織の個人的なコンポーネントを使用することでそれにサインして、普及のためにそれをONに伝えるでしょう、その後のRFCで定義された表現を使用して。 RCLsの普及と、カリフォルニアの管理ドメインとドメイン境界の向こう側の手段はこの提案で指定されません。 しかしながら、また、それぞれのホットリストがネットワーク情報センターデータベース、ディレクトリサーバなどで利用可能になると予期されます。
The following ASN.1 syntax, derived from X.509, defines the format of RCLs for use in the Internet privacy enhanced email environment. See the ASN.1 definition of certificates (later in this RFC or in X.509, Annex G) for comparison.
X.509から得られた以下のASN.1構文はインターネットのプライバシーの高められたメール環境における使用のためにRCLsの書式を定義します。 比較のための証明書(このRFCで、より遅いかX.509のAnnex G)のASN.1定義を見てください。
revokedCertificateList ::= SIGNED SEQUENCE {
signature AlgorithmIdentifier,
issuer Name,
list SEQUENCE RCLEntry,
lastUpdate UTCTime,
nextUpdate UTCTime}
revokedCertificateList:、:= サインされた系列署名AlgorithmIdentifier(発行人Name)はSEQUENCE RCLEntry、lastUpdate UTCTime、nextUpdate UTCTimeを記載します。
RCLEntry ::= SEQUENCE {
subject CertificateSerialNumber,
revocationDate UTCTime}
RCLEntry:、:= 系列対象のCertificateSerialNumber、revocationDate UTCTime
3.4 Certificate Definition and Usage
3.4 証明書定義と用法
3.4.1 Contents and Use
3.4.1 コンテンツと使用
A certificate contains the following contents:
証明書は以下のコンテンツを含んでいます:
1. version
1. バージョン
2. serial number
2. 通し番号
3. certificate signature (and associated algorithm identifier)
3. 証明書署名(そして、関連アルゴリズム識別子)
4. issuer name
4. 発行人名
5. validity period
5. 有効期間
6. subject name
6. 対象の名前
7. subject public component (and associated algorithm identifier)
7. 対象の公共のコンポーネント(そして、関連アルゴリズム識別子)
This section discusses the interpretation and use of each of these certificate elements.
このセクションはそれぞれのこれらの証明書要素の解釈と使用について論じます。
Kent & Linn [Page 17] RFC 1114 Mail Privacy: Key Management August 1989
ケントとリン[17ページ]RFC1114はプライバシーを郵送します: Key Management1989年8月
3.4.1.1 Version Number
3.4.1.1 バージョン番号
The version number field is intended to facilitate orderly changes in certificate formats over time. The initial version number for certificates is zero (0).
バージョンナンバーフィールドが時間がたつにつれて証明書形式における秩序だった変化を容易にすることを意図します。 証明書の初期のバージョン番号は(0)ではありません。
3.4.1.2 Serial Number
3.4.1.2 通し番号
The serial number field provides a short form, unique identifier for each certificate generated by an issuer. The serial number is used in RCLs to identify revoked certificates instead of including entire certificates. Thus each certificate generated by an issuer must contain a unique serial number. It is suggested that these numbers be issued as a compact, monotonic increasing sequence.
通し番号分野は発行人によって作られた各証明書に縮約形、ユニークな識別子を供給します。 通し番号は、全体の証明書を含んでいることの代わりに取り消された証明書を特定するのにRCLsで使用されます。 したがって、発行人によって作られた各証明書はユニークな通し番号を含まなければなりません。 これらの数がコンパクトで、単調な増加する系列として発行されることが提案されます。
3.4.1.3 Subject Name
3.4.1.3 対象の名前
A certificate provides a representation of its subject's identity and organizational affiliation in the form of a Distinguished Name. The fundamental binding ensured by the privacy enhancement mechanisms is that between public-key and the user identity. CCITT Recommendation X.500 defines the concept of Distinguished Name.
証明書は対象のアイデンティティと組織的な所属の代理をDistinguished Nameの形に供給します。 プライバシーエンハンスメカニズムによって確実にされた基本的な結合は公開カギとユーザアイデンティティの間のそれです。 CCITT Recommendation X.500はDistinguished Nameの概念を定義します。
Version 2 of the U.S. Government Open Systems Interconnection Profile (GOSIP) specifies maximum sizes for O/R Name attributes. Since most of these attributes also appear in Distinguished Names, we have adopted the O/R Name attribute size constraints specified in GOSIP and noted below. Using these size constraints yields a maximum Distinguished Name length (exclusive of ASN encoding) of two-hundred fifty-nine (259) characters, based on the required and optional attributes described below for subject names. The following attributes are required in subject Distinguished Names for purposes of this RFC:
米国政府オープン・システム・インターコネクションProfile(GOSIP)のバージョン2はO/R Name属性に最大サイズを指定します。 また、これらの属性の大部分がDistinguished Namesに現れるので、私たちはGOSIPで指定されて、以下に述べられたO/R Name属性サイズ規制を採用しました。 これらのサイズ規制を使用すると、最大のDistinguished Nameの長さ(ASNコード化を除いた)の259(259)キャラクタはもたらされます、対象の名前のために以下で説明された必要で任意の属性に基づいて。 以下の属性がこのRFCの目的に対象のDistinguished Namesで必要です:
1. Country Name in standard encoding (e.g., the two-character
Printable String "US" assigned by ISO 3166 as the identifier
for the United States of America, the string "GB" assigned as
the identifier for the United Kingdom, or the string "NQ"
assigned as the identifier for Dronning Maud Land). Maximum
ASCII character length of three (3).
1. 標準のコード化(例えば、アメリカ合衆国のための識別子としてISO3166によって割り当てられた2キャラクタPrintable String「米国」、イギリスのための識別子として割り当てられたストリング「GB」、またはDronning旅行用膝掛け陸のための識別子として割り当てられたストリング"NQ")における国のName。 最大のASCII文字の長さの3(3)。
2. Organizational Name (e.g., the Printable String "Bolt Beranek
and Newman, Inc."). Maximum ASCII character length of
sixty-four (64).
2. 組織的な名前(例えば、印刷可能なストリング「ボルトBeranekとニューマンInc.」)。 最大のASCII文字の長さの64(64)。
3. Personal Name (e.g., the X.402/X.411 structured Printable
String encoding for the name John Linn). Maximum ASCII
character length of sixty-four (64).
3. 個人的なName(例えば、X.402/X.411は名前のためにジョン・リンをコード化するPrintable Stringを構造化しました)。 最大のASCII文字の長さの64(64)。
Kent & Linn [Page 18] RFC 1114 Mail Privacy: Key Management August 1989
ケントとリン[18ページ]RFC1114はプライバシーを郵送します: Key Management1989年8月
The following attributes are optional in subject Distinguished Names for purposes of this RFC:
以下の属性はこのRFCの目的のために対象のDistinguished Namesで任意です:
1. Organizational Unit Name(s) (e.g., the Printable String "BBN
Communications Corporation") A hierarchy of up to four
organizational unit names may be provided; the least
significant member of the hierarchy is represented first.
Each of these attributes has a maximum ASCII character length of
thirty-two (32), for a total of one-hundred and twenty-eight
(128) characters if all four are present.
1. 最大4つの組織的なユニット名の階層構造が提供されるかもしれない組織的なUnit Name(s)(例えば、Printable String「BBNコミュニケーション社」)。 階層構造の最も重要でないメンバーは最初に、代理をされます。 それぞれのこれらの属性に、すべての4が存在しているなら、合計128の(128)キャラクタのための最大のASCII文字の長さの32(32)があります。
3.4.1.4 Issuer Name
3.4.1.4 発行人名
A certificate provides a representation of its issuer's identity, in the form of a Distinguished Name. The issuer identification is needed in order to determine the appropriate issuer public component to use in performing certificate validation. The following attributes are required in issuer Distinguished Names for purposes of this RFC:
証明書はDistinguished Nameの形における、発行人のアイデンティティの表現を提供します。 発行人識別が、証明書合法化を実行することにおける使用への適切な発行人公共のコンポーネントを決定するのに必要です。 以下の属性がこのRFCの目的に発行人Distinguished Namesで必要です:
1. Country Name (e.g., encoding for "US")
1. 国の名(例えば、「米国」へのコード化)
2. Organizational Name
2. 組織的な名前
The following attributes are optional in issuer Distinguished Names for purposes of this RFC:
以下の属性はこのRFCの目的のために発行人Distinguished Namesで任意です:
1. Organizational Unit Name(s). (A hierarchy of up to four
organizational unit names may be provided; the least significant
member of the hierarchy is represented first.) If the
issuer is vouching for the user identity in the Notary capacity
described above, then exactly one instance of this field
must be present and it must consist of the string "Notary".
1. 組織的なユニットは(s)を命名します。 (名前が提供されるかもしれない組織的な最大4個のユニットの階層構造; 階層構造の最も重要でないメンバーは最初に、代理をされます。) 発行人が容量が上で説明したNotaryでユーザアイデンティティを保証しているなら、まさにこの分野の1つの例が存在していなければなりません、そして、それはストリング「公証人」から成らなければなりません。
As noted earlier, only organizations are allowed as issuers in the proposed authentication hierarchy. Hence the Distinguished Name for an issuer should always be that of an organization, not a user, and thus no Personal Name field may be included in the Distinguished Name of an issuer.
より早く注意されるように、組織だけが発行人として提案された認証階層構造で許されています。 したがって、いつも発行人のためのDistinguished Nameはユーザではなく、組織のものであるべきです、そして、その結果、パーソナルName分野は全く発行人のDistinguished Nameに含まれないかもしれません。
3.4.1.5 Validity Period
3.4.1.5 有効期間
A certificate carries a pair of time specifiers, indicating the start and end of the time period over which a certificate is intended to be used. No message should ever be prepared for transmission with a non-current certificate, but recipients should be prepared to receive messages processed using recently-expired certificates. This fact results from the unpredictable (and sometimes substantial)
証明書は1組の時間特許説明書の作成書を載せます、証明書が使用されることを意図する期間の始めと終わりを示して。 今までに、非現在の証明書によるトランスミッションのためにメッセージを全く準備するべきではありませんが、受取人は最近満期の証明書を使用することで処理されたメッセージを受け取る用意ができているべきです。 この事実は予測できないのから生じます。(時々実質的)
Kent & Linn [Page 19] RFC 1114 Mail Privacy: Key Management August 1989
ケントとリン[19ページ]RFC1114はプライバシーを郵送します: Key Management1989年8月
transmission delay of the staged-delivery electronic mail environment. The default and maximum validity period for certificates issued in this system will be two years.
上演された配送電子メール環境のトランスミッション遅れ。 このシステムで発行された証明書のためのデフォルトと最大の有効期間は2年になるでしょう。
3.4.1.6 Subject Public Component
3.4.1.6 対象の公共のコンポーネント
A certificate carries the public component of its associated entity, as well as an indication of the algorithm with which the public component is to be used. For purposes of this RFC, the algorithm identifier will indicate use of the RSA algorithm, as specified in RFC-1115. Note that in this context, a user's public component is actually the modulus employed in RSA algorithm calculations. A "universal" (public) exponent is employed in conjunction with the modulus to complete the system. Two choices of exponents are recommended for use in this context and are described in section 3.4.3. Modulus size will be permitted to vary between 320 and 632 bits.
証明書は関連実体の公共のコンポーネントを載せます、使用されている公共のコンポーネントがことであるアルゴリズムのしるしと同様に。 このRFCの目的のために、アルゴリズム識別子はRFC-1115で指定されるようにRSAアルゴリズムの使用を示すでしょう。 このような関係においては、ユーザの公共のコンポーネントが実際にRSAアルゴリズム計算で使われた係数であることに注意してください。 「普遍的な」(公共の)解説者は、システムを完成するために係数に関連して雇われます。 解説者の2つの選択が、使用のためにこのような関係においては推薦されて、セクション3.4.3で説明されます。 係数サイズが320〜632ビット異なるのが許容されるでしょう。
3.4.1.7 Certificate Signature
3.4.1.7 証明書署名
A certificate carries a signature algorithm identifier and a signature, applied to the certificate by its issuer. The signature is validated by the user of a certificate, in order to determine that the integrity of its contents have not been compromised subsequent to generation by a CA. An encrypted, one-way hash will be employed as the signature algorithm. Hash functions suitable for use in this context are notoriously difficult to design and tend to be computationally intensive. Initially we have adopted a hash function developed by RSADSI and which exhibits performance roughly equivalent to the DES (in software). This same function has been selected for use in other contexts in this system where a hash function (message hash algorithm) is required, e.g., MIC for multicast messages. In the future we expect other one-way hash functions will be added to the list of algorithms designated for this purpose.
証明書は発行人による証明書に適用された署名アルゴリズム識別子と署名を載せます。 署名は証明書のユーザによって有効にされます、コンテンツの保全がカリフォルニアによる世代にその後で妥協していないことを決定するために。 コード化されて、片道の細切れ肉料理は署名アルゴリズムとして使われるでしょう。 使用に適したハッシュ関数は計算上徹底的である設計して、傾向があるのはこのような関係においては悪名高く難しいです。 初めは、私たちはおよそDES(ソフトウェアの)に同等な性能を示すRSADSIによって開発されたハッシュ関数を採用しました。 この同じ機能はハッシュ関数(メッセージ細切れ肉料理アルゴリズム)が必要であるこのシステムの他の文脈における使用のために選択されました、例えば、マルチキャストメッセージのためのMIC。 将来、私たちは、他の片道ハッシュ関数がこのために指定されたアルゴリズムのリストに追加されると予想します。
3.4.2 Validation Conventions
3.4.2 合法化コンベンション
Validating a certificate involves 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 the proposed architecture this recursive operation is terminated quickly by adopting the convention that RSADSI will certify the certificates of all organizations or organizational units which act as issuers for end users. (Additional validation steps may be
証明書を有効にするのは、発行人の公共のコンポーネントを使用することで署名分野を解読するので、証明書に付けられた署名が有効であり、すなわち、ハッシュ値が証明書コンテンツマッチの上に結果として生じる値を計算したことを確かめることを伴います。 この操作を実行するために、ユーザには発行人の公共のコンポーネントが別の(有効にされます)証明書から保全で確実なチャンネルでそれを抽出することによって、なければなりません。 提案されたアーキテクチャでは、この再帰的な操作は、急速にRSADSIがすべての組織の証明書であることを公認するコンベンションかエンドユーザのための発行人として機能する組織的なユニットを採用することによって、終えられます。 (追加合法化ステップはそうです。
Kent & Linn [Page 20] RFC 1114 Mail Privacy: Key Management August 1989
ケントとリン[20ページ]RFC1114はプライバシーを郵送します: Key Management1989年8月
required for certificates issued by other CAs as described in section 3.3.3.1.)
セクション3.3.3で.1について)説明するとき他のCAsによって発行された証明書のために、必要です。
Certification means that RSADSI will sign certificates in which the subject is the organization or organizational unit and for which RSADSI is the issuer, thus implying that RSADSI vouches for the credentials of the subject. This is an appropriate construct since each ON representing an organization or organizational unit must have registered with RSADSI via a procedure more rigorous than individual user registration. This does not preclude an organizational unit from also holding a certificate in which the "parent" organization (or organizational unit) is the issuer. Both certificates are appropriate and permitted in the X.509 framework. However, in order to facilitate the validation process in an environment where user- level directory services are generally not available, we will (at this time) adopt this certification convention.
証明は、RSADSIが対象が組織か組織的なユニットであり、RSADSIが発行人である証明書に署名することを意味します、その結果、RSADSIが対象の資格証明書を保証するのを含意します。 組織か組織的なユニットを代表する各ONが個々のユーザ登録より厳密な手順でRSADSIとともに記名したに違いないので、これは適切な構造物です。 これはまた、証明書を所持するのからの「親」組織(または、組織的なユニット)が発行人である離れたところ組織的なユニットを排除しません。 両方の証明書は、適切でX.509フレームワークで受入れられます。 しかしながら、一般に、ユーザレベルディレクトリサービスが利用可能でない環境で合法化プロセスを容易にするために、私たちは(このとき、)この証明コンベンションを採用するつもりです。
The public component needed to validate certificates signed by RSADSI (in its role as a CA for issuers) is transmitted to each user as part of the registration process (using electronic mail with independent, postal confirmation via a message hash). Thus a user will be able to validate any user certificate (from the RSADSI hierarchy) in at most two steps. Consider the situation in which a user receives a privacy enhanced message from an originator with whom the recipient has never previously corresponded. Based on the certification convention described above, the recipient can use the RSADSI public component to validate the issuer's certificate contained in the X-Issuer- Certificate field. (We recommend that, initially, the originator include his organization's certificate in this optional field so that the recipient need not access a server or cache for this public component.) Using the issuer's public component (extracted from this certificate), the recipient can validate the originator's certificate contained in the X-Certificate field of the header.
RSADSI(発行人のためのカリフォルニアとしての役割における)によって署名された証明書を有効にするのに必要である公共のコンポーネントは登録手続(メッセージハッシュを通した独立していて、郵便の確認と共に電子メールを使用する)の一部として各ユーザに伝えられます。 したがって、ユーザは高々2ステップでどんなユーザー証明書も有効にすることができるでしょう(RSADSI階層構造から)。 ユーザが受取人が以前に一度も文通したことがない創始者からプライバシーの高められたメッセージを受け取る状況を考えてください。 上で説明された証明コンベンションに基づいて、受取人は、証明書分野がX-発行人に含まれる状態で発行人の証明書を有効にするのにRSADSIの公共の部品を使用できます。 (私たちは、初めは受取人がこの公共のコンポーネントのためにサーバかキャッシュにアクセスする必要はないように創始者がこの任意の分野で彼の組織の証明書を入れることを勧めます。) 発行人の公共のコンポーネント(この証明書から、抽出される)を使用して、受取人はヘッダーのX-証明書分野に保管されていた創始者の証明書を有効にすることができます。
Having performed this certificate validation process, the recipient can extract the originator's public component and use it to decrypt the content of the X-MIC-Info field and thus verify the data origin authenticity and integrity of the message. Of course, implementations of privacy enhanced mail should cache validated public components (acquired from incoming mail or via the message from a user registration process) to speed up this process. If a message arrives from an originator whose public component is held in the recipient's cache, the recipient can immediately employ that public component without the need for the certificate validation process described here. Also note that the arithmetic required for certificate validation is considerably faster than that involved in digitally signing a certificate, so as to minimize the computational burden on users.
この証明書合法化プロセスを実行したので、受取人は、創始者の公共のコンポーネントを抽出して、X-MIC-インフォメーション分野の内容を解読して、その結果、メッセージのデータ発生源の信憑性と保全について確かめるのにそれを使用できます。 もちろん、高められたメールがキャッシュするべきであるプライバシーの実装はこのプロセスを加速するために、公共のコンポーネント(入って来るメールかユーザ登録手続からのメッセージで、取得する)を有効にしました。 メッセージが公共のコンポーネントが受取人のキャッシュで保持される創始者から到着するなら、受取人はすぐに、ここで説明された証明書合法化プロセスの必要性なしでその公共のコンポーネントを使うことができます。 また、証明書合法化に必要である演算が証明書にデジタルに署名するのにかかわるそれよりかなり速いことに注意してください、ユーザでコンピュータの負担を最小にするために。
Kent & Linn [Page 21] RFC 1114 Mail Privacy: Key Management August 1989
ケントとリン[21ページ]RFC1114はプライバシーを郵送します: Key Management1989年8月
A separate issue associated with validation of certificates is a semantic one, i.e., is the entity identified in the issuer field appropriate to vouch for the identifying information in the subject field. This is a topic outside the scope of X.509, but one which must be addressed in any viable system. The hierarchy proposed in this RFC is designed to address this issue. In most cases a user will claim, as part of his identifying information, affiliation with some organization and that organization will have the means and responsibility for verifying this identifying information. In such circumstances one should expect an obvious relationship between the Distinguished Name components in the issuer and subject fields.
証明書の合法化に関連している別個問題は意味ものです、すなわち、実体が対象の分野で身元が分かる情報を保証するのが適切である発行人分野で特定されますか? これはX.509、しかし、どんな実行可能なシステムでも扱わなければならないものの範囲の外の話題です。 このRFCで提案された階層構造は、この問題を扱うように設計されています。 多くの場合、ユーザは、彼の身元が分かる情報の一部として何らかの組織とその組織による提携にはこの身元が分かる情報について確かめることへの手段と責任があると主張するでしょう。 そのような事情では、発行人と対象の分野のDistinguished Nameの部品の間の明白な関係を予想するべきです。
For example, if the subject field of a certificate identified an individual as affiliated with the "Widget Systems Division" (Organizational Unit Name) of "Compudigicorp" (Organizational Name), one would expect the issuer field to specify "Compudigicorp" as the Organizational Name and, if an Organizational Unit Name were present, it should be "Widget Systems Division." If the issuer's certificate indicated "Compudigicorp" as the subject (with no Organizational Unit specified), then the issuer should be "RSADSI." If the issuer's certificate indicated "Widget Systems Division" as Organizational Unit and "Compudigicorp" as Organization in the subject field, then the issuer could be either "RSADSI" (due to the direct certification convention described earlier) or "Compudigicorp" (if the organization elected to distribute this intermediate level certificate). In the later case, the certificate path would involve an additional step using the certificate in which "Compudigicorp" is the subject and "RSADSI" is the issuer. One should be suspicious if the validation path does not indicate a subset relationship for the subject and issuer Distinguished Names in the certification path, expect where cross-certification is employed to cross CA boundaries.
例えば、証明書の対象の分野が"Compudigicorp"(組織的なName)の「ウィジェットシステム区画」(組織的なUnit Name)に加わられるように個人を特定するなら、人は、Organizational NameとOrganizational Unit Nameが存在しているときのそれが「ウィジェットシステム区画」であるべきであって、発行人分野が"Compudigicorp"を指定すると予想するでしょうに。 発行人の証明書が対象(Organizational Unitが全く指定されていない)として"Compudigicorp"を示すなら、発行人は"RSADSI"でしょうに。 発行人の証明書がOrganizationとしてのOrganizational Unitと"Compudigicorp"として対象の分野で「ウィジェットシステム区画」を示すなら、発行人は、"RSADSI"(より早く説明されたダイレクト証明コンベンションによる)か"Compudigicorp"のどちらかであるかもしれないでしょうに(組織が、この中間的平らな証明書を配布するのを選んだなら)。 後の場合では、"Compudigicorp"が対象であり、"RSADSI"が発行人である証明書を使用することで証明書経路は追加ステップにかかわるでしょう。 合法化経路が対象と発行人Distinguished Namesのために証明経路で部分集合関係を示さないなら、疑わしげであるはずであり、相互認証が採用しているところでカリフォルニア境界に交差するように予想してください。
It is a local matter whether the message system presents a human user with the certification path used to validate a certificate associated with incoming, privacy-enhanced mail. We note that a visual display of the Distinguished Names involved in that path is one means of providing the user with the necessary information. We recommend, however, that certificate validation software incorporate checks and alert the user whenever the expected certification path relationships are not present. The rationale here is that regular display of certification path data will likely be ignored by users, whereas automated checking with a warning provision is a more effective means of alerting users to possible certification path anomalies. We urge developers to provide facilities of this sort.
メッセージシステムが証明経路を人間のユーザに与えるかどうかが以前はよく入って来て、プライバシーで高められたメールに関連している証明書を有効にしたのは、地域にかかわる事柄です。 私たちは、その経路にかかわるDistinguished Namesの視覚ディスプレイが必要事項をユーザに提供する1つの手段であることに注意します。 しかしながら、私たちは、予想された証明経路関係が存在していないときはいつも、証明書合法化ソフトウェアがチェックを取り入れて、ユーザを警告することを勧めます。 ここの原理は証明経路データの定期的なディスプレイがユーザによっておそらく無視されるのにもかかわらずの、警告支給による自動化された照合が可能な証明経路例外にユーザの注意を喚起するより効果的な手段であるということです。 私たちは、この種類の施設を提供するよう開発者に促します。
3.4.3 Relation with X.509 Certificate Specification
3.4.3 X.509証明書仕様との関係
An X.509 certificate can be viewed as two components: contents and an
2つのコンポーネントとしてX.509証明書を見なすことができます: そしてコンテンツ。
Kent & Linn [Page 22] RFC 1114 Mail Privacy: Key Management August 1989
ケントとリン[22ページ]RFC1114はプライバシーを郵送します: Key Management1989年8月
encrypted hash. The encrypted hash is formed and processed as follows:
暗号化されたハッシュ。 暗号化されたハッシュは、以下の通り形成されて、処理されます:
1. X, the hash, is computed as a function of the certificate
contents
1. X(ハッシュ)は証明書コンテンツの機能として計算されます。
2. the hash is signed by raising X to the power e (modulo n)
2. パワーeにXを上げることによって、ハッシュは署名されます。(法n)
3. the hash's signature is validated by raising the result of
step 2 to the power d (modulo n), yielding X, which is
compared with the result computed as a function of certificate
contents.
3. ハッシュの署名はパワーd(法n)へのステップ2の結果を上げることによって、有効にされます、X(証明書コンテンツの機能として計算される結果と比較される)をもたらして。
Annex C to X.509 suggests the use of Fermat number F4 (65537 decimal, 1 + 2 **16 ) as a fixed value for e which allows relatively efficient authentication processing, i.e., at most seventeen (17) multiplications are required to effect exponentiation). As an alternative one can employ three (3) as the value for e, yielding even faster exponentiation, but some precautions must be observed (see RFC-1115). Users of the algorithm select values for d (a secret quantity) and n (a non-secret quantity) given this fixed value for e. As noted earlier, this RFC proposes that either three (3) or F4 be employed as universal encryption exponents, with the choice specified in the algorithm identifier. In particular, use of an exponent value of three (3) for certificate validation is encouraged, to permit rapid certificate validation. Given these conventions, a user's public component, and thus the quantity represented in his certificate, is actually the modulus (n) employed in this computation (and in the computations used to protect the DEK and MSGHASH, as described in RFC-1113). A user's private component is the exponent (d) cited above.
X.509への別館Cはフェルマー数F4の使用を示します(65537小数、1+2**16)がすなわち、比較的効率的な認証処理を許すeのための一定の価値、ほとんどの17(17)掛け算のときに羃法に作用するのに必要です)。 代替手段として、人はeのための値、柔軟なさらに速い羃法として3(3)を使うことができますが、いくつかの注意を守らなければなりません(RFC-1115を見てください)。 eのためのこの一定の価値を考えて、アルゴリズムのユーザはd(秘密の量)とn(非秘密の量)のために値を選択します。 より早く注意されるように、このRFCは、3(3)かF4のどちらかが普遍的な暗号化解説者として使われるよう提案します、選択がアルゴリズム識別子で指定されている状態で。 特に、3(3)の解説者価値の証明書合法化の使用が急速な証明書合法化を可能にするよう奨励されます。 これらのコンベンションを考えて、ユーザの公共のコンポーネント、およびその結果彼の証明書に表された量は実際にこの計算(そしてDEKとMSGHASHを保護するのにRFC-1113で説明されるように使用される計算で)で使われた係数(n)です。 ユーザの個人的なコンポーネントは上で引用された解説者(d)です。
The X.509 certificate format is defined (in X.509, Annex G) by the following ASN.1 syntax:
X.509証明書書式は以下のASN.1構文で定義されます(X.509のAnnex G):
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:、:= 整数
Kent & Linn [Page 23] RFC 1114 Mail Privacy: Key Management August 1989
ケントとリン[23ページ]RFC1114はプライバシーを郵送します: Key Management1989年8月
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
All components of this structure are well defined by ASN.1 syntax defined in the 1988 X.400 and X.500 Series Recommendations, except for the AlgorithmIdentifier. An algorithm identifier for RSA is contained in Annex H of X.509 but is unofficial. RFC-1115 will provide detailed syntax and values for this field.
この構造のすべての部品が1988X.400とX.500 Series Recommendationsで定義されたASN.1構文でよく定義されます、AlgorithmIdentifierを除いて。 RSAのためのアルゴリズム識別子は、X.509のAnnex Hに含まれていますが、非公式です。 RFC-1115は詳細な構文と値をこの分野に提供するでしょう。
NOTES:
注意:
[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)、「ディレクトリ認証フレームワーク。」
Kent & Linn [Page 24] RFC 1114 Mail Privacy: Key Management August 1989
ケントとリン[24ページ]RFC1114はプライバシーを郵送します: Key Management1989年8月
Authors' Addresses
作者のアドレス
Steve Kent
BBN Communications
50 Moulton Street
Cambridge, MA 02138
スティーブ・ケントBBN Communications50モールトン・通りケンブリッジ、MA 02138
Phone: (617) 873-3988
以下に電話をしてください。 (617) 873-3988
EMail: kent@BBN.COM
メール: kent@BBN.COM
John Linn
Secure Systems
Digital Equipment Corporation
85 Swanson Road, BXB1-2/D04
Boxborough, MA 01719-1326
DEC85スワンソンRoad、BXB1-2/D04 Boxborough、ジョン・リンSecureのSystems MA01719-1326
Phone: 508-264-5491
以下に電話をしてください。 508-264-5491
EMail: Linn@ultra.enet.dec.com
メール: Linn@ultra.enet.dec.com
Kent & Linn [Page 25]
ケントとリン[25ページ]
一覧
スポンサーリンク
