RFC2528 日本語訳

Network Working Group                                        R. Housley
Request for Comments: 2528                                       SPYRUS
Category: Informational                                         W. Polk
                                                                   NIST
                                                             March 1999

Housleyがコメントのために要求するワーキンググループR.をネットワークでつないでください: 2528年のSPYRUSカテゴリ: 1999年の情報のW.ポークのNIST行進

                Internet X.509 Public Key Infrastructure

インターネットX.509公開鍵暗号基盤

         Representation of Key Exchange Algorithm (KEA) Keys in
         Internet X.509 Public Key Infrastructure Certificates

インターネットX.509公開鍵暗号基盤証明書における、主要な交換アルゴリズム(ケア)キーの表現

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Copyright Notice

版権情報

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

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

Table of Contents

目次

   Abstract ........................................................ 2
   1.  Executive Summary ........................................... 2
   2.  Requirements and Assumptions ................................ 2
   2.1.  Communication and Topology ................................ 2
   2.2.  Acceptability Criteria .................................... 2
   2.3.  User Expectations ......................................... 3
   2.4.  Administrator Expectations ................................ 3
   3.  KEA Algorithm Support ....................................... 3
   3.1.  Subject Public Key Info ................................... 3
   3.1.1.  Algorithm Identifier and Parameters ..................... 4
   3.1.2.  Encoding of KEA Public Keys ............................. 5
   3.2.  Key Usage Extension in KEA certificates ................... 5
   4. ASN.1 Modules ................................................ 5
   4.1 1988 Syntax ................................................. 5
   4.2 1993 Syntax ................................................. 6
   5. References ................................................... 6
   6. Security Considerations ...................................... 7
   7. Authors' Addresses ........................................... 8
   8. Full Copyright Statement ..................................... 9

要約… 2 1. 要約… 2 2. 要件と仮定… 2 2.1. コミュニケーションとトポロジー… 2 2.2. 受容性評価基準… 2 2.3. ユーザ期待… 3 2.4. 管理者期待… 3 3. ケアアルゴリズムサポート… 3 3.1. 対象の公開鍵インフォメーション… 3 3.1.1. アルゴリズム識別子とパラメタ… 4 3.1.2. ケア公開鍵のコード化… 5 3.2. KEA証明書の主要なUsage Extension… 5 4. ASN.1モジュール… 5 4.1 1988年の構文… 5 4.2 1993年の構文… 6 5. 参照… 6 6. セキュリティ問題… 7 7. 作者のアドレス… 8 8. 完全な著作権宣言文… 9

Housley & Polk               Informational                      [Page 1]

RFC 2528                        PKIX KEA                      March 1999

1999年の[1ページ]RFC2528PKIXケア行進の情報のHousleyとポーク

Abstract

要約

   The Key Exchange Algorithm (KEA) is a classified algorithm for
   exchanging keys.  This specification profiles the format and
   semantics of fields in X.509 V3 certificates containing KEA keys. The
   specification addresses the subjectPublicKeyInfo field and the
   keyUsage extension.

Key Exchange Algorithm(KEA)は、キーを交換するための分類されたアルゴリズムです。 KEAキーを含んでいて、この仕様はX.509 V3証明書で分野の形式と意味論の輪郭を描きます。 仕様は、subjectPublicKeyInfo分野とkeyUsageが拡大であると扱います。

1.  Executive Summary

1. 要約

   This specification contains guidance on the use of the Internet
   Public Key Infrastructure certificates to convey Key Exchange
   Algorithm (KEA) keys. This specification is an addendum to RFC 2459,
   "Internet X.509 Public Key Infrastructure: Certificate and CRL
   Profile".  Implementations of this specification must also conform to
   RFC 2459.  Implementations of this specification are not required to
   conform to other parts from that series.

この仕様は、Key Exchange Algorithm(KEA)キーを運ぶためにインターネット公開鍵暗号基盤証明書の使用に指導を含んでいます。 この仕様がRFC2459への付加物である、「インターネットX.509公開鍵基盤:」 「証明書とCRLプロフィール。」 また、この仕様の実装はRFC2459に従わなければなりません。 この仕様の実装は、そのシリーズからの他の部品に従うのに必要ではありません。

2.  Requirements and Assumptions

