RFC1424 日本語訳

Network Working Group                                         B. Kaliski
Request for Comments: 1424                              RSA Laboratories
                                                           February 1993

Kaliskiがコメントのために要求するワーキンググループB.をネットワークでつないでください: 1424 RSA研究所1993年2月

           Privacy Enhancement for Internet Electronic Mail:
            Part IV: Key Certification and Related Services

インターネット電子メールのためのプライバシー増進: パートIV: 主要な証明と関連サービス

Status of this Memo

このMemoの状態

   This RFC specifies an IAB standards track protocol for the Internet
   community, and requests discussion and suggestions for improvements.
   Please refer to the current edition of the "IAB Official Protocol
   Standards" for the standardization state and status of this protocol.
   Distribution of this memo is unlimited.

このRFCはIAB標準化過程プロトコルをインターネットコミュニティに指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。

Acknowledgements

承認

   This document is the product of many discussions at RSA Data
   Security, at Trusted Information Systems, and on the <pem-
   dev@tis.com> mailing list.  Contributors include Dave Balenson, Jim
   Bidzos, Pat Cain, Vint Cerf, Pam Cochrane, Steve Dusse, Jeff Fassett,
   Craig Finseth, Jim Galvin, Mike Indovina, Bob Jueneman, Steve Kent,
   John Lowry, Paul McKenney, Jeff Thompson, and Charles Wu.  This
   document is the product of the Privacy-Enhanced Electronic Mail
   Working Group.

このドキュメントがRSA Data SecurityにおけるTrusted情報システムにおける<pem- dev@tis.com についての多くの議論の成果である、gt;、メーリングリスト。 貢献者はデーヴBalenson、ジム・ビゾス、パット・カイン、Vintサーフ、パム・コークラン、スティーブDusse、ジェフ・ファセット、クレイグFinseth、ジム・ガルビン、マイクIndovina、ボブJueneman、スティーブ・ケント、ジョン・ロウリー、ポールMcKenney、ジェフトンプソン、およびチャールズ・ウーを入れます。 このドキュメントはPrivacyによって高められたElectronicメール作業部会の製品です。

1. Executive Summary

1. 要約

   This document describes three types of service in support of Internet
   Privacy-Enhanced Mail (PEM) [1-3]: key certification, certificate-
   revocation list (CRL) storage, and CRL retrieval. Such services are
   among those required of an RFC 1422 [2] certification authority.
   Other services such as certificate revocation and certificate
   retrieval are left to the certification authority to define, although
   they may be based on the services described in this document.

このドキュメントはインターネットのPrivacyによって高められたメール(PEM)[1-3]を支持して3つのタイプのサービスについて説明します: 主要な証明、証明書取消しリスト(CRL)ストレージ、およびCRL検索。 そのようなサービスがRFC1422[2]証明権威について必要であるものにあります。 証明書取消しや証明書検索などの他のサービスが定義するのが証明権威に残されます、本書では説明されたサービスに基づくかもしれませんが。

   Each service involves an electronic-mail request and an electronic-
   mail reply. The request is either an RFC 1421 [1] privacy-enhanced
   message or a message with a new syntax defined in this document. The
   new syntax follows the general RFC 1421 syntax but has a different
   process type, thereby distinguishing it from ordinary privacy-
   enhanced messages. The reply is either an RFC 1421 privacy-enhanced
   message, or an ordinary unstructured message.

各サービスは電子メール要求と電子メール回答にかかわります。 要求は、RFC1421の[1]のプライバシーで高められたメッセージか新しい構文が本書では定義されているメッセージのどちらかです。 新しい構文によって、1421年の一般的なRFC構文に従いますが、異なったプロセスはタイプされます、その結果、普通のプライバシーとそれを区別すると、メッセージが高められました。 回答は、RFC1421のプライバシーで高められたメッセージか普通の不統一なメッセージのどちらかです。

   Replies that are privacy-enhanced messages can be processed like any
   other privacy-enhanced message, so that the new certificate or the
   retrieved CRLs can be inserted into the requestor's database during

