RFC1423 日本語訳

1423 Privacy Enhancement for Internet Electronic Mail: Part III:Algorithms, Modes, and Identifiers. D. Balenson. February 1993. (Format: TXT=33277 bytes) (Obsoletes RFC1115) (Status: HISTORIC)
プログラムでの自動翻訳です。
RFC一覧
英語原文

Network Working Group                                        D. Balenson
Request for Comments: 1423                                           TIS
Obsoletes: 1115                               IAB IRTF PSRG, IETF PEM WG
                                                           February 1993

Balensonがコメントのために要求するワーキンググループD.をネットワークでつないでください: 1423TISが以下を時代遅れにします。 1115IAB IRTF PSRG、IETF PEM WG1993年2月

           Privacy Enhancement for Internet Electronic Mail:
              Part III: Algorithms, Modes, and Identifiers

インターネット電子メールのためのプライバシー増進: パートIII: アルゴリズム、モード、および識別子

Status of This 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の公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。

Abstract

要約

   This document provides definitions, formats, references, and
   citations for cryptographic algorithms, usage modes, and associated
   identifiers and parameters used in support of Privacy Enhanced Mail
   (PEM) in the Internet community.  It is intended to become one member
   of the set of related PEM RFCs.  This document is organized into four
   primary sections, dealing with message encryption algorithms, message
   integrity check algorithms, symmetric key management algorithms, and
   asymmetric key management algorithms (including both asymmetric
   encryption and asymmetric signature algorithms).

このドキュメントはインターネットコミュニティのPrivacy Enhancedメール(PEM)を支持して使用される暗号アルゴリズム、用法モード、関連識別子、およびパラメタのための定義、形式、参照、および引用を提供します。 関連するPEM RFCsのセットの1人のメンバーになるのは意図しています。 このドキュメントは4つの第一のセクションへまとめられます、メッセージ暗号化アルゴリズム、メッセージの保全チェックアルゴリズム、左右対称のかぎ管理アルゴリズム、および非対称のかぎ管理アルゴリズムに対処して(非対称の暗号化と非対称の署名アルゴリズムの両方を含んでいて)。

   Some parts of this material are cited by other documents and it is
   anticipated that some of the material herein may be changed, added,
   or replaced without affecting the citing documents.  Therefore,
   algorithm-specific material has been placed into this separate
   document.

この材料のいくつかの一部分が他のドキュメントによって引用されて、ここに引用ドキュメントに影響しないで何らかの材料を変えるか、加えるか、または取り替えるかもしれないと予期されます。 したがって、アルゴリズム特有の材料はこの別々のドキュメントに置かれました。

   Use of other algorithms and/or modes will require case-by-case study
   to determine applicability and constraints.  The use of additional
   algorithms may be documented first in Prototype or Experimental RFCs.
   As experience is gained, these protocols may be considered for
   incorporation into the standard.  Additional algorithms and modes
   approved for use in PEM in this context will be specified in
   successors to this document.

他のアルゴリズム、そして/または、モードの使用は、適用性と規制を決定するためにその場その場の研究を必要とするでしょう。 追加アルゴリズムの使用は最初に、PrototypeかExperimental RFCsに記録されるかもしれません。 経験が獲得していて、これらのプロトコルが規格への編入のために考えられるかもしれないということであるので。 PEMにおける使用のために承認された追加アルゴリズムとモードはこのドキュメントの後継者でこのような関係においては指定されるでしょう。

Acknowledgments

承認

   This specification was initially developed by the Internet Research
   Task Force's Privacy and Security Research Group (IRTF PSRG) and
   subsequently refined based on discussion in the Internet Engineering

この仕様は、初めは、インターネットResearch Task ForceのPrivacyとSecurity Research Group(IRTF PSRG)によって開発されて、次に、インターネットEngineeringでの議論に基づいて洗練されました。

Balenson                                                        [Page 1]

RFC 1423         PEM: Algorithms, Modes and Identifiers    February 1993

Balenson[1ページ]RFC1423PEM: アルゴリズム、モード、および識別子1993年2月

   Task Force's Privacy Enhanced Mail Working Group (IETF PEM WG).  John
   Linn contributed significantly to the predecessor of this document
   (RFC 1115).  I would like to thank the members of the PSRG and PEM
   WG, as well as all participants in discussions on the "pem-
   dev@tis.com" mailing list, for their contributions to this document.

特別委員会のプライバシーはメール作業部会(IETF PEM WG)を高めました。 ジョン・リンはこのドキュメント(RFC1115)の前任者にかなり貢献しました。 PSRGとPEM WGのメンバーに感謝申し上げます、「pem dev@tis.com 」メーリングリストについての議論のすべての関係者と同様に、このドキュメントへの彼らの貢献のために。

Table of Contents

目次

      1.  Message Encryption Algorithms ....................... 2
      1.1  DES in CBC Mode (DES-CBC) .......................... 2
      2.  Message Integrity Check Algorithms .................. 4
      2.1  RSA-MD2 Message Digest Algorithm ................... 4
      2.2  RSA-MD5 Message Digest Algorithm ................... 5
      3.  Symmetric Key Management Algorithms ................. 6
      3.1  DES in ECB mode (DES-ECB) .......................... 6
      3.2  DES in EDE mode (DES-EDE) .......................... 7
      4.  Asymmetric Key Management Algorithms ................ 7
      4.1  Asymmetric Keys .................................... 7
      4.1.1  RSA Keys ......................................... 7
      4.2  Asymmetric Encryption Algorithms ..................  9
      4.2.1  RSAEncryption ...................................  9
      4.3  Asymmetric Signature Algorithms ................... 10
      4.3.1  md2WithRSAEncryption ............................ 11
      5.  Descriptive Grammar ................................ 11
      References ............................................. 12
      Patent Statement ....................................... 13
      Security Considerations ................................ 14
      Author's Address ....................................... 14

1. メッセージ暗号化アルゴリズム… 2 CBCモード(DES-CBC)による1.1DES… 2 2. メッセージの保全チェックアルゴリズム… 4 2.1RSA-MD2メッセージダイジェストアルゴリズム… 4 2.2RSA-MD5メッセージダイジェストアルゴリズム… 5 3. 対称鍵管理アルゴリズム… 6 ECBモード(DES-ECB)による3.1DES… 6 EDEモード(DES-EDE)による3.2DES… 7 4. 非対称のKey Managementアルゴリズム… 7 4.1個の非対称のキー… 7 4.1 .1 RSAキー… 7 4.2 非対称の暗号化アルゴリズム… 9 4.2 .1RSAEncryption… 9 4.3 非対称の署名アルゴリズム… 10 4.3 .1md2WithRSAEncryption… 11 5. 描写的である文法… 11の参照箇所… 12 声明の特許をとってください… 13 セキュリティ問題… 14作者のアドレス… 14

1.  Message Encryption Algorithms

1. メッセージ暗号化アルゴリズム

   This section identifies the alternative message encryption algorithms
   and modes that shall be used to encrypt message text and, when
   asymmetric key management is employed in an ENCRYPTED PEM message, for
   encryption of message signatures.  Character string identifiers are
   assigned and any parameters required by the message encryption
   algorithm are defined for incorporation in an encapsulated "DEK-
   Info:" header field.