2. 要件と仮定

   The goal is to augment the X.509 certificate profile presented in
   Part 1 to facilitate the management of KEA keys for those communities
   which use this algorithm.

目標はこのアルゴリズムを使用するそれらの共同体にKEAキーの管理を容易にするためにPart1に提示されたX.509証明書プロフィールを増大させることです。

2.1.  Communication and Topology

2.1. コミュニケーションとトポロジー

   This profile, as presented in [RFC 2459] and augmented by this
   specification, supports users without high bandwidth, real-time IP
   connectivity, or high connection availability.  In addition, the
   profile allows for the presence of firewall or other filtered
   communication.

[RFC2459]に提示されて、この仕様で増大するこのプロフィールは、高帯域も、リアルタイムのIPの接続性も、または高い接続の有用性なしでユーザをサポートします。 さらに、プロフィールは何らかのファイアウォールの存在のためにフィルターにかけることのコミュニケーションを許容します。

   This profile does not assume the deployment of an X.500 Directory
   system.  The profile does not prohibit the use of an X.500 Directory,
   but other means of distributing certificates and certificate
   revocation lists (CRLs) are supported.

このプロフィールはX.500ディレクトリシステムの展開を仮定しません。 プロフィールはX.500ディレクトリの使用を禁止しませんが、証明書と証明書失効リスト(CRLs)を配布する他の手段はサポートされます。

2.2.  Acceptability Criteria

2.2. ロット判定基準

   The goal of the Internet Public Key Infrastructure (PKI) is to meet
   the needs of deterministic, automated identification, authentication,
   access control, and authorization functions. Support for these
   services determines the attributes contained in the certificate as
   well as the ancillary control information in the certificate such as
   policy data and certification path constraints.

インターネット公開鍵暗号基盤(PKI)の目標は決定論的で、自動化された識別、認証、アクセスコントロール、および承認機能の需要を満たすことです。 これらのサービスのサポートは付属の制御情報と同様に証明書の方針データなどの証明書に含まれた属性と証明経路規制を決定します。

Housley & Polk               Informational                      [Page 2]

RFC 2528                        PKIX KEA                      March 1999

1999年の[2ページ]RFC2528PKIXケア行進の情報のHousleyとポーク

   The goal of this document is to profile KEA certificates, specifying
   the contents and semantics of attributes which were not fully
   specified by [RFC 2459].  If not specifically addressed by this
   document, the contents and semantics of the fields and extensions
   must be as described in [RFC 2459].

このドキュメントの目標はKEA証明書の輪郭を描くことです、[RFC2459]によって完全に指定されたというわけではない属性のコンテンツと意味論を指定して。 このドキュメントによって明確に扱われないなら、分野と拡大のコンテンツと意味論が[RFC2459]で説明されるようにあるに違いありません。

2.3.  User Expectations

2.3. ユーザ期待

   Users of the Internet PKI are people and processes who use client
   software and are the subjects named in certificates.  These uses
   include readers and writers of electronic mail, the clients for WWW
   browsers, WWW servers, and the key manager for IPSEC within a router.
   This profile recognizes the limitations of the platforms these users
   employ and the sophistication/attentiveness of the users themselves.
   This manifests itself in minimal user configuration responsibility
   (e.g., root keys, rules), explicit platform usage constraints within
   the certificate, certification path constraints which shield the user
   from many malicious actions, and applications which sensibly automate
   validation functions.

インターネットPKIのユーザは、クライアントソフトウェアを使用する人々とプロセスであり、証明書で指定された対象です。 これらの用途はルータの中にIPSECの電子メールの読者と作家、WWWブラウザのためのクライアント、WWWサーバ、および主要なマネージャを含んでいます。 このプロフィールはこれらのユーザが使うプラットホームの制限とユーザ自身の洗練/注意深さを認識します。 これは最小量のユーザ構成責任(例えば、キーを根づかせてください、規則)、証明書、多くの悪意がある行為からユーザを保護する証明経路規制、および分別よく合法化機能を自動化するアプリケーションの中の明白なプラットホーム用法規制で現れます。

2.4.  Administrator Expectations