いかなる他のプライバシーで高められたメッセージのようにもプライバシーで高められたメッセージである回答は処理できます、新しい証明書か検索されたCRLsを要請者のデータベースに挿入できるように

Kaliski                                                         [Page 1]

RFC 1424        Key Certification and Related Services     February 1993

Kaliski[1ページ]RFC1424の主要な証明と関連サービス1993年2月

   normal privacy-enhanced mail processing.

通常のプライバシーで高められたメール処理。

   Certification authorities may also require non-electronic forms of
   request and may return non-electronic replies. It is expected that
   descriptions of such forms, which are outside the scope of this
   document, will be available through a certification authority's
   "information" service.

証明当局は、また、要求の非電子申込書を必要として、非電子の回答を返すかもしれません。 このドキュメントの範囲の外にあるそのような形式の記述が証明権威の「情報」サービスで利用可能になると予想されます。

2. Overview of Services

2. サービスの概要

   This section describes the three services in general terms.

このセクションはあいまいな言葉で3つのサービスについて説明します。

   The electronic-mail address to which requests are sent is left to the
   certification authority to specify. It is expected that certification
   authorities will advertise their addresses as part of an
   "information" service. Replies are sent to the address in the
   "Reply-To:" field of the request, and if that field is omitted, to
   the address in the "From:" field.

要求が送られる電子メールアドレスは指定する証明権威に残されます。 証明当局が「情報」サービスの一部として彼らのアドレスの広告を出すと予想されます。 「Reply-To」のアドレスに回答を送ります。 要求、その分野が省略される「From:」のアドレスへの分野 さばきます。

2.1 Key Certification

2.1 主要な証明

   The key-certification service signs a certificate containing a
   specified subject name and public key. The service takes a
   certification request (see Section 3.1), signs a certificate
   constructed from the request, and returns a certification reply (see
   Section 3.2) containing the new certificate.

主要な証明サービスは指定主語名と公開鍵を含む証明書に署名します。 新しい証明書を含んでいて、サービスは、証明要求を取って(セクション3.1を見ます)、要求から構成された証明書に署名して、証明回答を返します(セクション3.2を見ます)。

   The certification request specifies the requestor's subject name and
   public key in the form of a self-signed certificate. The
   certification request contains two signatures, both computed with the
   requestor's private key:

証明要求は自己署名入りの証書の形で要請者の対象の名前と公開鍵を指定します。 証明要求は2つの署名、要請者の秘密鍵で計算された両方を含んでいます:

     1.   The signature on the self-signed certificate, having the
          cryptographic purpose of preventing a requestor from
          requesting a certificate with another party's public key.
          (See Section 4.)

1. 要請者が別のパーティーの公開鍵で証明書を要求するのを防ぐ暗号の目的を持っている自己署名入りの証書における署名。 (セクション4を見てください。)

     2.   A signature on some encapsulated text, having the
          practical purpose of allowing the certification authority
          to construct an ordinary RFC 1421 privacy-enhanced
          message as a reply, with user-friendly encapsulated text.
          (RFC 1421 does not provide for messages with
          certificates but no encapsulated text; and the self-
          signed certificate is not "user friendly" text.) The text
          should be something innocuous like "Hello world!"

2. テキストであるとカプセル化されたいくつかにおける署名、普通のRFCを組み立てる証明権威を許容する実用的な目的を持っていて、aとしての1421年のプライバシーで高められたメッセージは返答します、ユーザフレンドリーなカプセル化されたテキストで。 (RFC1421は証明書があるメッセージではなく、カプセル化されたテキストに全く備えません; そして、自己署名入りの証書は「ユーザフレンドリーな」テキストではありません。) テキストが何かであるべきであること無毒であることのもの、「こんにちは、世界!、」

   A requestor would typically send a certification request after
   generating a public-key/private-key pair, but may also do so after a