このセクションはメッセージ・テキストをコード化するのに使用されるものとする代替のメッセージ暗号化アルゴリズムとモードを特定します、そして、非対称のかぎ管理であるときに、採用しているコネはメッセージ署名の暗号化へのENCRYPTED PEMメッセージですか? 文字列識別子が割り当てられて、メッセージ暗号化アルゴリズムによって必要とされたパラメタが編入のために中で定義される、要約、「DEKインフォメーション:」 ヘッダーフィールド。

   Only one alternative is currently defined in this category.

1つの選択肢だけが現在、このカテゴリで定義されます。

1.1  DES in CBC Mode (DES-CBC)

1.1 CBCモードによるDES(デス-CBC)

   Message text and, if required, message signatures are encrypted using
   the Data Encryption Standard (DES) algorithm in the Cipher Block
   Chaining (CBC) mode of operation.  The DES algorithm is defined in
   FIPS PUB 46-1 [1], and is equivalent to the Data Encryption Algorithm
   (DEA) provided in ANSI X3.92-1981 [2].  The CBC mode of operation of

メッセージ・テキストと必要ならメッセージ署名は、Cipher Block Chaining(CBC)運転モードでデータ暗号化規格(DES)アルゴリズムを使用することでコード化されています。 DESアルゴリズムは、FIPS PUB46-1[1]で定義されて、ANSI X3.92-1981[2]に提供されたData Encryption Algorithm(DEA)に同等です。 CBC運転モード

Balenson                                                        [Page 2]

RFC 1423         PEM: Algorithms, Modes and Identifiers    February 1993

Balenson[2ページ]RFC1423PEM: アルゴリズム、モード、および識別子1993年2月

   DES is defined in FIPS PUB 81 [3], and is equivalent to those
   provided in ANSI X3.106 [4] and in ISO IS 8372 [5].  The character
   string "DES-CBC" within an encapsulated PEM header field indicates
   the use of this algorithm/mode combination.

DESはFIPS PUB81[3]で定義されて、ANSI X3.106[4]とISO IS8372[5]に提供されたものに同等です。 要約のPEMヘッダーフィールドの中の文字列「デス-CBC」はこのアルゴリズム/モード組み合わせの使用を示します。

   The input to the DES CBC encryption process shall be padded to a
   multiple of 8 octets, in the following manner.  Let n be the length
   in octets of the input.  Pad the input by appending 8-(n mod 8)
   octets to the end of the message, each having the value 8-(n mod 8),
   the number of octets being added.  In hexadecimal, the possible
   paddings are:  01, 0202, 030303, 04040404, 0505050505, 060606060606,
   07070707070707, and 0808080808080808.  All input is padded with 1 to
   8 octets to produce a multiple of 8 octets in length.  The padding
   can be removed unambiguously after decryption.