2.4. 管理者期待

   As with users, the Internet PKI profile is structured to support the
   individuals who generally operate Certification Authorities (CAs).
   Providing administrators with unbounded choices increases the chances
   that a subtle CA administrator mistake will result in broad
   compromise or unnecessarily limit interoperability.  This profile
   defines the object identifiers and data formats that must be
   supported to interpret KEA public keys.

ユーザのように、インターネットPKIプロフィールは、一般に、Certification Authorities(CAs)を運用する個人をサポートするために構造化されます。 限りない選択を管理者に提供すると、微妙なカリフォルニア管理者誤りが広い感染をもたらすか、または不必要に相互運用性を制限するという可能性は増強されます。 このプロフィールはKEA公開鍵を解釈するためにサポートしなければならないオブジェクト識別子とデータ書式を定義します。

3.  KEA Algorithm Support

3. ケアアルゴリズムサポート

   This section describes object identifiers and data formats which may
   be used with [RFC 2459] to describe X.509 certificates containing a
   KEA public key.  Conforming CAs are required to use the object
   identifiers and data formats when issuing KEA certificates.
   Conforming applications shall recognize the object identifiers and
   process the data formats when processing such certificates.

このセクションはKEA公開鍵を含むX.509証明書について説明するのに[RFC2459]と共に使用されるかもしれないオブジェクト識別子とデータ形式について説明します。 KEAに証明書を発行するとき、従うCAsはオブジェクト識別子とデータ形式を使用しなければなりません。 アプリケーションを従わせると、そのような証明書を処理するときデータがフォーマットするオブジェクト識別子とプロセスは認識されるものとします。

3.1.  Subject Public Key Info

3.1. 対象の公開鍵インフォメーション

   The certificate identifies the KEA algorithm, conveys optional
   parameters, and specifies the KEA public key in the
   subjectPublicKeyInfo field. The subjectPublicKeyInfo field is a
   SEQUENCE of an algorithm identifier and the subjectPublicKey field.

証明書は、subjectPublicKeyInfo分野でKEAアルゴリズムを特定して、任意のパラメタを伝えて、KEA公開鍵を指定します。 subjectPublicKeyInfo分野はアルゴリズム識別子とsubjectPublicKey分野のSEQUENCEです。

Housley & Polk               Informational                      [Page 3]

RFC 2528                        PKIX KEA                      March 1999

1999年の[3ページ]RFC2528PKIXケア行進の情報のHousleyとポーク

   The certificate indicates the algorithm through an algorithm
   identifier.  This algorithm identifier consists of an object
   identifier (OID) and optional associated parameters.  Section 3.1.1
   identifies the preferred OID and parameters for the KEA algorithm.
   Conforming CAs shall use the identified OID when issuing certificates
   containing public keys for the KEA algorithm. Conforming applications
   supporting the KEA algorithm shall, at a minimum, recognize the OID
   identified in section 3.1.1.

証明書はアルゴリズム識別子を通してアルゴリズムを示します。 このアルゴリズム識別子はオブジェクト識別子(OID)と任意の関連パラメタから成ります。 セクション3.1 .1 KEAアルゴリズムのための都合のよいOIDとパラメタを特定します。 KEAアルゴリズムのために公開鍵を含む証明書を発行するとき、CAsを従わせると、特定されたOIDは使用されるものとします。 KEAアルゴリズムをサポートするアプリケーションを従わせると、最小限で、セクション3.1.1で特定されたOIDは認識されるものとします。

   The certificate conveys the KEA public key through the
   subjectPublicKey field.  This subjectPublicKey field is a BIT STRING.
   Section 3.1.2 specifies the method for encoding a KEA public key as a
   BIT STRING.  Conforming CAs shall encode the KEA public key as
   described in Section 3.1.2 when issuing certificates containing
   public keys for the KEA algorithm. Conforming applications supporting
   the KEA algorithm shall decode the subjectPublicKey as described in
   section 3.1.2 when the algorithm identifier is the one presented in
   3.1.1.

証明書はsubjectPublicKey分野を通ってKEA公開鍵を伝えます。 このsubjectPublicKey分野はBIT STRINGです。 セクション3.1 .2 BIT STRINGとしてKEA公開鍵をコード化するためのメソッドを指定します。 CAsを従わせると、KEA公開鍵はKEAアルゴリズムのために公開鍵を含む証明書を発行するとき、セクション3.1.2で説明されるようにコード化されるものとします。 KEAアルゴリズムをサポートするとsubjectPublicKeyが解読されるものとするアプリケーションを従わせるのが、セクション3.1.2でいつアルゴリズム識別子が提示されたものであるかを説明した、3.1、.1