要請者は、公開鍵/秘密鍵組を生成した後に証明要求を通常送るでしょうが、また、それほど後にaをするかもしれません。

Kaliski                                                         [Page 2]

RFC 1424        Key Certification and Related Services     February 1993

Kaliski[2ページ]RFC1424の主要な証明と関連サービス1993年2月

   change in the requestor's distinguished name.

要請者の分類名では、変化してください。

   A certification authority signs a certificate only if both signatures
   in the certification request are valid.

証明要求における両方の署名が有効である場合にだけ、証明権威は証明書に署名します。

   The new certificate contains the subject name and public key from the
   self-signed certificate, and an issuer name, serial number, validity
   period, and signature algorithm of the certification authority's
   choice. (The validity period may be derived from the self-signed
   certificate.) Following RFC 1422, the issuer may be any whose
   distinguished name is superior to the subject's distinguished name,
   typically the one closest to the subject. The certification authority
   signs the certificate with the issuer's private key, then transforms
   the request into a reply containing the new certificate (see Section
   3.2 for details).

新しい証明書は証明権威の選択の自己署名入りの証書からの対象の名前と公開鍵、発行人名、通し番号、有効期間、および署名アルゴリズムを含んでいます。 (自己署名入りの証書から有効期間を得るかもしれません。) RFC1422に続いて、分類名が対象の分類名、通常ものより優れているいずれか対象に最も近かったなら、発行人は続きます。 証明権威は、発行人の秘密鍵を証明書と契約して、次に、要求を新しい証明書を含む回答に変えます(詳細に関してセクション3.2を見てください)。

   The certification reply includes a certification path from the new
   certificate to the RFC 1422 Internet certification authority. It may
   also include other certificates such as cross-certificates that the
   certification authority considers helpful to the requestor.

証明回答は新しい証明書からRFC1422インターネット証明権威までの証明経路を含んでいます。 また、それは証明権威が要請者にとって役立っていると考える交差している証明書などの他の証明書を含むかもしれません。

2.2 CRL Storage

2.2 CRLストレージ

   The CRL storage service stores CRLs. The service takes a CRL-storage
   request (see Section 3.3) specifying the CRLs to be stored, stores
   the CRLs, and returns a CRL-storage reply (see Section 3.4)
   acknowledging the request.

CRLストレージサービスはCRLsを保存します。 サービスは、要求を承諾しながら、保存されるためにCRLsを指定しながらCRL-ストレージ要求を取って(セクション3.3を見ます)、CRLsを保存して、CRL-ストレージ回答を返します(セクション3.4を見ます)。

   The certification authority stores a CRL only if its signature and
   certification path are valid, following concepts in RFC 1422
   (Although a certification path is not required in a CRL-storage
   request, it may help the certification authority validate the CRL.)

RFC1422の概念に従って、その署名と証明経路が有効である場合にだけ、証明権威はCRLを保存します。(証明経路はCRL-ストレージ要求で必要ではありませんが、それは、証明権威がCRLを有効にするのを助けるかもしれません。)

2.3 CRL Retrieval

2.3 CRL検索

   The CRL retrieval service retrieves the latest CRLs of specified
   certificate issuers. The service takes a CRL-retrieval request (see
   Section 3.5), retrieves the latest CRLs the request specifies, and
   returns a CRL-retrieval reply (see Section 3.6) containing the CRLs.

CRL検索サービスは指定された証明書発行人の最新のCRLsを検索します。 CRLsを含んでいて、サービスは、CRL-検索要求(セクション3.5を見る)を取って、要求が指定する最新のCRLsを検索して、CRL-検索回答を返します(セクション3.6を見ます)。

   There may be more than one "latest" CRL for a given issuer, if that
   issuer has more than one public key (see RFC 1422 for details).

与えられた発行人のための1「最新」のCRLがあるかもしれません、その発行人に1つ以上の公開鍵があるなら(詳細に関してRFC1422を見てください)。

   The CRL-retrieval reply includes a certification path from each
   retrieved CRL to the RFC 1422 Internet certification authority. It
   may also include other certificates such as cross-certificates that
   the certification authority considers helpful to the requestor.