DES CBC暗号化の過程への入力は8つの八重奏の倍数に水増しされるものとします、以下の方法で。 nが入力の八重奏で長さであることをさせてください。 8(nモッズ風の8)八重奏をメッセージの終わりに追加することによって、入力を水増ししてください、それぞれ、値8(nモッズ風の8)(加えられる八重奏の数)を持っていて 16進では、可能な詰め物は以下の通りです。 01、0202、030303、04040404、0505050505、060606060606、07070707070707、および0808080808080808。 すべての入力が1〜8つの八重奏で水増しされて、長さにおける、8つの八重奏の倍数を生産します。 復号化の明白に後に詰め物を取り除くことができます。

   The DES CBC encryption process requires a 64-bit cryptographic key.
   A new, pseudorandom key shall be generated for each ENCRYPTED PEM
   message.  Of the 64 bits, 56 are used directly by the DES CBC
   process, and 8 are odd parity bits, with one parity bit occupying the
   right-most bit of each octet.  When symmetric key management is
   employed, the setting and checking of odd parity bits is encouraged,
   since these bits could detect an error in the decryption of a DES key
   encrypted under a symmetric key management algorithm (e.g., DES ECB).
   When asymmetric key management is employed, the setting of odd parity
   bits is encouraged, but the checking of odd parity bits is
   discouraged, in order to facilitate interoperability, and since an
   error in the decryption of a DES key can be detected by other means
   (e.g., an incorrect PKCS #1 encryption-block format).  In all cases,
   the encrypted form of a DES key shall carry all 64 bits of the key,
   including the 8 parity bits, though those bits may have no meaning.

DES CBC暗号化の過程は64ビットの暗号化キーを必要とします。 新しい擬似ランダムキーはそれぞれのENCRYPTED PEMメッセージのために発生するものとします。 64ビットでは、56は直接DES CBC工程で使用されます、そして、8は奇数パリティビットです、1つのパリティビットがそれぞれの八重奏の最も権利ビットを占領していて。 これらのビットが対称鍵管理アルゴリズム(例えば、DES ECB)の下でコード化されたDESキーの復号化における誤りを検出するかもしれないので、いつ対称鍵管理が奇数パリティビットが採用していて設定と照合であるかは奨励されます。 非対称のかぎ管理が採用しているとき、奇数パリティビットの設定は奨励されますが、奇数パリティビットの点検はお勧めできないです、相互運用性を容易にして、他の手段(例えば、不正確なPKCS#1暗号化ブロックフォーマット)でDESキーの復号化における誤りは検出できるので。 すべてのケース、キーが運ぶものとするDESのコード化された形では、それらのビットですが、8つのパリティビットを含むキーのすべての64ビットは意味を持っていないかもしれません。

   The DES CBC encryption process also requires a 64-bit Initialization
   Vector (IV).  A new, pseudorandom IV shall be generated for each
   ENCRYPTED PEM message.  Section 4.3.1 of [7] provides rationale for
   this requirement, even given the fact that individual DES keys are
   generated for individual messages.  The IV is transmitted with the
   message within an encapsulated PEM header field.

また、DES CBC暗号化の過程は64ビットの初期設定Vector(IV)を必要とします。 A新しくて、擬似ランダムIVはそれぞれのENCRYPTED PEMメッセージのために発生するものとします。 セクション4.3 .1 [7]では、そんなに個々の事実をこの要件に原理を前提として、考えさえして、DESキーは個々のメッセージのために発生します。 IVは要約のPEMヘッダーフィールドの中でメッセージで伝えられます。

   When this algorithm/mode combination is used for message text
   encryption, the "DEK-Info:" header field carries exactly two
   arguments.  The first argument identifies the DES CBC algorithm/mode
   using the character string defined above.  The second argument
   contains the IV, represented as a contiguous string of 16 ASCII
   hexadecimal digits.

このアルゴリズム/モード組み合わせがメッセージ・テキスト暗号化に使用されるとき「DEK-インフォメーション:」 ヘッダーフィールドはちょうど2つの議論を運びます。 最初の議論は、上で定義された文字列を使用することでDES CBCアルゴリズム/モードを特定します。 2番目の議論は16のASCII16進数字の隣接のストリングとして表されたIVを含んでいます。

   When symmetric key management is employed with this algorithm/mode
   combination, a symmetrically encrypted DES key will be represented in
   the third argument of a "Key-Info:" header field as a contiguous

対称鍵管理がこのアルゴリズム/モード組み合わせと共に使われるとき、対称的にコード化されたDESキーがaの3番目の議論で表される、「主要なインフォメーション:」 a隣接としてのヘッダーフィールド

Balenson                                                        [Page 3]

RFC 1423         PEM: Algorithms, Modes and Identifiers    February 1993

Balenson[3ページ]RFC1423PEM: アルゴリズム、モード、および識別子1993年2月

   string of 16 ASCII hexadecimal digits (corresponding to a 64-bit
   key).

16のASCII16進数字(64ビットのキーに対応する)のストリング。

   To avoid any potential ambiguity regarding the ordering of the octets
   of a DES key that is input as a data value to another encryption
   process (e.g., RSAEncryption), the following holds true.  The first
   (or left-most displayed, if one thinks in terms of a key's "print"
   representation) (For purposes of discussion in this document, data
   values are normalized in terms of their "print" representation.  For a
   octet stream, the "first" octet would appear as the one on the "left",
   and the "last" octet would appear on the "right".) octet of the key
   (i.e., bits 1-8 per FIPS PUB 46-1), when considered as a data value,
   has numerical weight 2**56.  The last (or right-most displayed) octet
   (i.e., bits 57-64 per FIPS PUB 46-1) has numerical weight 2**0.

DESキーの八重奏の注文に関してどんな潜在的あいまいさも避けるために、別の暗号化へのデータ値が本当に(例えば、RSAEncryption)、以下の船倉を処理するとき、それは入力されます。 1(人が、キーのものに関して「印刷」が表現であると思うなら、最も左は表示した)番目(このドキュメントにおける議論の目的のために、データ値は彼らの「印刷」表現で正常にされます。 八重奏の流れに関しては、「1番目」の八重奏は「左」のものとして現れるでしょう、そして、「最後」の八重奏は「権利」に現れるでしょう。) キー(すなわち、FIPS PUB46-1あたりのビット1-8)の八重奏には、データ値であるとみなされると、数字の重さの2**56があります。 最後の、そして、(最も表示しています)の八重奏(すなわち、FIPS PUB46-1あたりのビット57-64)には、数字の重さの2**0があります。

2.  Message Integrity Check Algorithms

2. メッセージの保全チェックアルゴリズム

   This section identifies the alternative algorithms that shall be used
   to compute Message Integrity Check (MIC) values for PEM messages.
   Character string identifiers and ASN.1 object identifiers are
   assigned for incorporation in encapsulated "MIC-Info:" and "Key-
   Info:" header fields to indicate the choice of MIC algorithm
   employed.

このセクションはPEMメッセージのためにMessage Integrity Check(MIC)値を計算するのに使用されるものとする代替のアルゴリズムを特定します。 文字列識別子とASN.1物の識別子が要約にされるのでの編入のために割り当てられる、「MIC-インフォメーション:」 そして、「インフォメーションを合わせてください」 使われたMICアルゴリズムの選択を示すヘッダーフィールド。

   A compliant PEM implementation shall be able to process all of the
   alternative MIC algorithms defined here on incoming messages.  It is
   a sender option as to which alternative is employed on an outbound
   message.

対応するPEM実現はMICアルゴリズムがここ、入力メッセージで定義した代替手段のすべてを処理できるでしょう。 それはどの代替手段が外国行きのメッセージで採用しているかに関する送付者オプションです。

2.1  RSA-MD2 Message Digest Algorithm

2.1RSA-MD2メッセージダイジェストアルゴリズム

   The RSA-MD2 message digest is computed using the algorithm defined in
   RFC 1319 [9].  ( An error has been identified in RFC 1319.  The
   statement in the text of Section 3.2 which reads "Set C[j] to S[c xor
   L]" should read "Set C[j] to S[c xor L] xor C[j]".  Note that the C
   source code in the appendix of RFC 1319 is correct.)  The character
   string "RSA-MD2" within an encapsulated PEM header field indicates the
   use of this algorithm.  Also, as defined in RFC 1319, the ASN.1 object
   identifier

RSA-MD2メッセージダイジェストは、RFC1319[9]で定義されたアルゴリズムを使用することで計算されます。 誤りはRFC1319で特定されました。「S[c xor L]へのセットC[j]」を読むセクション3.2のテキストでの声明は「セットC[j]からS[c xor L]xor C[j]」を読むべきです。(RFC1319の付録のCソースコードが正しいことに注意してください。) 文字列、「要約のPEMヘッダーフィールドの中のRSA-MD2"はこのアルゴリズムの使用を示します」。 RFC1319で定義されるようなASN.1物の識別子も

     md2 OBJECT IDENTIFIER ::= {
         iso(1) member-body(2) US(840) rsadsi(113549)
         digestAlgorithm(2) 2
     }

md2 OBJECT IDENTIFIER:、:= iso(1)は(2) 米国(840)rsadsi(113549) digestAlgorithm(2)2をメンバーと同じくらい具体化させます。

   identifies this algorithm.  When this object identifier is used with
   the ASN.1 type AlgorithmIdentifier, the parameters component of that
   type is the ASN.1 type NULL.

このアルゴリズムを特定します。 この物の識別子がASN.1タイプAlgorithmIdentifierと共に使用されるとき、そのタイプのパラメタ成分はASN.1タイプNULLです。

Balenson                                                        [Page 4]

RFC 1423         PEM: Algorithms, Modes and Identifiers    February 1993

Balenson[4ページ]RFC1423PEM: アルゴリズム、モード、および識別子1993年2月

   The RSA-MD2 message digest algorithm accepts as input a message of
   any length and produces as output a 16-octet quantity.  When
   symmetric key management is employed, an RSA-MD2 MIC is encrypted by
   splitting the MIC into two 8-octet halves, independently encrypting
   each half, and concatenating the results.

RSA-MD2メッセージダイジェストアルゴリズムは、どんな長さに関するメッセージも入力するとき受け入れて、16八重奏の量を出力するとき、作成されます。 対称鍵管理が採用しているとき、RSA-MD2 MICはMICを2つの8八重奏の半分に分割することによって、コード化されます、独自に各半分をコード化して、結果を連結して。

   When symmetric key management is employed with this MIC algorithm,
   the symmetrically encrypted MD2 message digest is represented in a
   the fourth argument of a "Key-Info:" header field as a contiguous
   string of 32 ASCII hexadecimal digits (corresponding to a 128-bit MD2
   message digest).

いつ対称鍵管理がこのMICアルゴリズムで使われて、対称的にコード化されたMD2メッセージダイジェストが表されるか、4番目の議論、a、「主要なインフォメーション:」 32のASCII16進数字(128ビットのMD2メッセージダイジェストに対応する)の隣接のストリングとしてのヘッダーフィールド。

   To avoid any potential ambiguity regarding the ordering of the octets
   of an MD2 message digest that is input as a data value to another
   encryption process (e.g., RSAEncryption), the following holds true.
   The first (or left-most displayed, if one thinks in terms of a
   digest's "print" representation) octet of the digest (i.e., digest[0]
   as specified in RFC 1319), when considered as an RSA data value, has
   numerical weight 2**120.  The last (or right-most displayed) octet
   (i.e., digest[15] as specified in RFC 1319) has numerical weight
   2**0.

MD2メッセージダイジェストの八重奏の注文に関してどんな潜在的あいまいさも避けるために、別の暗号化へのデータ値が本当に(例えば、RSAEncryption)、以下の船倉を処理するとき、それは入力されます。 ダイジェスト(すなわち、RFC1319の指定されるとしてのダイジェスト[0])の最初(または、人が、ダイジェストのものに関して「印刷」が表現であると思うなら、表示していた状態で最も残される)の八重奏には、RSAデータ価値であるとみなされると、数字の重さの2**120があります。 最後の、そして、(最も表示しています)の八重奏(すなわち、RFC1319の指定されるとしてのダイジェスト[15])には、数字の重さの2**0があります。

2.2  RSA-MD5 Message Digest Algorithm

2.2RSA-MD5メッセージダイジェストアルゴリズム

   The RSA-MD5 message digest is computed using the algorithm defined in
   RFC 1321 [10].  The character string "RSA-MD5" within an encapsulated
   PEM header field indicates the use of this algorithm.  Also, as
   defined in RFC 1321, the object identifier

RSA-MD5メッセージダイジェストは、RFC1321[10]で定義されたアルゴリズムを使用することで計算されます。 文字列、「要約のPEMヘッダーフィールドの中のRSA-MD5"はこのアルゴリズムの使用を示します」。 RFC1321で定義されるような物の識別子も

     md5 OBJECT IDENTIFIER ::= {
         iso(1) member-body(2) US(840) rsadsi(113549)
         digestAlgorithm(2) 5
     }

md5 OBJECT IDENTIFIER:、:= iso(1)は(2) 米国(840)rsadsi(113549) digestAlgorithm(2)5をメンバーと同じくらい具体化させます。

   identifies this algorithm.  When this object identifier is used with
   the ASN.1 type AlgorithmIdentifier, the parameters component of that
   type is the ASN.1 type NULL.

このアルゴリズムを特定します。 この物の識別子がASN.1タイプAlgorithmIdentifierと共に使用されるとき、そのタイプのパラメタ成分はASN.1タイプNULLです。

   The RSA-MD5 message digest algorithm accepts as input a message of
   any length and produces as output a 16-octet quantity.  When
   symmetric key management is employed, an RSA-MD5 MIC is encrypted by
   splitting the MIC into two 8-octet halves, independently encrypting
   each half, and concatenating the results.

RSA-MD5メッセージダイジェストアルゴリズムは、どんな長さに関するメッセージも入力するとき受け入れて、16八重奏の量を出力するとき、作成されます。 対称鍵管理が採用しているとき、RSA-MD5 MICはMICを2つの8八重奏の半分に分割することによって、コード化されます、独自に各半分をコード化して、結果を連結して。

   When symmetric key management is employed with this MIC algorithm,
   the symmetrically encrypted MD5 message digest is represented in the
   fourth argument of a "Key-Info:" header field as a contiguous string
   of 32 ASCII hexadecimal digits (corresponding to a 128-bit MD5

対称鍵管理がこのMICアルゴリズムで使われるとき、対称的にコード化されたMD5メッセージダイジェストがaの4番目の議論で表される、「主要なインフォメーション:」 32のASCII16進数字の隣接のストリングとしてのヘッダーフィールド、(128ビットのMD5に対応すること。

Balenson                                                        [Page 5]

RFC 1423         PEM: Algorithms, Modes and Identifiers    February 1993

Balenson[5ページ]RFC1423PEM: アルゴリズム、モード、および識別子1993年2月

   message digest).

メッセージダイジェスト)

   To avoid any potential ambiguity regarding the ordering of the octets
   of a MD5 message digest that is input as an RSA data value to the RSA
   encryption process, the following holds true.  The first (or left-
   most displayed, if one thinks in terms of a digest's "print"
   representation) octet of the digest (i.e., the low-order octet of A
   as specified in RFC 1321), when considered as an RSA data value, has
   numerical weight 2**120.  The last (or right-most displayed) octet
   (i.e., the high-order octet of D as specified in RFC 1321) has
   numerical weight 2**0.

MD5メッセージダイジェストの八重奏の注文に関してどんな潜在的あいまいさも避けるために、それは本当にRSAデータ価値としてRSA暗号化の過程、以下の船倉に入力されます。 ダイジェスト(すなわち、RFC1321の指定されるとしてのAの下位の八重奏)の最初(人がダイジェストに関して考えるなら最も表示していた状態で残されているのは、「印刷」表現である)の八重奏には、RSAデータ価値であるとみなされると、数字の重さの2**120があります。 最後の、そして、(最も表示しています)の八重奏(すなわち、RFC1321の指定されるとしてのDの高位八重奏)には、数字の重さの2**0があります。

3.  Symmetric Key Management Algorithms

3. 対称鍵管理アルゴリズム

   This section identifies the alternative algorithms and modes that
   shall be used when symmetric key management is employed, to encrypt
   data encryption keys (DEKs) and message integrity check (MIC) values.
   Character string identifiers are assigned for incorporation in
   encapsulated "Key-Info:" header fields to indicate the choice of
   algorithm employed.

このセクションは対称鍵管理がデータ暗号化キー(DEKs)とメッセージの保全チェック(MIC)値をコード化するのに使われるとき使用されるものとする代替のアルゴリズムとモードを特定します。 文字列識別子が要約にされるのでの編入のために割り当てられる、「主要なインフォメーション:」 使われたアルゴリズムの選択を示すヘッダーフィールド。

   All alternatives presently defined in this category correspond to
   different usage modes of the DES algorithm, rather than to other
   algorithms.

現在このカテゴリで定義されているすべての選択肢が他のアルゴリズムにというよりむしろDESアルゴリズムの異なった用法モードに対応しています。

   When symmetric key management is employed, the symmetrically
   encrypted DEK and MIC, carried in the third and fourth arguments of a
   "Key-Info:" header field, respectively, are each represented as a
   string of contiguous ASCII hexadecimal digits.  The manner in which
   to use the following symmetric encryption algorithms and the length
   of the symmetrically encrypted DEK and MIC may vary depending on the
   length of the underlying DEK and MIC.  Section 1, Message Encryption
   Algorithms, and Section 2, Message Integrity Check Algorithms,
   provide information on the proper manner in which a DEK and MIC,
   respectively, are symmetrically encrypted when the size of the DEK or
   MIC is not equal to the symmetric encryption algorithm's input block
   size.  These sections also provide information on the proper format
   and length of the symmetrically encrypted DEK and MIC, respectively.

対称鍵管理がいつ採用しているか、そして、対称的にコード化されたDEKとMICがaの3番目と4番目の議論で運んだ、「主要なインフォメーション:」 ヘッダーフィールドは一連の隣接のASCII16進数字としてそれぞれそれぞれ表されます。 基本的なDEKとMICの長さによって、以下の左右対称の暗号化アルゴリズムを使用する方法と対称的にコード化されたDEKとMICの長さは異なるかもしれません。 セクション1(Message Encryption Algorithms、およびセクション2、Message Integrity Check Algorithms)は、DEKかMICのサイズが左右対称の暗号化アルゴリズムの入力ブロック・サイズと等しくないときにDEKとMICがそれぞれ対称的にコード化される適切な方法の情報を提供します。 また、これらのセクションはそれぞれ対称的にコード化されたDEKとMICの適切な形式と長さの情報を提供します。

3.1  DES in ECB Mode (DES-ECB)

3.1 ECBモードによるDES(デス-ECB)

   The DES algorithm in Electronic Codebook (ECB) mode [1][3] is used
   for DEK and MIC encryption when symmetric key management is employed.
   The character string "DES-ECB" within an encapsulated PEM header
   field indicates use of this algorithm/mode combination.

対称鍵管理が採用しているとき、Electronic Codebook(ECB)モード[1][3]のDESアルゴリズムはDEKとMIC暗号化に使用されます。 要約のPEMヘッダーフィールドの中の文字列「デス-ECB」はこのアルゴリズム/モード組み合わせの使用を示します。

   A compliant PEM implementation supporting symmetric key management
   shall support this algorithm/mode combination.

対称鍵管理を支持する対応するPEM実現はこのアルゴリズム/モード組み合わせをサポートするものとします。

Balenson                                                        [Page 6]

RFC 1423         PEM: Algorithms, Modes and Identifiers    February 1993

Balenson[6ページ]RFC1423PEM: アルゴリズム、モード、および識別子1993年2月

3.2  DES in EDE Mode (DES-EDE)

3.2 EDEモードによるDES(デス-エーデ)

   The DES algorithm in Encrypt-Decrypt-Encrypt (EDE) multiple
   encryption mode, as defined by ANSI X9.17 [6] for encryption and
   decryption with pairs of 64-bit keys, may be used for DEK and MIC
   encryption when symmetric key management is employed.  The character
   string "DES-EDE" within an encapsulated a PEM header field indicates
   use of this algorithm/mode combination.

中のDESアルゴリズム、Encryptが解読する、コード化、(EDE) 対称鍵管理が採用しているとき、暗号化と復号化のために組の64ビットのキーでANSI X9.17[6]によって定義される複数の暗号化モードがDEKとMIC暗号化に使用されるかもしれません。 文字列要約のa PEMヘッダーフィールドの中の「デス-エーデ」はこのアルゴリズム/モード組み合わせの使用を示します。

   A compliant PEM implementation supporting symmetric key management
   may optionally support this algorithm/mode combination.

対称鍵管理を支持する対応するPEM実現は任意にこのアルゴリズム/モード組み合わせをサポートするかもしれません。

4.  Asymmetric Key Management Algorithms

4. 非対称のKey Managementアルゴリズム

   This section identifies the alternative asymmetric keys and the
   alternative asymmetric key management algorithms with which those
   keys shall be used, namely the asymmetric encryption algorithms with
   which DEKs and MICs are encrypted, and the asymmetric signature
   algorithms with which certificates and certificate revocation lists
   (CRLs) are signed.

このセクションは代替の非対称のキー、それらのキーが使用されるものとする代替の非対称のかぎ管理アルゴリズム、すなわち、DEKsとMICsがコード化されている非対称の暗号化アルゴリズム、および証明書と証明書失効リスト(CRLs)がサインされる非対称の署名アルゴリズムを特定します。

4.1  Asymmetric Keys

4.1 非対称のキー

   This section describes the asymmetric keys that shall be used with
   the asymmetric encryption algorithms and the signature algorithms
   described later.  ASN.1 object identifiers are identified for
   incorporation in a public-key certificate to identify the
   algorithm(s) with which the accompanying public key is to be
   employed.

このセクションは後で説明される非対称の暗号化アルゴリズムと署名アルゴリズムで使用されるものとする非対称のキーについて説明します。 公開カギ証明書における編入が採用している付随の公開鍵がことであるアルゴリズムを特定するように、ASN.1物の識別子は特定されます。

4.1.1  RSA Keys

4.1.1 RSAキー

   An RSA asymmetric key pair is comprised of matching public and
   private keys.

RSA非対称の主要な組は合っている公衆と秘密鍵から成ります。

   An RSA public key consists of an encryption exponent e and an
   arithmetic modulus n, which are both public quantities typically
   carried in a public-key certificate.  For the value of e, Annex C to
   X.509 suggests the use of Fermat's Number F4 (65537 decimal, or
   1+2**16) as a value "common to the whole environment in order to
   reduce transmission capacity and complexity of transformation", i.e.,
   the value can be transmitted as 3 octets and at most seventeen (17)
   multiplications are required to effect exponentiation.  As an
   alternative, the number three (3) can be employed as the value for e,
   requiring even less octets for transmission and yielding even faster
   exponentiation.  For purposes of PEM, the value of e shall be either
   F4 or the number three (3).  The use of the number three (3) for the
   value of e is encouraged, to permit rapid certificate validation.