3.1.1.  Algorithm Identifier and Parameters

3.1.1. アルゴリズム識別子とパラメタ

   The Key Exchange Algorithm (KEA) is an algorithm for exchanging keys.
   A KEA "pairwise key" may be generated between two users if their KEA
   public keys were generated with the same KEA parameters.  The KEA
   parameters are not included in a certificate; instead a "domain
   identifier" is supplied in the parameters field.

Key Exchange Algorithm(KEA)は、キーを交換するためのアルゴリズムです。 彼らのKEA公開鍵が同じKEAパラメタで生成されたなら、KEA「対状キー」は2人のユーザの間で生成されるかもしれません。 KEAパラメタは証明書に含まれていません。 代わりに、パラメタ分野で「ドメイン識別子」を供給します。

   When the subjectPublicKeyInfo field contains a KEA key, the algorithm
   identifier and parameters shall be as defined in [sdn.701r]:

subjectPublicKeyInfo分野がKEAキーを含むとき、アルゴリズム識別子とパラメタは[sdn.701r]で定義されるとおりのものとするです:

      id-keyExchangeAlgorithm  OBJECT IDENTIFIER   ::=
             { 2 16 840 1 101 2 1 1 22 }

イド-keyExchangeAlgorithmオブジェクト識別子:、:= { 2 16 840 1 101 2 1 1 22 }

      KEA-Parms-Id     ::= OCTET STRING

ケアParmsイド:、:= 八重奏ストリング

   CAs shall populate the parameters field of the AlgorithmIdentifier
   within the subjectPublicKeyInfo field of each certificate containing
   a KEA public key with an 80-bit parameter identifier (OCTET STRING),
   also known as the domain identifier. The domain identifier will be
   computed in three steps: (1) the KEA parameters are DER encoded using
   the Dss-Parms structure; (2) a 160-bit SHA-1 hash is generated from
   the parameters; and (3) the 160-bit hash is reduced to 80-bits by
   performing an "exclusive or" of the 80 high order bits with the 80
   low order bits.  The resulting value is encoded such that the most
   significant byte of the 80-bit value is the first octet in the octet
   string.

また、ドメイン識別子として知られている80ビットのパラメタ識別子(OCTET STRING)があるKEA公開鍵を含んでいて、CAsはそれぞれの証明書のsubjectPublicKeyInfo分野の中でAlgorithmIdentifierのパラメタ分野に居住するものとします。 ドメイン識別子は以下の3ステップで計算されるでしょう: (1) KEAパラメタはDss-Parms構造を使用することでコード化されたDERです。 (2) 160ビットのSHA-1ハッシュはパラメタから生成されます。 または、(3) そして、160ビットのハッシュが働くことによって80ビットまで減少する、「排他的である、」 80安値がある80高位のビットでは、ビットを配置してください。 結果として起こる値がコード化されるので、80ビットの価値の最も重要なバイトは八重奏ストリングで最初の八重奏です。

Housley & Polk               Informational                      [Page 4]

RFC 2528                        PKIX KEA                      March 1999

1999年の[4ページ]RFC2528PKIXケア行進の情報のHousleyとポーク

   The Dss-Parms is provided in [RFC 2459] and reproduced below for
   completeness.

Dss-Parmsは[RFC2459]に提供されて、完全性のために以下で再生します。

        Dss-Parms  ::=  SEQUENCE  {
            p             INTEGER,
            q             INTEGER,
            g             INTEGER  }

Dss-Parms:、:= 系列p INTEGER、q INTEGER、g INTEGER

3.1.2.  Encoding of KEA Public Keys

3.1.2. ケア公開鍵のコード化

   A KEA public key, y, is conveyed in the subjectPublicKey BIT STRING
   such that the most significant bit (MSB) of y becomes the MSB of the
   BIT STRING value field and the least significant bit (LSB) of y
   becomes the LSB of the BIT STRING value field.  This results in the
   following encoding: BIT STRING tag, BIT STRING length, 0 (indicating
   that there are zero unused bits in the final octet of y), BIT STRING
   value field including y.