CRL-検索回答はそれぞれの検索されたCRLから1422年のRFCインターネット証明権威までの証明経路を含んでいます。 また、それは証明権威が要請者にとって役立っていると考える交差している証明書などの他の証明書を含むかもしれません。

Kaliski                                                         [Page 3]

RFC 1424        Key Certification and Related Services     February 1993

Kaliski[3ページ]RFC1424の主要な証明と関連サービス1993年2月

3. Syntax

3. 構文

   This section describes the syntax of requests and replies for the
   three services, giving simple examples.

簡単な例を出して、このセクションは3つのサービスのための要求と回答の構文について説明します。

3.1 Certification request

3.1 証明要求

   A certification request is an RFC 1421 MIC-ONLY or MIC-CLEAR
   privacy-enhanced message containing a self-signed certificate. There
   is only one signer.

証明要求は自己署名入りの証書を含むRFC1421ミックだけかミック-CLEARのプライバシーで高められたメッセージです。 1つの署名者しかありません。

   The fields of the self-signed certificate (which has type
   Certificate, as in RFC 1422) are as follows:

自己署名入りの証書(RFC1422のようにタイプCertificateを持っている)の分野は以下の通りです:

     version is 0

バージョンは0です。

     serialNumber is arbitrary; the value 0 is suggested unless the
          certification authority specifies otherwise

serialNumberは任意です。 証明権威が別の方法で指定しない場合、値0は示されます。

     signature is the algorithm by which the self-signed
          certificate is signed; it need not be the same as the
          algorithm by which the requested certificate is to be
          signed

署名は自己署名入りの証書が署名されるアルゴリズムです。 それは署名される要求された証明書がことであるアルゴリズムと同じである必要はありません。

     issuer is the requestor's distinguished name

発行人は要請者の分類名です。

     validity is arbitrary; the value with start and end both at
          12:00am GMT, January 1, 1970, is suggested unless the
          certification authority specifies otherwise

正当性は任意です。 証明権威が別の方法で指定しない場合、ともに始めと終わりグリニッジ標準時午前12時0分の値(1970年1月1日)は示されます。

     subject is the requestor's distinguished name

対象は要請者の分類名です。

     subjectPublicKeyInfo is the requestor's public key

subjectPublicKeyInfoは要請者の公開鍵です。

   The requestor's MIC encryption algorithm must be asymmetric (e.g.,
   RSA) and the MIC algorithm must be keyless (e.g., RSA-MD2, not MAC),
   so that anyone can verify the signature.

要請者のMIC暗号化アルゴリズムは非対称であるに違いありません、そして、(例えば、RSA)MICアルゴリズムはキーがないに違いありません(例えば、MACではなく、RSA-MD2)、だれでも署名について確かめることができるように。

Kaliski                                                         [Page 4]

RFC 1424        Key Certification and Related Services     February 1993

Kaliski[4ページ]RFC1424の主要な証明と関連サービス1993年2月

   Example:

例:

   To: cert-service@ca.domain
   From: requestor@host.domain

To: cert-service@ca.domain From: requestor@host.domain

   -----BEGIN PRIVACY-ENHANCED MESSAGE-----
   Proc-Type: 4,MIC-ONLY
   Content-Domain: RFC822
   Originator-Certificate: <requestor's self-signed certificate>
   MIC-Info: RSA,RSA-MD2,<requestor's signature on text>

-----プライバシーで高められたメッセージを始めてください。----- Proc-タイプ: 4 ミックだけの満足しているDomain: RFC822創始者証明書: <要請者は証明書>MIC-インフォメーションであると自己に署名されました: RSA、RSA-MD2、テキスト>における<要請者の署名

   <text>
   -----END PRIVACY-ENHANCED MESSAGE-----

<テキスト>。-----プライバシーで高められたメッセージを終わらせてください。-----