RSA公開鍵は暗号化解説者eと算数の係数nから成ります。(それは、公開カギ証明書で通常運ばれた両方の公共の量です)。 eの値のために、X.509へのAnnex Cが値としてフェルマーのNumber F4(65537 10進*、または1+2**16)の使用を勧める、「全体の環境に共通である、変化の送信能力と複雑さを減少させる、」、3つの八重奏と高々17(17)掛け算が羃法に作用するのに必要であるときに、すなわち、値を送ることができます。 代替手段として、eのための値としてNo.three(3)を使うことができます、トランスミッションのためのさらに少ない八重奏を必要として、さらに速い羃法をもたらして。 PEMの目的のために、eの値は、F4かNo.three(3)のどちらかになるでしょう。 使用、数では、eの値のための3(3)が急速な証明書合法化を可能にするよう奨励されます。

Balenson                                                        [Page 7]

RFC 1423         PEM: Algorithms, Modes and Identifiers    February 1993

Balenson[7ページ]RFC1423PEM: アルゴリズム、モード、および識別子1993年2月

   An RSA private key consists of a decryption exponent d, which should
   be kept secret, and the arithmetic modulus n.  Other values may be
   stored with a private key to facilitate efficient private key
   operations (see PKCS #1 [11]).

RSA秘密鍵は復号化解説者dと算数の係数nから成ります。(その解説者は、秘密にされるべきです)。 他の値は効率的な秘密鍵操作を容易にする秘密鍵で格納されるかもしれません。(PKCS#1[11])を見てください。

   For purposes of PEM, the modulus n may vary in size from 508 to 1024
   bits.

PEMの目的のために、係数nは508〜1024ビット大小の差があるかもしれません。

   Two ASN.1 object identifiers have been defined to identify RSA public
   keys.  In Annex H of X.509 [8], the object identifier

2ASN.1物の識別子は、RSA公開鍵を特定するために定義されました。 X.509[8]のAnnex H、物の識別子で

     rsa OBJECT IDENTIFIER ::= {
         joint-iso-ccitt(2) ds(5) algorithm(8)
         encryptionAlgorithm(1) 1
     }

rsa OBJECT IDENTIFIER:、:= 共同iso-ccitt(2) ds(5)アルゴリズム(8)encryptionAlgorithm(1)1

   is defined to identify an RSA public key.  A single parameter,
   KeySize, the length of the public key modulus in bits, is defined for
   use in conjunction with this object identifier.  When this object
   identifier is used with the ASN.1 type AlgorithmIdentifier, the
   parameters component of that type is the number of bits in the
   modulus, ASN.1 encoded as an INTEGER.

RSA公開鍵を特定するために、定義されます。 ただ一つのパラメタ、KeySize(ビットの公開鍵係数の長さ)は使用のためにこの物の識別子に関連して定義されます。 この物の識別子がASN.1タイプAlgorithmIdentifierと共に使用されるとき、そのタイプのパラメタ成分は係数(INTEGERとしてコード化されたASN.1)のビットの数です。

   Alternatively, in PKCS #1 [11], the ASN.1 object identifier

あるいはまた、PKCS#1[11]のASN.1物の識別子

     rsaEncryption OBJECT IDENTIFIER ::= {
         iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
         pkcs-1(1) 1
     }

rsaEncryption物の識別子:、:= iso(1)は(2) 米国(840)rsadsi(113549) pkcs(1) pkcs-1(1)1をメンバーと同じくらい具体化させます。

   is defined to identify both an RSA public key and the RSAEncryption
   process.  There are no parameters defined in conjunction with this
   object identifier, hence, when it is used with the ASN.1 type
   AlgorithmIdentifier, the parameters component of that type is the
   ASN.1 type NULL.

RSA公開鍵とRSAEncryptionの過程の両方を特定するために、定義されます。 この物の識別子に関連して定義されたパラメタが全くありません、それがASN.1タイプAlgorithmIdentifierと共に使用されるとき、したがって、そのタイプのパラメタ成分はASN.1タイプNULLです。

   A compliant PEM implementation may optionally generate an RSA
   public-key certificate that identifies the enclosed RSA public key
   (within the SubjectPublicKeyInformation component) with either the
   "rsa" or the "rsaEncryption" object identifier.  Use of the "rsa"
   object identifier is encouraged, since it is, in some sense, more
   generic in its identification of a key, without indicating how the
   key will be used.  However, to facilitate interoperability, a
   compliant PEM implementation shall accept RSA public-key certificates
   that identify the enclosed RSA public key with either the "rsa" or
   the "rsaEncryption" object identifier.  In all cases, an RSA public
   key identified in an RSA public-key certificate with either the "rsa"
   or "rsaEncryption" object identifier, shall be used according to the

対応するPEM実現は任意に"rsa"か"rsaEncryption"物の識別子のどちらかで同封のRSA公開鍵を特定する(SubjectPublicKeyInformationの部品の中で)RSA公開カギ証明書を作るかもしれません。 "rsa"物の識別子の使用は奨励されます、何らかの意味でそれがキーの識別で、より一般的であるので、キーがどう使用されるかを示さないで。 しかしながら、相互運用性を容易にするために、対応するPEM実現は"rsa"か"rsaEncryption"物の識別子のどちらかと同封のRSA公開鍵を同一視するRSA公開カギ証明書を受け入れるものとします。 すべてケース(RSA公開カギ証明書で"rsa"か"rsaEncryption"のどちらか物の識別子で特定されたRSA公開鍵)が使用されるものとする

Balenson                                                        [Page 8]

RFC 1423         PEM: Algorithms, Modes and Identifiers    February 1993

Balenson[8ページ]RFC1423PEM: アルゴリズム、モード、および識別子1993年2月

   procedures defined below for asymmetric encryption algorithms and
   asymmetric signature algorithms.

手順は非対称の暗号化のために以下でアルゴリズムと非対称の署名アルゴリズムを定義しました。

4.2  Asymmetric Encryption Algorithms

4.2 非対称の暗号化アルゴリズム

   This section identifies the alternative algorithms that shall be used
   when asymmetric key management is employed, to encrypt DEKs and MICs.
   Character string identifiers are assigned for incorporation in "MIC-
   Info:" and "Key-Info:" header fields to indicate the choice of
   algorithm employed.

このセクションは非対称のかぎ管理がDEKsとMICsをコード化するのに使われるとき使用されるものとする代替のアルゴリズムを特定します。 文字列識別子が編入のために中に割り当てられる、「MICインフォメーション:」 そして、「主要なインフォメーション:」 使われたアルゴリズムの選択を示すヘッダーフィールド。

   Only one alternative is presently defined in this category.

1つの選択肢だけが現在、このカテゴリで定義されます。

4.2.1  RSAEncryption

4.2.1 RSAEncryption

   The RSAEncryption public-key encryption algorithm, defined in PKCS #1
   [11], is used for DEK and MIC encryption when asymmetric key
   management is employed.  The character string "RSA" within a "MIC-
   Info:" or "Key-Info:" header field indicates the use of this
   algorithm.

非対称のかぎ管理が採用しているとき、PKCS#1[11]で定義されたRSAEncryption公開カギ暗号化アルゴリズムはDEKとMIC暗号化に使用されます。 aの中の文字列"RSA"、「ミックInfo:」 または、「主要なインフォメーション:」 ヘッダーフィールドはこのアルゴリズムの使用を示します。

   All PEM implementations supporting asymmetric key management shall
   support this algorithm.

非対称のかぎ管理を支持するすべてのPEM実現がこのアルゴリズムを支持するものとします。

   As described in PKCS #1, all quantities input as data values to the
   RSAEncryption process shall be properly justified and padded to the
   length of the modulus prior to the encryption process.  In general,
   an RSAEncryption input value is formed by concatenating a leading
   NULL octet, a block type BT, a padding string PS, a NULL octet, and
   the data quantity D, that is,

PKCS#1で説明されるように、RSAEncryptionへのデータ値が処理されるとき、すべての量の入力が、暗号化の過程の前に係数の長さに適切に正当化されて、水増しされるものとします。 一般に、RSAEncryption入力価値は主なNULL八重奏、ゴシック体BT、詰め物ストリングPS、NULL八重奏、およびデータ量Dを連結することによって、形成されて、それはそうです。

     RSA input value = 0x00 || BT || PS || 0x00 || D.

RSA入力値の=0x00|| BT|| PS|| 0×00|| D。

   To prepare a DEK for RSAEncryption, the PKCS #1 "block type 02"
   encryption-block formatting scheme is employed.  The block type BT is
   a single octet containing the value 0x02 and the padding string PS is
   one or more octets (enough octets to make the length of the complete
   RSA input value equal to the length of the modulus) each containing a
   pseudorandomly generated, non-zero value.  For multiple recipient
   messages, a different, pseudorandom padding string should be used for
   each recipient.  The data quantity D is the DEK itself, which is
   right-justified within the RSA input such that the last (or rightmost
   displayed, if one thinks in terms of the "print" representation)
   octet of the DEK is aligned with the right-most, or least-
   significant, octet of the RSA input.  Proceeding to the left, each of
   the remaining octets of the DEK, up through the first (or left-most
   displayed) octet, are each aligned in the next more significant octet
   of the RSA input.

RSAEncryption、PKCS#1のためにDEKを準備するために、「計画をフォーマットしている2インチ暗号化が妨げるゴシック体は採用しています」。 ゴシック体BTは値0x02を含むただ一つの八重奏です、そして、詰め物ストリングPSはそれぞれ発生する擬似ランダムを含む1つ以上の八重奏(完全なRSA入力価値の長さを係数の長さと等しくすることができるくらいの八重奏)です、非ゼロ値。 複数の受取人メッセージに関しては、異なった擬似ランダム詰め物ストリングは各受取人に使用されるべきです。 データ量DがDEK自身である、どれがRSAの中でまさしく正当であるかがそのようなものを入力した、それ、最終である、(一番右、表示しています、人が「印刷」表現) DEKの八重奏で考えるなら、RSA入力の最も右に並べられたか、最少重要な八重奏はそうです。 左に続いて、最初(最も左は表示した)の八重奏によるそれぞれのDEKの残っている八重奏はRSA入力の次の、より重要な八重奏でそれぞれ並べられます。

Balenson                                                        [Page 9]

RFC 1423         PEM: Algorithms, Modes and Identifiers    February 1993

Balenson[9ページ]RFC1423PEM: アルゴリズム、モード、および識別子1993年2月

   To prepare a MIC for RSAEncryption, the PKCS #1 "block type 01"
   encryption-block formatting scheme is employed.  The block type BT is
   a single octet containing the value 0x01 and the padding string PS is
   one or more octets (enough octets to make the length of the complete
   RSA input value equal to the length of the modulus) each containing
   the value 0xFF.  The data quantity D is comprised of the MIC and the
   MIC algorithm identifier which are ASN.1 encoded as the following
   sequence.

RSAEncryption、PKCS#1のためにMICを準備するために、「計画をフォーマットしている1インチ暗号化が妨げるゴシック体は採用しています」。 ゴシック体BTは値0x01を含むただ一つの八重奏です、そして、詰め物ストリングPSはそれぞれ値の0xFFを含む1つ以上の八重奏(完全なRSA入力価値の長さを係数の長さと等しくすることができるくらいの八重奏)です。 データ量Dは以下の系列としてコード化されたASN.1であるMICとMICアルゴリズム識別子から成ります。

     SEQUENCE {
         digestAlgorithm   AlgorithmIdentifier,
         digest            OCTET STRING
     }

系列digestAlgorithm AlgorithmIdentifier、ダイジェストOCTET STRING

   The ASN.1 type AlgorithmIdentifier is defined in X.509 as follows.

ASN.1タイプAlgorithmIdentifierは以下のX.509で定義されます。

     AlgorithmIdentifier ::= SEQUENCE {
         algorithm         OBJECT IDENTIFIER,
         parameters        ANY DEFINED BY algorithm OPTIONAL
     }

AlgorithmIdentifier:、:= 系列アルゴリズムOBJECT IDENTIFIER、パラメタANY DEFINED BYアルゴリズムOPTIONAL

   An RSA input block is encrypted using the RSA algorithm with the
   first (or left-most) octet taken as the most significant octet, and
   the last (or right-most) octet taken as the least significant octet.
   The resulting RSA output block is interpreted in a similar manner.

RSA入力ブロックは、最も重要な八重奏としてみなされる最初(または、最もいなくなる)の八重奏と最も重要でない八重奏としてみなされる最後の最も)八重奏と共にRSAアルゴリズムを使用することで暗号化されています。 結果として起こるRSA出力ブロックは同じように解釈されます。

   When RSAEncryption is used to encrypt a DEK, the second argument in a
   "MIC-Info:" header field, an asymmetrically encrypted DEK, is
   represented using the printable encoding technique defined in Section
   4.3.2.4 of RFC 1421 [12].

RSAEncryptionがaでDEK、2番目の議論を暗号化するのに使用される、「MIC-インフォメーション:」 ヘッダーフィールド(非対称的に暗号化されたDEK)は印刷可能なコード化を使用することで表されて、テクニックがセクション4.3.2で.4RFC1421[12]を定義したということです。

   When RSAEncryption is used to sign a MIC, the third argument in a
   "MIC-Info:" header field, an asymmetrically signed MIC, is
   represented using the printable encoding technique defined in Section
   4.3.2.4 of RFC 1421.

RSAEncryptionがaでMIC、3番目の議論に署名するのに使用される、「MIC-インフォメーション:」 ヘッダーフィールド(非対称的に署名しているMIC)は印刷可能なコード化を使用することで表されて、テクニックがセクション4.3.2で.4RFC1421を定義したということです。

4.3  Asymmetric Signature Algorithms

4.3 非対称の署名アルゴリズム

   This section identifies the alternative algorithms which shall be
   used to asymmetrically sign certificates and certificate revocation
   lists (CRLs) in accordance with the SIGNED macro defined in Annex G
   of X.509.  ASN.1 object identifiers are identified for incorporation
   in certificates and CRLs to indicate the choice of algorithm
   employed.

このセクションはX.509のAnnex Gで定義されたSIGNEDマクロに従って証明書と証明書失効リストが(CRLs)であると非対称的に署名するのに使用されるものとする代替のアルゴリズムを特定します。 証明書とCRLsでの編入が使われたアルゴリズムの選択を示すように、ASN.1オブジェクト識別子は特定されます。

   Only one alternative is presently defined in this category.

1つの選択肢だけが現在、このカテゴリで定義されます。

Balenson                                                       [Page 10]

RFC 1423         PEM: Algorithms, Modes and Identifiers    February 1993

Balenson[10ページ]RFC1423PEM: アルゴリズム、モード、および識別子1993年2月

4.3.1  md2WithRSAEncryption

4.3.1 md2WithRSAEncryption

   The md2WithRSAEncryption signature algorithm is used to sign
   certificates and CRLs.  The algorithm is defined in PKCS #1 [11].  It
   combines the RSA-MD2 message digest algorithm described here in
   Section 2.2 with the RSAEncryption asymmetric encryption algorithm
   described here in Section 4.2.1.  As defined in PKCS #1, the ASN.1
   object identifier

md2WithRSAEncryption署名アルゴリズムは、証明書とCRLsに署名するのに使用されます。 アルゴリズムはPKCS#1[11]で定義されます。 それはRSAEncryptionの非対称の暗号化アルゴリズムがここ、セクション4.2.1で説明されている状態でここ、セクション2.2で説明されたRSA-MD2メッセージダイジェストアルゴリズムを結合します。 定義されたコネPKCS#1、ASN.1オブジェクト識別子として

     md2WithRSAEncryption OBJECT IDENTIFIER ::= {
         iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
         pkcs-1(1) 2
     }

md2WithRSAEncryptionオブジェクト識別子:、:= iso(1)は(2) 米国(840)rsadsi(113549) pkcs(1) pkcs-1(1)2をメンバーと同じくらい具体化させます。

   identifies this algorithm.  When this object identifier is used with
   the ASN.1 type AlgorithmIdentifier, the parameters component of that
   type is the ASN.1 type NULL.

このアルゴリズムを特定します。 このオブジェクト識別子がASN.1タイプAlgorithmIdentifierと共に使用されるとき、そのタイプのパラメタ成分はASN.1タイプNULLです。

   There is some ambiguity in X.509 regarding the definition of the
   SIGNED macro and, in particular, the representation of a signature in
   a certificate or a CRL.  The interpretation selected for PEM requires
   that the data to be signed (in our case, an MD2 message digest) is
   first ASN.1 encoded as an OCTET STRING and the result is encrypted
   (in our case, using RSAEncryption) to form the signed quantity, which
   is then ASN.1 encoded as a BIT STRING.

SIGNEDマクロの定義と証明書かCRLの署名の特に表現に関して何らかのあいまいさがX.509にあります。 PEMのために選択された解釈は、署名されるデータ(私たちの場合におけるMD2メッセージダイジェスト)が最初に、OCTET STRINGと結果が次に、BIT STRINGとしてコード化されたASN.1である署名している量を形成するために暗号化されるので(私たちの場合ではRSAEncryptionを使用します)コード化されたASN.1であることを必要とします。

5.  Descriptive Grammar

5. 記述文法

   ; Addendum to PEM BNF representation, using RFC 822 notation
   ; Provides specification for official PEM cryptographic algorithms,
   ; modes, identifiers and formats.

; PEM BNF表現へのRFC822記法を使用することでの付加物 公式のPEM暗号アルゴリズムのための仕様を提供します。 モード、識別子、および形式。

   ; Imports <hexchar> and <encbin> from RFC [1421]

; RFCから<hexchar>と<encbinが>であるとインポートします。[1421]

       <dekalgid> ::= "DES-CBC"
       <ikalgid>  ::= "DES-EDE" / "DES-ECB" / "RSA"
       <sigalgid> ::= "RSA"
       <micalgid> ::= "RSA-MD2" / "RSA-MD5"

<dekalgid>:、:= "DES-CBC"<ikalgid>:、:= "DES-EDE"/「DES ECB」/"RSA"<sigalgid>:、:= "RSA"<micalgid>:、:= 「RSA-MD2"/"RSA-MD5""

       <dekparameters> ::= <DESCBCparameters>
       <DESCBCparameters> ::= <IV>
       <IV> ::= <hexchar16>

<dekparameters>:、:= <DESCBCparameters><DESCBCparameters>:、:= <IV><IV>:、:= <hexchar16>。

       <symencdek> ::= <DESECBencDESCBC> / <DESEDEencDESCBC>
       <DESECBencDESCBC> ::= <hexchar16>
       <DESEDEencDESCBC> ::= <hexchar16>

<symencdek>:、:= <DESECBencDESCBC>/<DESEDEencDESCBC><DESECBencDESCBC>:、:= <hexchar16><DESEDEencDESCBC>:、:= <hexchar16>。

       <symencmic> ::= <DESECBencRSAMD2> / <DESECBencRSAMD5>

<symencmic>:、:= <DESECBencRSAMD2>/<DESECBencRSAMD5>。

Balenson                                                       [Page 11]

RFC 1423         PEM: Algorithms, Modes and Identifiers    February 1993

Balenson[11ページ]RFC1423PEM: アルゴリズム、モード、および識別子1993年2月

       <DESECBencRSAMD2> ::= 2*2<hexchar16>
       <DESECBencRSAMD5> ::= 2*2<hexchar16>

<DESECBencRSAMD2>:、:= 2*2<hexchar16><DESECBencRSAMD5>:、:= 2*2<hexchar16>。

       <asymsignmic> ::= <RSAsignmic>
       <RSAsignmic> ::= <encbin>

<asymsignmic>:、:= <RSAsignmic><RSAsignmic>:、:= <encbin>。

       <asymencdek> ::= <RSAencdek>
       <RSAencdek> ::= <encbin>

<asymencdek>:、:= <RSAencdek><RSAencdek>:、:= <encbin>。

       <hexchar16> ::= 16*16<hexchar>

<hexchar16>:、:= 16*16<hexchar>。

References

参照

   [1] Federal Information Processing Standards Publication (FIPS PUB)
       46-1, Data Encryption Standard, Reaffirmed 1988 January 22
       (supersedes FIPS PUB 46, 1977 January 15).

[1] 連邦政府の情報処理規格公表(FIPSパブ)46-1(データ暗号化規格)は1月22日(1月15日にFIPSパブ46、1977に取って代わる)に1988を再び断言しました。

   [2] ANSI X3.92-1981, American National Standard Data Encryption
       Algorithm, American National Standards Institute, Approved 30
       December 1980.

[2]ANSI X3.92-1981、米国標準規格データ暗号化アルゴリズム、American National Standards Institut、承認された1980年12月30日。

   [3] Federal Information Processing Standards Publication (FIPS PUB)
       81, DES Modes of Operation, 1980 December 2.

[3] 1980年のDES運転モード、12月2連邦政府の情報処理規格公表(FIPSパブ)81、日。

   [4] ANSI X3.106-1983, American National Standard for Information
       Systems - Data Encryption Algorithm - Modes of Operation,
       American National Standards Institute, Approved 16 May 1983.

[4] ANSI X3.106-1983、情報システムのための米国標準規格--データ暗号化アルゴリズム--運転モード、American National Standards Institut(承認された1983年5月16日)。

   [5] ISO 8372, Information Processing Systems: Data Encipherment:
       Modes of Operation of a 64-bit Block Cipher.

[5] ISO8372、情報処理システム: データ暗号文: 64ビットのブロックの運転モードは解かれます。

   [6] ANSI X9.17-1985, American National Standard, Financial
       Institution Key Management (Wholesale), American Bankers
       Association, April 4, 1985, Section 7.2.

[6]ANSI X9.17-1985、米国標準規格、金融機関Key Management(大量の)、アメリカ銀行家協会、1985年4月4日、セクション7.2。

   [7] Voydock, V. L. and Kent, S. T., "Security Mechanisms in High-
       Level Network Protocols", ACM Computing Surveys, Vol. 15, No. 2,
       June 1983, pp. 135-171.

[7] Voydock、V.L.、およびケント、S.T.、「高いレベルのセキュリティー対策はプロトコルをネットワークでつなぎます」、ACM Computing Surveys、Vol.15、No.2、1983年6月、ページ 135-171.

   [8] CCITT Recommendation X.509, "The Directory - Authentication
       Framework", November 1988, (Developed in collaboration, and
       technically aligned, with ISO 9594-8).