KEA公開鍵(y)がsubjectPublicKey BIT STRINGで伝えられるので、yの最も重要なビット(MSB)はBIT STRING値の分野のMSBになります、そして、yの最下位ビット(LSB)はBIT STRING値の分野のLSBになります。 これは以下のコード化をもたらします: BIT STRINGタグ、BIT STRINGの長さ、0(yの最終的な八重奏にはどんな未使用のビットもないのを示す)、BIT STRINGはyを含む分野を評価します。

3.2.  Key Usage Extension in KEA certificates

3.2. KEA証明書の主要なUsage Extension

   The key usage extension may optionally appear in a KEA certificate.
   If a KEA certificate includes the keyUsage extension, only the
   following values may be asserted:

主要な用法拡大はKEA証明書に任意に現れるかもしれません。 KEA証明書がkeyUsage拡張子を含んでいるなら、以下の値だけについて断言してもよいです:

      keyAgreement;
      encipherOnly; and
      decipherOnly.

keyAgreement。 encipherOnly。 そして、decipherOnly。

   The encipherOnly and decipherOnly values may only be asserted if the
   keyAgreement value is also asserted.  At most one of encipherOnly and
   decipherOnly shall be asserted in keyUsage extension.  Generally, the
   keyAgreement value is asserted without either the encipherOnly or
   decipherOnly value being asserted.

また、keyAgreement値が断言される場合にだけ、encipherOnlyとdecipherOnly値は断言されるかもしれません。 高々、encipherOnlyとdecipherOnlyの1つはkeyUsage拡張子で断言されるものとします。 一般に、keyAgreement値はencipherOnlyも断言されるdecipherOnly値のどちらかなしで断言されます。

4. ASN.1 Modules

4. ASN.1モジュール

4.1 1988 Syntax

4.1 1988年の構文

   PKIXkea88 {iso(1) identified-organization(3) dod(6)
            internet(1) security(5) mechanisms(5) pkix(7)
            id-mod(0) id-mod-kea-profile-88(7) }

PKIXkea88iso(1)の特定された組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)イドモッズケアプロフィール88(7)

   BEGIN ::=

以下を始めてください:=

   -- EXPORTS ALL --

-- すべてをエクスポートします--

   -- IMPORTS NONE --

-- なにもインポートしません--

Housley & Polk               Informational                      [Page 5]

RFC 2528                        PKIX KEA                      March 1999

1999年の[5ページ]RFC2528PKIXケア行進の情報のHousleyとポーク

      id-keyExchangeAlgorithm  OBJECT IDENTIFIER   ::=
             { 2 16 840 1 101 2 1 1 22 }

イド-keyExchangeAlgorithmオブジェクト識別子:、:= { 2 16 840 1 101 2 1 1 22 }

      KEA-Parms-Id     ::= OCTET STRING

ケアParmsイド:、:= 八重奏ストリング

   END

終わり

4.2 1993 Syntax

4.2 1993年の構文

      PKIXkea93 {iso(1) identified-organization(3) dod(6)
            internet(1) security(5) mechanisms(5) pkix(7)
            id-mod(0) id-mod-kea-profile-93(8) }

PKIXkea93iso(1)の特定された組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)イドモッズケアプロフィール93(8)

      BEGIN ::=

以下を始めてください:=

   -- EXPORTS ALL --

-- すべてをエクスポートします--

   IMPORTS         ALGORITHM-ID
           FROM PKIX1Explicit93 {iso(1) identified-organization(3)
           dod(6) internet(1) security(5) mechanisms(5) pkix(7)
           id-mod(0) id-pkix1-explicit-93(3) }

PKIX1Explicit93からALGORITHM IDをインポートします。iso(1)の特定された組織(3)のdod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)のイドのpkix1の明白な93(3)

     KeaPublicKey ALGORITHM-ID ::=  { OID id-keyExchangeAlgorithm
                                     PARMS KEA-Parms-Id }

KeaPublicKey ALGORITHM ID:、:= OIDイド-keyExchangeAlgorithm PARMSケアParmsイド

      id-keyExchangeAlgorithm  OBJECT IDENTIFIER   ::=
             { 2 16 840 1 101 2 1 1 22 }