3.2 Certification reply

3.2 証明回答

   A certification reply is an RFC 1421 MIC-ONLY or MIC-CLEAR privacy-
   enhanced message containing a new certificate, its certification path
   to the RFC 1422 Internet certification authority, and possibly other
   certificates. There is only one signer. The "MIC-Info:" field and
   encapsulated text are taken directly from the certification request.
   The reply has the same process type (MIC-ONLY or MIC-CLEAR) as the
   request.

証明回答はRFC1421ミックにすぎませんかミック-CLEARプライバシーが新しい証明書、1422年のRFCインターネット証明権威への証明経路を含むメッセージとことによると他の証明書を高めました。 1つの署名者しかありません。 「MIC-インフォメーション:」 グラウンドとカプセル化されたテキストは直接証明要求から抜粋されます。 回答で、同じプロセスは要求として(ミックだけかミック-CLEAR)をタイプします。

   Since the reply is an ordinary privacy-enhanced message, the new
   certificate can be inserted into the requestor's database during
   normal privacy-enhanced mail processing. The requestor can forward
   the reply to other requestors to disseminate the certificate.

回答が普通のプライバシーで高められたメッセージであるので、通常のプライバシーで高められたメール処理の間、新しい証明書を要請者のデータベースに挿入できます。 要請者は、証明書を広めるために他の要請者に回答を送ることができます。

   Example:

例:

   To: requestor@host.domain
   From: cert-service@ca.domain

To: requestor@host.domain From: cert-service@ca.domain

   -----BEGIN PRIVACY-ENHANCED MESSAGE-----
   Proc-Type: 4,MIC-ONLY
   Content-Domain: RFC822
   Originator-Certificate: <requestor's new certificate>
   Issuer-Certificate: <issuer's certificate>
   MIC-Info: RSA,RSA-MD2,<requestor's signature on text>

-----プライバシーで高められたメッセージを始めてください。----- Proc-タイプ: 4 ミックだけの満足しているDomain: RFC822創始者証明書: <要請者の新しい証明書>のIssuer-証明書: <発行人の証明書>MIC-インフォメーション: RSA、RSA-MD2、テキスト>における<要請者の署名

   <text>
   -----END PRIVACY-ENHANCED MESSAGE-----

<テキスト>。-----プライバシーで高められたメッセージを終わらせてください。-----

Kaliski                                                         [Page 5]

RFC 1424        Key Certification and Related Services     February 1993

Kaliski[5ページ]RFC1424の主要な証明と関連サービス1993年2月

3.3 CRL-storage request

3.3 CRL-ストレージ要求

   A CRL-storage request is an RFC 1421 CRL-type privacy-enhanced
   message containing the CRLs to be stored and optionally their
   certification paths to the RFC 1422 Internet certification authority.

CRL-ストレージ要求は任意に保存されるべきCRLsを含むRFC1421のCRL-タイプのプライバシーで高められたメッセージです。1422年のRFCインターネット証明権威への彼らの証明経路。

   Example:

例:

   To: cert-service@ca.domain
   From: requestor@host.domain

To: cert-service@ca.domain From: requestor@host.domain

   -----BEGIN PRIVACY-ENHANCED MESSAGE-----
   Proc-Type: 4,CRL
   CRL: <CRL to be stored>
   Originator-Certificate: <CRL issuer's certificate>
   CRL: <another CRL to be stored>
   Originator-Certificate: <other CRL issuer's certificate>
   -----END PRIVACY-ENHANCED MESSAGE-----

-----プライバシーで高められたメッセージを始めてください。----- Proc-タイプ: 4、CRL CRL: 保存された>Originator-証明書である<CRL: <CRL発行人の証明書>CRL: <は保存された>が以下をOriginator証明するということである別のCRLです。 <他のCRL発行人の証明書>。-----プライバシーで高められたメッセージを終わらせてください。-----

3.4 CRL-storage reply