[8] CCITT Recommendation X.509、「ディレクトリ--1988年11月の(共同で開発され、ISO9594-8に技術的に並べられます)の認証フレームワーク。

   [9] Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319, RSA
       Laboratories, April 1992.

[9]Kaliski、B.、「MD2メッセージダイジェストアルゴリズム」、RFC1319、RSA研究所、1992年4月。

  [10] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, MIT
       Laboratory for Computer Science and RSA Data Security, Inc.,

[10] 最もRivestなR.、「MD5メッセージダイジェストアルゴリズム」RFC1321、MITコンピュータサイエンス研究所、およびRSA Data Security Inc.

Balenson                                                       [Page 12]

RFC 1423         PEM: Algorithms, Modes and Identifiers    February 1993

Balenson[12ページ]RFC1423PEM: アルゴリズム、モード、および識別子1993年2月

       April 1992.

1992年4月。

  [11] PKCS #1: RSA Encryption Standard, Version 1.4, RSA Data Security,
       Inc., June 3, 1991.

[11]PKCS#1: RSA暗号化規格、バージョン1.4、RSA Data Security Inc.、1991年6月3日。

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

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

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

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

  [14] Kaliski, B., "Privacy Enhancement for Internet Electronic Mail:
       Part IV: Key Certification and Related Services", RFC 1424, RSA
       Laboratories, February 1993.

[14]Kaliski、B.、「インターネット電子メールのためのプライバシー増進:」 パートIV: 「主要な証明の、そして、関連のサービス」、RFC1424、RSA研究所、1993年2月。

Patent Statement

特許声明

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Balenson                                                       [Page 13]

RFC 1423         PEM: Algorithms, Modes and Identifiers    February 1993

Balenson[13ページ]RFC1423PEM: アルゴリズム、モード、および識別子1993年2月

   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

セキュリティ問題

   This entire document is about security.

この全体のドキュメントはセキュリティに関するものです。

Author's Address

作者のアドレス

   David Balenson
   Trusted Information Systems
   3060 Washington Road
   Glenwood, Maryland 21738

デヴィッドBalensonは情報システム3060ワシントン道路グレンウッド、メリーランド 21738を信じました。

   Phone: 301-854-6889
   EMail: balenson@tis.com

以下に電話をしてください。 301-854-6889 メールしてください: balenson@tis.com

Balenson                                                       [Page 14]

Balenson[14ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

CREATE VIEW ビューを作成する

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る