イド-keyExchangeAlgorithmオブジェクト識別子:、:= { 2 16 840 1 101 2 1 1 22 }

      KEA-Parms-Id     ::= OCTET STRING

ケアParmsイド:、:= 八重奏ストリング

   END

終わり

5. References

5. 参照

   [KEA]      "Skipjack and KEA Algorithm Specification", Version 2.0,
              29 May 1998. available from
              http://csrc.nist.gov/encryption/skipjack-kea.htm

[KEA] 「トビウオの類とケアアルゴリズム仕様」、バージョン2.0、 http://csrc.nist.gov/encryption/skipjack-kea.htm から空いている1998年5月29日

   [SDN.701R] SDN.701, "Message Security Protocol", Revision 4.0
              1996-06-07 with "Corrections to Message Security Protocol,
              SDN.701, Rev 4.0, 96-06-07." August 30, 1996.

[SDN.701R]SDN.701、「メッセージセキュリティプロトコル」、改正、「メッセージセキュリティプロトコル、SDN.701、回転4.0、96-06-07への修正」がある4.0 1996年6月7日。 1996年8月30日。

   [RFC 2459] Housley, R., Ford, W., Polk, W. and D. Solo "Internet
              X.509 Public Key Infrastructure: X.509 Certificate and CRL
              Profile", RFC 2459, January 1999.

[RFC2459]のHousley、R.、フォード、W.、ポーク、W.、およびD.が独奏される、「インターネットX.509公開鍵基盤:」 「X.509証明書とCRLプロフィール」、RFC2459、1月1999日

Housley & Polk               Informational                      [Page 6]

RFC 2528                        PKIX KEA                      March 1999

1999年の[6ページ]RFC2528PKIXケア行進の情報のHousleyとポーク

6. Security Considerations

6. セキュリティ問題

   This specification is devoted to the format and encoding of KEA keys
   in X.509 certificates.  Since certificates are digitally signed, no
   additional integrity service is necessary. Certificates need not be
   kept secret, and unrestricted and anonymous access to certificates
   and CRLs has no security implications.

この仕様はX.509証明書における、KEAキーの形式とコード化にささげられます。 証明書がデジタルに署名されるので、どんな追加保全サービスも必要ではありません。 証明書は秘密にされる必要はありません、そして、証明書とCRLsへの無制限で匿名のアクセスには、セキュリティ意味が全くありません。

   However, security factors outside the scope of this specification
   will affect the assurance provided to certificate users.  This
   section highlights critical issues that should be considered by
   implementors, administrators, and users.

しかしながら、この仕様の範囲の外のセキュリティ要素はユーザを証明するために提供された保証に影響するでしょう。 このセクションは作成者、管理者、およびユーザによって考えられるべきである重要な問題を強調します。

   The procedures performed by CAs and RAs to validate the binding of
   the subject's identity of their public key greatly affect the
   assurance that should be placed in the certificate.  Relying parties
   may wish to review the CA's certificate practice statement.

彼らの公開鍵に関する対象のアイデンティティの結合を有効にするためにCAsとRAsによって実行された手順は証明書に置かれるべきである保証に大いに影響します。 信用パーティーはCAの証明書習慣声明を批評したがっているかもしれません。

   The protection afforded private keys is a critical factor in
   maintaining security.  Failure of users to protect their KEA private
   keys will permit an attacker to masquerade as them, or decrypt their
   personal information.

秘密鍵が提供された保護は警備を維持することにおいて重要な要素です。 ユーザが彼らのKEA秘密鍵を保護しないと、攻撃者がそれらのふりをすることを許可するか、またはそれらの個人情報を解読するでしょう。

   The availability and freshness of revocation information will affect
   the degree of assurance that should be placed in a certificate.

取消し情報の有用性と新しさは証明書に置かれるべきである保証の度合いに影響するでしょう。

   While certificates expire naturally, events may occur during its
   natural lifetime which negate the binding between the subject and
   public key.  If revocation information is untimely or unavailable,
   the assurance associated with the binding is clearly reduced.
   Similarly, implementations of the Path Validation mechanism described
   in section 6 that omit revocation checking provide less assurance
   than those that support it.