3.4 CRL-ストレージ回答

   A CRL-storage reply is an ordinary message acknowledging the storage
   of CRLs. No particular syntax is specified.

CRL-ストレージ回答はCRLsのストレージを承諾することでの普通のメッセージです。 どんな特定の構文も指定されません。

3.5 CRL-retrieval request

3.5 CRL-検索要求

   A CRL-retrieval request is a new type of privacy-enhanced message,
   distinguished from RFC 1421 privacy-enhanced messages by the process
   type CRL-RETRIEVAL-REQUEST.

CRL-検索要求が新しいタイプのプライバシーで高められたメッセージである、RFCと区別されて、プロセスによる1421のプライバシーで高められたメッセージがCRL-RETRIEVAL-REQUESTをタイプします。

   The request has two or more encapsulated header fields: the required
   "Proc-Type:" field and one or more "Issuer:" fields. The fields must
   appear in the order just described. There is no encapsulated text, so
   there is no blank line separating the fields from encapsulated text.

要求で、ヘッダーフィールドであると2以上をカプセル化します: 必要は「以下をProcタイプします」。 分野と1以上、「発行人:」 分野。 野原はオーダーでただ説明されているように見えなければなりません。 テキストであることはカプセル化されないので、カプセル化されたテキストから野原を分離する空白行が、全くありません。

   Each "Issuer:" field specifies an issuer whose latest CRL is to be
   retrieved. The field contains a value of type Name specifying the
   issuer's distinguished name. The value is encoded as in an RFC 1421
   "Originator-ID-Asymmetric:" field (i.e., according to the Basic
   Encoding Rules, then in ASCII).

それぞれ、「発行人:」 分野は最新のCRLが検索されることになっている発行人を指定します。 分野は発行人の分類名を指定するタイプNameの値を含んでいます。 値がRFC1421のようにコード化される、「創始者ID非対称、:、」 さばきます(すなわち、そして、ASCIIにおけるBasic Encoding Rulesによると)。

Kaliski                                                         [Page 6]

RFC 1424        Key Certification and Related Services     February 1993

Kaliski[6ページ]RFC1424の主要な証明と関連サービス1993年2月

   Example:

例:

   To: cert-service@ca.domain
   From: requestor@host.domain

To: cert-service@ca.domain From: requestor@host.domain

   -----BEGIN PRIVACY-ENHANCED MESSAGE-----
   Proc-Type: 4,CRL-RETRIEVAL-REQUEST
   Issuer: <issuer whose latest CRL is to be retrieved>
   Issuer: <another issuer whose latest CRL is to be retrieved>
   -----END PRIVACY-ENHANCED MESSAGE-----

-----プライバシーで高められたメッセージを始めてください。----- Proc-タイプ: 4 CRL検索要求発行人: 最新のCRLによる検索された>Issuerである<発行人: <は最新のCRLによる検索された>である別の発行人です。-----プライバシーで高められたメッセージを終わらせてください。-----

3.6 CRL-retrieval reply

3.6 CRL-検索回答

   A CRL-retrieval reply is an RFC 1421 CRL-type privacy-enhanced
   message containing retrieved CRLs, their certification paths to the
   RFC 1422 Internet certification authority, and possibly other
   certificates.

CRL-検索回答は、検索されたCRLs、1422年のRFCインターネット証明権威への彼らの証明経路を含むRFC1421のCRL-タイプのプライバシーで高められたメッセージとことによると他の証明書です。

   Since the reply is an ordinary privacy-enhanced message, the
   retrieved CRLs can be inserted into the requestor's database during
   normal privacy-enhanced mail processing. The requestor can forward
   the reply to other requestors to disseminate the CRLs.

回答が普通のプライバシーで高められたメッセージであるので、通常のプライバシーで高められたメール処理の間、検索されたCRLsを要請者のデータベースに挿入できます。 要請者は、CRLsを広めるために他の要請者に回答を送ることができます。

   Example:

例:

   To: requestor@host.domain
   From: cert-service@ca.domain

To: requestor@host.domain From: cert-service@ca.domain

   -----BEGIN PRIVACY-ENHANCED MESSAGE-----
   Proc-Type: 4,CRL
   CRL: <issuer's latest CRL>
   Originator-Certificate: <issuer's certificate>
   CRL: <other issuer's latest CRL>
   Originator-Certificate: <other issuer's certificate>
   -----END PRIVACY-ENHANCED MESSAGE-----

-----プライバシーで高められたメッセージを始めてください。----- Proc-タイプ: 4、CRL CRL: <発行人の最新のCRL>Originator-証明書: <発行人の証明書>CRL: <他の発行人の最新のCRL>Originator-証明書: <他の発行人の証明書>。-----プライバシーで高められたメッセージを終わらせてください。-----

Patent Statement

特許声明

   This version of Privacy Enhanced Mail (PEM) relies on the use of
   patented public key encryption technology for authentication and
   encryption.  The Internet Standards Process as defined in RFC 1310
   requires a written statement from the Patent holder that a license
   will be made available to applicants under reasonable terms and
   conditions prior to approving a specification as a Proposed, Draft or
   Internet Standard.

Privacy Enhancedメール(PEM)のこのバージョンは特許をとられた公開鍵暗号技術の認証と暗号化の使用に依存します。 RFC1310で定義されるインターネットStandards ProcessはPatent所有者からのProposed、DraftまたはインターネットStandardとして仕様を承認する前に無理のない条件と条件のもとでライセンスを応募者にとって利用可能にするという書かれた声明を必要とします。

Kaliski                                                         [Page 7]

RFC 1424        Key Certification and Related Services     February 1993

Kaliski[7ページ]RFC1424の主要な証明と関連サービス1993年2月

   The Massachusetts Institute of Technology and the Board of Trustees
   of the Leland Stanford Junior University have granted Public Key
   Partners (PKP) exclusive sub-licensing rights to the following
   patents issued in the United States, and all of their corresponding
   foreign patents:

リーランドスタンフォードジュニア大学のTrusteesのマサチューセッツ工科大学とBoardは合衆国で発行された以下の特許への権利、およびそれらの対応する外国特許のすべてをPublic Key Partners(PKP)の排他的なサブ認可に与えました:

      Cryptographic Apparatus and Method
      ("Diffie-Hellman")............................... No. 4,200,770

暗号の装置とメソッド(「ディフィー-ヘルマン」)… No.4,200,770

      Public Key Cryptographic Apparatus
      and Method ("Hellman-Merkle").................... No. 4,218,582

公開鍵の暗号の装置とメソッド(「ヘルマン-Merkle」)… No.4,218,582

      Cryptographic Communications System and
      Method ("RSA")................................... No. 4,405,829

暗号の通信網とメソッド("RSA")… No.4,405,829

      Exponential Cryptographic Apparatus
      and Method ("Hellman-Pohlig").................... No. 4,424,414

指数の暗号の装置とメソッド(「ヘルマン-Pohlig」)… No.4,424,414

   These patents are stated by PKP to cover all known methods of
   practicing the art of Public Key encryption, including the variations
   collectively known as El Gamal.

これらの特許はPublic Key暗号化の芸術を実施するすべての知られているメソッドをカバーするためにPKPによって述べられています、El Gamalとして一括して知られている変化を含んでいて。

   Public Key Partners has provided written assurance to the Internet
   Society that parties will be able to obtain, under reasonable,
   nondiscriminatory terms, the right to use the technology covered by
   these patents.  This assurance is documented in RFC 1170 titled
   "Public Key Standards and Licenses".  A copy of the written assurance
   dated April 20, 1990, may be obtained from the Internet Assigned
   Number Authority (IANA).