証明書は自然に期限が切れますが、イベントは生まれながらの生涯起こるかもしれません(対象と公開鍵の間の結合を否定します)。 取消し情報がタイミングが悪いか、または入手できないなら、結合に関連している保証は明確に抑えられます。 同様に、取消しの照合を省略するセクション6で説明されたPath Validationメカニズムの実装はそれをサポートするものより少ない保証を提供します。

   The path validation algorithm specified in [RFC 2459] depends on the
   certain knowledge of the public keys (and other information) about
   one or more trusted CAs. The decision to trust a CA is an important
   decision as it ultimately determines the trust afforded a
   certificate.  The authenticated distribution of trusted CA public
   keys (usually in the form of a "self-signed" certificate) is a
   security critical out of band process that is beyond the scope of
   this specification.

[RFC2459]で指定された経路合法化アルゴリズムは公開鍵(そして、他の情報)のおよそ1かさらに信じられたCAsに関する、ある知識によります。 結局証明書が提供された信頼を決定するとき、カリフォルニアを信じるという決定は重要な決定です。 信じられたカリフォルニア公開鍵(通常、「自己によって署名している」証明書の形の)の認証された分配はこの仕様の範囲にあるバンドプロセスから重要なセキュリティです。

   In addition, where a key compromise or CA failure occurs for a
   trusted CA, the user will need to modify the information provided to
   the path validation routine.  Selection of too many trusted CAs will
   make the trusted CA information difficult to maintain.  On the other
   hand, selection of only one trusted CA may limit users to a closed

さらに、主要な感染かカリフォルニアの失敗が信じられたカリフォルニアに起こるところでは、ユーザは、経路合法化ルーチンに提供された情報を変更する必要があるでしょう。 あまりに多くの信じられたCAsの品揃えは信じられたカリフォルニアを維持するのが難しい情報にするでしょう。 他方では、ある信じられたカリフォルニアだけの選択はユーザを閉じられたaに制限するかもしれません。

Housley & Polk               Informational                      [Page 7]

RFC 2528                        PKIX KEA                      March 1999

1999年の[7ページ]RFC2528PKIXケア行進の情報のHousleyとポーク

   community of users until a global PKI emerges.

グローバルなPKIまでのユーザの共同体は現れます。

   The quality of implementations that process certificates may also
   affect the degree of assurance provided.  The path validation
   algorithm described in section 6 relies upon the integrity of the
   trusted CA information, and especially the integrity of the public
   keys associated with the trusted CAs.  By substituting public keys
   for which an attacker has the private key, an attacker could trick
   the user into accepting false certificates.

また、証明書を処理する実装の品質は提供された保証の度合いに影響するかもしれません。 セクション6で説明された経路合法化アルゴリズムは信じられたカリフォルニア情報の保全、および特に信じられたCAsに関連している公開鍵の保全を当てにします。 攻撃者が秘密鍵を持っている公開鍵を代入することによって、攻撃者は、ユーザが偽の証明書を受け入れるようにだますことができるでしょう。

   The binding between a key and certificate subject cannot be stronger
   than the cryptographic module implementation and algorithms used to
   generate the signature.

キーと証明書対象の間の結合は暗号のモジュール実装とアルゴリズムが以前はよく署名を生成していたより強いはずがありません。

7. Authors' Addresses

7. 作者のアドレス

   Russell Housley
   SPYRUS
   381 Elden Street
   Suite 1120
   Herndon, VA 20170
   USA

ラッセルHousley SPYRUS381エルデン・通りスイート1120ヴァージニア20170ハーンドン(米国)

   EMail: housley@spyrus.com

メール: housley@spyrus.com

   Tim Polk
   NIST
   Building 820, Room 426
   Gaithersburg, MD 20899
   USA

MD20899ゲイザースバーグ(米国)を820、部屋426に造るティムポークNIST

   EMail: wpolk@nist.gov

メール: wpolk@nist.gov

Housley & Polk               Informational                      [Page 8]

RFC 2528                        PKIX KEA                      March 1999

1999年の[8ページ]RFC2528PKIXケア行進の情報のHousleyとポーク

8.  Full Copyright Statement

8. 完全な著作権宣言文

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

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

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

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Housley & Polk               Informational                      [Page 9]

HousleyとポークInformationalです。[9ページ]