公共のKey Partnersはパーティーが妥当なnondiscriminatory諸条件でこれらの特許でカバーされた技術を使用する権利を得ることができるというインターネット協会への書かれた保証を提供しました。 この保証は「公開鍵規格とライセンス」と題をつけられたRFC1170に記録されます。 ISOCの機関の一つで(IANA)から書かれた1990年4月20日付けの保証のコピーを入手するかもしれません。

   The Internet Society, Internet Architecture Board, Internet
   Engineering Steering Group and the Corporation for National Research
   Initiatives take no position on the validity or scope of the patents
   and patent applications, nor on the appropriateness of the terms of
   the assurance.  The Internet Society and other groups mentioned above
   have not made any determination as to any other intellectual property
   rights which may apply to the practice of this standard. Any further
   consideration of these matters is the user's own responsibility.

インターネット協会、インターネット・アーキテクチャ委員会、インターネットEngineering Steering Group、およびNational Research Initiativesのための社は特許と特許出願の正当性か範囲の上と、そして、保証に関する諸条件の適切さの上の立場を全く取りません。 前記のようにインターネット協会と他のグループはこの規格の習慣に申請されるかもしれないいかなる他の知的所有権に関しても少しの決断もしていません。 これらの件のどんなさらなる考慮もユーザの自己の責任です。

Security Considerations

セキュリティ問題

   The self-signed certificate (Section 3.1) prevents a requestor from
   requesting a certificate with another party's public key. Such an
   attack would give the requestor the minor ability to pretend to be
   the originator of any message signed by the other party. This attack
   is significant only if the requestor does not know the message being
   signed, and the signed part of the message does not identify the
   signer. The requestor would still not be able to decrypt messages

自己署名入りの証書(セクション3.1)は、要請者が別のパーティーの公開鍵で証明書を要求するのを防ぎます。 そのような攻撃は相手によって署名されたどんなメッセージの創始者であるもふりをする小さい方の能力を要請者に与えるでしょう。 要請者が署名されるメッセージを知らない場合にだけ、この攻撃は重要です、そして、メッセージの署名している部分は署名者を特定しません。 要請者はまだメッセージを解読することができないでしょう。

Kaliski                                                         [Page 8]

RFC 1424        Key Certification and Related Services     February 1993

Kaliski[8ページ]RFC1424の主要な証明と関連サービス1993年2月

   intended for the other party, of course.

もう片方のために意図して、パーティーへ行ってください、もちろん。

References

参照

   [1] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part
       I: Message Encryption and Authentication Procedures", RFC 1421,
       DEC, February 1993.

[1] リン、J.、「インターネット電子メールのためのプライバシー増進:」 部分I: 「メッセージ暗号化と認証手順」、RFC1421、12月、2月1993

   [2] Kent, S., "Privacy Enhancement for Internet Electronic Mail: Part
       II: Certificate-Based Key Management", RFC 1422, BBN, February
       1993.

[2] ケント、S.、「インターネット電子メールのためのプライバシー増進:」 パートII: 「証明書ベースのKey Management」、RFC1422、BBN、1993年2月。

   [3] Balenson, D., "Privacy Enhancement for Internet Electronic Mail:
       Part III: Algorithms, Modes, and Identifiers", RFC 1423, TIS,
       February 1993.

[3]Balenson、D.、「インターネット電子メールのためのプライバシー増進:」 パートIII: 「アルゴリズム、モード、および識別子」、RFC1423、TIS、2月1993日

Author's Address

作者のアドレス

       Burton S. Kaliski, Jr.
       RSA Laboratories (a division of RSA Data Security, Inc.)
       10 Twin Dolphin Drive
       Redwood City, CA  94065

バートンS.Kaliski、Jr.RSA研究所(RSA Data Security Inc.の師団) 10 Driveレッドウッドシティー、双子のDolphinカリフォルニア 94065

       Phone: (415) 595-7703
       FAX: (415) 595-4126
       EMail: burt@rsa.com

以下に電話をしてください。 (415) 595-7703 Fax: (415) 595-4126 メールしてください: burt@rsa.com

Kaliski                                                         [Page 9]

Kaliski[9ページ]