RFC4880 日本語訳
4880 OpenPGP Message Format. J. Callas, L. Donnerhacke, H. Finney, D.Shaw, R. Thayer. November 2007. (Format: TXT=203706 bytes) (Obsoletes RFC1991, RFC2440) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Callas
Request for Comments: 4880 PGP Corporation
Obsoletes: 1991, 2440 L. Donnerhacke
Category: Standards Track IKS GmbH
H. Finney
PGP Corporation
D. Shaw
R. Thayer
November 2007
カラがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 4880 PGP社は以下を時代遅れにします。 1991、2440L.Donnerhackeカテゴリ: 標準化過程IKS GmbH H.フィニーPGP社のD.ショーR.セイヤー2007年11月
OpenPGP Message Format
OpenPGPメッセージ・フォーマット
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws.
このドキュメントは、OpenPGP形式に基づく共同利用できるアプリケーションを開発するのに必要であるすべての必要事項を発表するために維持されます。 それは、アプリケーションを書くための段階的な料理の本ではありません。 それはどんなネットワークも越える従うパケットを読んで、チェックして、生成して、書くのに必要である形式とメソッドだけを説明します。 それはストレージと実装質問に対処しません。 しかしながら、それはセキュリティー・フローを避けるのに必要な導入問題について議論します。
OpenPGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication, and digital signatures. This document specifies the message formats used in OpenPGP.
OpenPGPソフトウェアは、電子通信とデータ保存のためのセキュリティー・サービスを提供するのに強い公開鍵と左右対称の暗号の組み合わせを使用します。 これらのサービスは秘密性、かぎ管理、認証、およびデジタル署名を含んでいます。 このドキュメントはOpenPGPで使用されるメッセージ・フォーマットを指定します。
Callas, et al Standards Track [Page 1] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[1ページ]RFC4880OpenPGP Message Format2007年11月
Table of Contents
目次
1. Introduction ....................................................5
1.1. Terms ......................................................5
2. General functions ...............................................6
2.1. Confidentiality via Encryption .............................6
2.2. Authentication via Digital Signature .......................7
2.3. Compression ................................................7
2.4. Conversion to Radix-64 .....................................8
2.5. Signature-Only Applications ................................8
3. Data Element Formats ............................................8
3.1. Scalar Numbers .............................................8
3.2. Multiprecision Integers ....................................9
3.3. Key IDs ....................................................9
3.4. Text .......................................................9
3.5. Time Fields ...............................................10
3.6. Keyrings ..................................................10
3.7. String-to-Key (S2K) Specifiers ............................10
3.7.1. String-to-Key (S2K) Specifier Types ................10
3.7.1.1. Simple S2K ................................10
3.7.1.2. Salted S2K ................................11
3.7.1.3. Iterated and Salted S2K ...................11
3.7.2. String-to-Key Usage ................................12
3.7.2.1. Secret-Key Encryption .....................12
3.7.2.2. Symmetric-Key Message Encryption ..........13
4. Packet Syntax ..................................................13
4.1. Overview ..................................................13
4.2. Packet Headers ............................................13
4.2.1. Old Format Packet Lengths ..........................14
4.2.2. New Format Packet Lengths ..........................15
4.2.2.1. One-Octet Lengths .........................15
4.2.2.2. Two-Octet Lengths .........................15
4.2.2.3. Five-Octet Lengths ........................15
4.2.2.4. Partial Body Lengths ......................16
4.2.3. Packet Length Examples .............................16
4.3. Packet Tags ...............................................17
5. Packet Types ...................................................17
5.1. Public-Key Encrypted Session Key Packets (Tag 1) ..........17
5.2. Signature Packet (Tag 2) ..................................19
5.2.1. Signature Types ....................................19
5.2.2. Version 3 Signature Packet Format ..................21
5.2.3. Version 4 Signature Packet Format ..................24
5.2.3.1. Signature Subpacket Specification .........25
5.2.3.2. Signature Subpacket Types .................27
5.2.3.3. Notes on Self-Signatures ..................27
5.2.3.4. Signature Creation Time ...................28
5.2.3.5. Issuer ....................................28
5.2.3.6. Key Expiration Time .......................28
1. 序論…5 1.1. 用語…5 2. 一般は機能します…6 2.1. Encryptionを通した秘密性…6 2.2. Digital Signatureを通した認証…7 2.3. 圧縮…7 2.4. 基数-64への変換…8 2.5. 署名だけアプリケーション…8 3. データ要素形式…8 3.1. スカラの数…8 3.2. 多倍精度整数…9 3.3. 主要なID…9 3.4. テキスト…9 3.5. 時間分野…10 3.6. Keyrings…10 3.7. ストリングからキー(S2K)への特許説明書の作成書…10 3.7.1. ストリングからキー(S2K)への特許説明書の作成書はタイプします…10 3.7.1.1. 簡単なS2K…10 3.7.1.2. S2Kに塩味を付けさせます…11 3.7.1.3. S2Kを繰り返して、塩味を付けさせます…11 3.7.2. ストリングからキーへの用法…12 3.7.2.1. 秘密鍵暗号化…12 3.7.2.2. 対称鍵メッセージ暗号化…13 4. パケット構文…13 4.1. 概要…13 4.2. パケットヘッダー…13 4.2.1. 古い方式パケット長…14 4.2.2. 新しい形式パケット長…15 4.2.2.1. 1八重奏の長さ…15 4.2.2.2. 2八重奏の長さ…15 4.2.2.3. 5八重奏の長さ…15 4.2.2.4. 部分的なボディーの長さ…16 4.2.3. パケット長の例…16 4.3. パケットタグ…17 5. パケットはタイプされます…17 5.1. 公開鍵はセッションの主要なパケット(タグ1)を暗号化しました…17 5.2. 署名パケット(タグ2)…19 5.2.1. 署名タイプ…19 5.2.2. バージョン3署名パケット・フォーマット…21 5.2.3. バージョン4署名パケット・フォーマット…24 5.2.3.1. 署名Subpacket仕様…25 5.2.3.2. 署名Subpacketはタイプします…27 5.2.3.3. 自己署名に関する注…27 5.2.3.4. 署名作成時間…28 5.2.3.5. 発行人…28 5.2.3.6. 主要な満了時間…28
Callas, et al Standards Track [Page 2] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[2ページ]RFC4880OpenPGP Message Format2007年11月
5.2.3.7. Preferred Symmetric Algorithms ............28
5.2.3.8. Preferred Hash Algorithms .................29
5.2.3.9. Preferred Compression Algorithms ..........29
5.2.3.10. Signature Expiration Time ................29
5.2.3.11. Exportable Certification .................29
5.2.3.12. Revocable ................................30
5.2.3.13. Trust Signature ..........................30
5.2.3.14. Regular Expression .......................31
5.2.3.15. Revocation Key ...........................31
5.2.3.16. Notation Data ............................31
5.2.3.17. Key Server Preferences ...................32
5.2.3.18. Preferred Key Server .....................33
5.2.3.19. Primary User ID ..........................33
5.2.3.20. Policy URI ...............................33
5.2.3.21. Key Flags ................................33
5.2.3.22. Signer's User ID .........................34
5.2.3.23. Reason for Revocation ....................35
5.2.3.24. Features .................................36
5.2.3.25. Signature Target .........................36
5.2.3.26. Embedded Signature .......................37
5.2.4. Computing Signatures ...............................37
5.2.4.1. Subpacket Hints ...........................38
5.3. Symmetric-Key Encrypted Session Key Packets (Tag 3) .......38
5.4. One-Pass Signature Packets (Tag 4) ........................39
5.5. Key Material Packet .......................................40
5.5.1. Key Packet Variants ................................40
5.5.1.1. Public-Key Packet (Tag 6) .................40
5.5.1.2. Public-Subkey Packet (Tag 14) .............40
5.5.1.3. Secret-Key Packet (Tag 5) .................41
5.5.1.4. Secret-Subkey Packet (Tag 7) ..............41
5.5.2. Public-Key Packet Formats ..........................41
5.5.3. Secret-Key Packet Formats ..........................43
5.6. Compressed Data Packet (Tag 8) ............................45
5.7. Symmetrically Encrypted Data Packet (Tag 9) ...............45
5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) ..........46
5.9. Literal Data Packet (Tag 11) ..............................46
5.10. Trust Packet (Tag 12) ....................................47
5.11. User ID Packet (Tag 13) ..................................48
5.12. User Attribute Packet (Tag 17) ...........................48
5.12.1. The Image Attribute Subpacket .....................48
5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18) ..49
5.14. Modification Detection Code Packet (Tag 19) ..............52
6. Radix-64 Conversions ...........................................53
6.1. An Implementation of the CRC-24 in "C" ....................54
6.2. Forming ASCII Armor .......................................54
6.3. Encoding Binary in Radix-64 ...............................57
6.4. Decoding Radix-64 .........................................58
6.5. Examples of Radix-64 ......................................59
5.2.3.7. 左右対称のアルゴリズムを好みます…28 5.2.3.8. ハッシュアルゴリズムを好みます…29 5.2.3.9. 圧縮アルゴリズムを好みます…29 5.2.3.10. 署名満了時間…29 5.2.3.11. 輸出向きの証明…29 5.2.3.12. 廃止可能…30 5.2.3.13. 署名を信じてください…30 5.2.3.14. 正規表現…31 5.2.3.15. 取消しキー…31 5.2.3.16. 記法データ…31 5.2.3.17. 主要なサーバ好み…32 5.2.3.18. 主要なサーバを好みます…33 5.2.3.19. 主たる利用者ID…33 5.2.3.20. 方針URI…33 5.2.3.21. キーは弛みます…33 5.2.3.22. 署名者のユーザID…34 5.2.3.23. 取消しには、推論してください…35 5.2.3.24. 特徴…36 5.2.3.25. 署名目標…36 5.2.3.26. 署名を埋め込みます…37 5.2.4. 署名を計算します…37 5.2.4.1. Subpacketは暗示します…38 5.3. 対称鍵はセッションの主要なパケット(タグ3)を暗号化しました…38 5.4. 署名パケット(タグ4)を1つ通過してください…39 5.5. キー材料パケット…40 5.5.1. 主要なパケット異形…40 5.5.1.1. 公開鍵パケット(タグ6)…40 5.5.1.2. 公共のサブキーパケット(タグ14)…40 5.5.1.3. 秘密鍵パケット(タグ5)…41 5.5.1.4. 秘密のサブキーパケット(タグ7)…41 5.5.2. 公開鍵パケット・フォーマット…41 5.5.3. 秘密鍵パケット・フォーマット…43 5.6. データ・パケット(タグ8)を圧縮します…45 5.7. 対称的に、データ・パケット(タグ9)を暗号化します…45 5.8. マーカーパケット(時代遅れの文字通りのパケット)(タグ10)…46 5.9. 文字通りのデータ・パケット(タグ11)…46 5.10. パケット(タグ12)を信じてください…47 5.11. ユーザIDパケット(タグ13)…48 5.12. ユーザ属性パケット(タグ17)…48 5.12.1. イメージ属性Subpacket…48 5.13. Sym。 暗号化された保全はデータ・パケット(タグ18)を保護しました。49 5.14. 変更検出コードパケット(タグ19)…52 6. 基数-64の変換…53 6.1. 「C」のCRC-24の実装…54 6.2. ASCIIよろいかぶとを形成します…54 6.3. 基数-64におけるバイナリーをコード化します…57 6.4. 基数-64を解読します…58 6.5. 基数-64に関する例…59
Callas, et al Standards Track [Page 3] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[3ページ]RFC4880OpenPGP Message Format2007年11月
6.6. Example of an ASCII Armored Message .......................59
7. Cleartext Signature Framework ..................................59
7.1. Dash-Escaped Text .........................................60
8. Regular Expressions ............................................61
9. Constants ......................................................61
9.1. Public-Key Algorithms .....................................62
9.2. Symmetric-Key Algorithms ..................................62
9.3. Compression Algorithms ....................................63
9.4. Hash Algorithms ...........................................63
10. IANA Considerations ...........................................63
10.1. New String-to-Key Specifier Types ........................64
10.2. New Packets ..............................................64
10.2.1. User Attribute Types ..............................64
10.2.1.1. Image Format Subpacket Types .............64
10.2.2. New Signature Subpackets ..........................64
10.2.2.1. Signature Notation Data Subpackets .......65
10.2.2.2. Key Server Preference Extensions .........65
10.2.2.3. Key Flags Extensions .....................65
10.2.2.4. Reason For Revocation Extensions .........65
10.2.2.5. Implementation Features ..................66
10.2.3. New Packet Versions ...............................66
10.3. New Algorithms ...........................................66
10.3.1. Public-Key Algorithms .............................66
10.3.2. Symmetric-Key Algorithms ..........................67
10.3.3. Hash Algorithms ...................................67
10.3.4. Compression Algorithms ............................67
11. Packet Composition ............................................67
11.1. Transferable Public Keys .................................67
11.2. Transferable Secret Keys .................................69
11.3. OpenPGP Messages .........................................69
11.4. Detached Signatures ......................................70
12. Enhanced Key Formats ..........................................70
12.1. Key Structures ...........................................70
12.2. Key IDs and Fingerprints .................................71
13. Notes on Algorithms ...........................................72
13.1. PKCS#1 Encoding in OpenPGP ...............................72
13.1.1. EME-PKCS1-v1_5-ENCODE .............................73
13.1.2. EME-PKCS1-v1_5-DECODE .............................73
13.1.3. EMSA-PKCS1-v1_5 ...................................74
13.2. Symmetric Algorithm Preferences ..........................75
13.3. Other Algorithm Preferences ..............................76
13.3.1. Compression Preferences ...........................76
13.3.2. Hash Algorithm Preferences ........................76
13.4. Plaintext ................................................77
13.5. RSA ......................................................77
13.6. DSA ......................................................77
13.7. Elgamal ..................................................78
13.8. Reserved Algorithm Numbers ...............................78
6.6. ASCIIの武具のメッセージに関する例…59 7. Cleartext署名フレームワーク…59 7.1. ダッシュで逃げられたテキスト…60 8. 正規表現…61 9. 定数…61 9.1. 公開鍵アルゴリズム…62 9.2. 対称鍵アルゴリズム…62 9.3. 圧縮アルゴリズム…63 9.4. アルゴリズムを論じ尽くしてください…63 10. IANA問題…63 10.1. ストリングからキーへの新しい特許説明書の作成書はタイプします…64 10.2. 新しいパケット…64 10.2.1. ユーザ属性タイプ…64 10.2.1.1. 画像形式Subpacketはタイプします…64 10.2.2. 新しい署名Subpackets…64 10.2.2.1. 署名記法データSubpackets…65 10.2.2.2. 主要なサーバ好みの拡大…65 10.2.2.3. キーは拡大に旗を揚げさせます…65 10.2.2.4. 取消し拡大には、推論してください…65 10.2.2.5. 実装機能…66 10.2.3. 新しいパケットバージョン…66 10.3. 新しいアルゴリズム…66 10.3.1. 公開鍵アルゴリズム…66 10.3.2. 対称鍵アルゴリズム…67 10.3.3. アルゴリズムを論じ尽くしてください…67 10.3.4. 圧縮アルゴリズム…67 11. パケット構成…67 11.1. 移転可能な公開鍵…67 11.2. 移転可能な秘密鍵…69 11.3. OpenPGPメッセージ…69 11.4. 署名を取り外します…70 12. 主要な形式を高めます…70 12.1. 主要な構造…70 12.2. 主要なIDと指紋…71 13. アルゴリズムに関する注…72 13.1. OpenPGPでのPKCS#1コード化…72 13.1.1. EME-PKCS1-v1_5エンコード…73 13.1.2. EME-PKCS1-v1_、5 -解読してください…73 13.1.3. EMSA-PKCS1-v1_5…74 13.2. 左右対称のアルゴリズム好み…75 13.3. 他のアルゴリズム好み…76 13.3.1. 圧縮好み…76 13.3.2. アルゴリズム好みを論じ尽くしてください…76 13.4. 平文…77 13.5. RSA…77 13.6. DSA…77 13.7. Elgamal…78 13.8. アルゴリズム番号を予約します…78
Callas, et al Standards Track [Page 4] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[4ページ]RFC4880OpenPGP Message Format2007年11月
13.9. OpenPGP CFB Mode .........................................78
13.10. Private or Experimental Parameters ......................79
13.11. Extension of the MDC System .............................80
13.12. Meta-Considerations for Expansion .......................80
14. Security Considerations .......................................81
15. Implementation Nits ...........................................84
16. References ....................................................86
16.1. Normative References .....................................86
16.2. Informative References ...................................88
13.9. OpenPGP CFBモード…78 13.10. 個人的であるか実験しているパラメタ…79 13.11. MDCシステムの拡大…80 13.12. 拡張のためのメタ問題…80 14. セキュリティ問題…81 15. 実装夜…84 16. 参照…86 16.1. 標準の参照…86 16.2. 有益な参照…88
1. Introduction
1. 序論
This document provides information on the message-exchange packet formats used by OpenPGP to provide encryption, decryption, signing, and key management functions. It is a revision of RFC 2440, "OpenPGP Message Format", which itself replaces RFC 1991, "PGP Message Exchange Formats" [RFC1991] [RFC2440].
このドキュメントは暗号化、復号化、署名、およびかぎ管理機能を提供するのにOpenPGPによって使用された交換処理パケット・フォーマットの情報を提供します。 それはRFC2440の改正、RFC1991、「PGP交換処理形式」[RFC1991][RFC2440]を取り替える「OpenPGPメッセージ・フォーマット」自体です。
1.1. Terms
1.1. 用語
* OpenPGP - This is a term for security software that uses PGP 5.x
as a basis, formalized in RFC 2440 and this document.
* OpenPGP--これはRFC2440とこのドキュメントで正式にされた基礎としてPGP 5.xを使用する機密保護ソフトウェアのための用語です。
* PGP - Pretty Good Privacy. PGP is a family of software systems
developed by Philip R. Zimmermann from which OpenPGP is based.
* PGP--プリティ・グッド・プライバシ。 PGPはOpenPGPが基づいているフィリップR.Zimmermannによって開発されたソフトウェア・システムのファミリーです。
* PGP 2.6.x - This version of PGP has many variants, hence the term
PGP 2.6.x. It used only RSA, MD5, and IDEA for its cryptographic
transforms. An informational RFC, RFC 1991, was written
describing this version of PGP.
* PGP 2.6.x--PGPのこのバージョンには、多くの異形、したがって、用語PGP 2.6.xがあります。 それは暗号の変換にRSA、MD5、およびIDEAだけを使用しました。情報のRFC(RFC1991)は、PGPのこのバージョンについて説明しながら、書かれました。
* PGP 5.x - This version of PGP is formerly known as "PGP 3" in the
community and also in the predecessor of this document, RFC 1991.
It has new formats and corrects a number of problems in the PGP
2.6.x design. It is referred to here as PGP 5.x because that
software was the first release of the "PGP 3" code base.
* PGP 5.x、--、以前PGPのこのバージョンとして知られている「PGP、共同体とこのドキュメント(RFC1991インチ)の前任者でも3インチ それは、PGP 2.6.xデザインで新しい形式を持って、多くの問題を修正します。 そのソフトウェアが「3インチのPGPコードベース」の最初のリリースであったので、それはPGP 5.xとしてここと呼ばれます。
* GnuPG - GNU Privacy Guard, also called GPG. GnuPG is an OpenPGP
implementation that avoids all encumbered algorithms.
Consequently, early versions of GnuPG did not include RSA public
keys. GnuPG may or may not have (depending on version) support
for IDEA or other encumbered algorithms.
* GnuPG--また、GPGと呼ばれるGNU Privacy Guard。 GnuPGはすべての妨げられたアルゴリズムを避けるOpenPGP実装です。その結果、GnuPGの早めのバージョンはRSA公開鍵を含んでいませんでした。 GnuPGには、IDEAのサポートか他の妨げられたアルゴリズムがあるかもしれません(バージョンによります)。
"PGP", "Pretty Good", and "Pretty Good Privacy" are trademarks of PGP Corporation and are used with permission. The term "OpenPGP" refers to the protocol described in this and related documents.
"PGP"、「きれいな利益」、および「プリティ・グッド・プライバシ」は、PGP社の商標であり、許可と共に使用されます。 "OpenPGP"という用語はこれと関連するドキュメントで説明されたプロトコルを示します。
Callas, et al Standards Track [Page 5] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[5ページ]RFC4880OpenPGP Message Format2007年11月
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
The key words "PRIVATE USE", "HIERARCHICAL ALLOCATION", "FIRST COME FIRST SERVED", "EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG APPROVAL", "IETF CONSENSUS", and "STANDARDS ACTION" that appear in this document when used to describe namespace allocation are to be interpreted as described in [RFC2434].
名前空間配分について説明するのに本書では使用されると現れる「私用」、「階層的な配分」、「先着順」、「専門のレビュー」、「仕様が必要である」、「IESG承認」、「IETFコンセンサス」、および「規格動作」というキーワードは[RFC2434]で説明されるように解釈されることです。
2. General functions
2. 一般機能
OpenPGP provides data integrity services for messages and data files by using these core technologies:
OpenPGPはこれらの核の技術を使用することによって、メッセージとデータファイルのためのデータ保全サービスを提供します:
- digital signatures
- デジタル署名
- encryption
- 暗号化
- compression
- 圧縮
- Radix-64 conversion
- 基数-64変換
In addition, OpenPGP provides key management and certificate services, but many of these are beyond the scope of this document.
さらに、OpenPGPはかぎ管理と証明書サービスを提供しますが、これらの多くがこのドキュメントの範囲を超えています。
2.1. Confidentiality via Encryption
2.1. Encryptionを通した秘密性
OpenPGP combines symmetric-key encryption and public-key encryption to provide confidentiality. When made confidential, first the object is encrypted using a symmetric encryption algorithm. Each symmetric key is used only once, for a single object. A new "session key" is generated as a random number for each object (sometimes referred to as a session). Since it is used only once, the session key is bound to the message and transmitted with it. To protect the key, it is encrypted with the receiver's public key. The sequence is as follows:
OpenPGPは、秘密性を提供するために共通鍵暗号と公開鍵暗号化を結合します。 秘密に作られると、最初に、オブジェクトは、左右対称の暗号化アルゴリズムを使用することで暗号化されています。 各対称鍵は単一のオブジェクトに一度だけ使用されます。 新しい「セッションキー」は各オブジェクト(時々セッションに言及される)のための乱数として生成されます。 それが一度だけ使用されるので、セッションキーは、メッセージに縛られて、それで送られます。 キーを保護するために、それは受信機の公開鍵で暗号化されます。 系列は以下の通りです:
1. The sender creates a message.
1. 送付者はメッセージを作成します。
2. The sending OpenPGP generates a random number to be used as a
session key for this message only.
2. 発信しているOpenPGPは、このメッセージだけに、主要なセッションとして使用されるために乱数を生成します。
3. The session key is encrypted using each recipient's public key.
These "encrypted session keys" start the message.
3. セッションキーは、各受取人の公開鍵を使用することで暗号化されています。 これらの「暗号化されたセッションキー」はメッセージを始めます。
Callas, et al Standards Track [Page 6] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[6ページ]RFC4880OpenPGP Message Format2007年11月
4. The sending OpenPGP encrypts the message using the session key,
which forms the remainder of the message. Note that the message
is also usually compressed.
4. 発信しているOpenPGPは、セッションキー(メッセージの残りを形成する)を使用することでメッセージを暗号化します。 また、通常、メッセージが圧縮されることに注意してください。
5. The receiving OpenPGP decrypts the session key using the
recipient's private key.
5. 受信OpenPGPは、受取人の秘密鍵を使用することでセッションキーを解読します。
6. The receiving OpenPGP decrypts the message using the session key.
If the message was compressed, it will be decompressed.
6. 受信OpenPGPは、セッションキーを使用することでメッセージを解読します。 メッセージが圧縮されたなら、それは減圧されるでしょう。
With symmetric-key encryption, an object may be encrypted with a symmetric key derived from a passphrase (or other shared secret), or a two-stage mechanism similar to the public-key method described above in which a session key is itself encrypted with a symmetric algorithm keyed from a shared secret.
暗号化、対称鍵によるオブジェクトは対称鍵で左右対称のアルゴリズムが共有秘密キーから合わせられている状態でセッションキーが暗号化される上で説明された公開鍵メソッドと同様のパスフレーズ(または、他の共有秘密キー)、または2ステージのメカニズムから派生していた状態で暗号化されるかもしれません。
Both digital signature and confidentiality services may be applied to the same message. First, a signature is generated for the message and attached to the message. Then the message plus signature is encrypted using a symmetric session key. Finally, the session key is encrypted using public-key encryption and prefixed to the encrypted block.
デジタル署名と秘密性サービスの両方が同じメッセージに適用されるかもしれません。 まず最初に、署名は、メッセージのために生成されて、メッセージに付けられます。 そして、メッセージプラス署名は、左右対称のセッションキーを使用することで暗号化されています。 最終的に、セッションキーは、公開鍵暗号化を使用することで暗号化されて、暗号化されたブロックへ前に置かれています。
2.2. Authentication via Digital Signature
2.2. Digital Signatureを通した認証
The digital signature uses a hash code or message digest algorithm, and a public-key signature algorithm. The sequence is as follows:
デジタル署名はハッシュコードかメッセージダイジェストアルゴリズムと、公開鍵署名アルゴリズムを使用します。 系列は以下の通りです:
1. The sender creates a message.
1. 送付者はメッセージを作成します。
2. The sending software generates a hash code of the message.
2. 送付ソフトウェアは、ハッシュがメッセージのコードであると生成します。
3. The sending software generates a signature from the hash code
using the sender's private key.
3. 送付ソフトウェアは、ハッシュコードから送付者の秘密鍵を使用することで署名を生成します。
4. The binary signature is attached to the message.
4. 2進の署名はメッセージに付けられています。
5. The receiving software keeps a copy of the message signature.
5. 受信ソフトウェアはメッセージ署名の写しを取っておきます。
6. The receiving software generates a new hash code for the received
message and verifies it using the message's signature. If the
verification is successful, the message is accepted as authentic.
6. 受信ソフトウェアは、受信されたメッセージのために新しいハッシュがコードであると生成して、メッセージの署名を使用することでそれについて確かめます。 検証がうまくいくなら、メッセージは正統であるとして認められます。
2.3. Compression
2.3. 圧縮
OpenPGP implementations SHOULD compress the message after applying the signature but before encryption.
OpenPGP実装SHOULDは署名を適用した後にもかかわらず、暗号化の前にメッセージを圧縮します。
Callas, et al Standards Track [Page 7] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[7ページ]RFC4880OpenPGP Message Format2007年11月
If an implementation does not implement compression, its authors should be aware that most OpenPGP messages in the world are compressed. Thus, it may even be wise for a space-constrained implementation to implement decompression, but not compression.
実装が圧縮を実装しないなら、作者は世界のほとんどのOpenPGPメッセージが圧縮されるのを意識しているべきです。 したがって、スペースで強制的な実装が圧縮ではなく、減圧を実装するのは、賢明でさえあるかもしれません。
Furthermore, compression has the added side effect that some types of attacks can be thwarted by the fact that slightly altered, compressed data rarely uncompresses without severe errors. This is hardly rigorous, but it is operationally useful. These attacks can be rigorously prevented by implementing and using Modification Detection Codes as described in sections following.
その上、何人かのタイプの攻撃は加えられた副作用であるかもしれませんが、わずかに変更されて、圧縮されたデータが厳しい誤りなしでめったに解凍しないという事実によって邪魔されて、圧縮は持っています。 これはほとんど厳しくはありませんが、それは操作上役に立ちます。 続いて、セクションで説明されるようにModification Detection Codesを実装して、使用することによって、これらの攻撃をきびしく防ぐことができます。
2.4. Conversion to Radix-64
2.4. 基数-64への変換
OpenPGP's underlying native representation for encrypted messages, signature certificates, and keys is a stream of arbitrary octets. Some systems only permit the use of blocks consisting of seven-bit, printable text. For transporting OpenPGP's native raw binary octets through channels that are not safe to raw binary data, a printable encoding of these binary octets is needed. OpenPGP provides the service of converting the raw 8-bit binary octet stream to a stream of printable ASCII characters, called Radix-64 encoding or ASCII Armor.
OpenPGPの暗号化メッセージ、署名証明書、およびキーの基本的な固有の表現は任意の八重奏のストリームです。 いくつかのシステムが7ビットの、そして、印刷可能なテキストから成るブロックの使用を可能にするだけです。 生のバイナリ・データに安全でないチャンネルによるOpenPGPのネイティブの生の2進の八重奏を輸送するのにおいて、これらの2進の八重奏の印刷可能なコード化が必要です。 Radix-64コード化かASCII Armorが、OpenPGPが生の8ビットの2進の八重奏ストリームを印刷可能なASCII文字の流れに変換するサービスを提供すると呼びました。
Implementations SHOULD provide Radix-64 conversions.
実装SHOULDは変換をRadix-64に供給します。
2.5. Signature-Only Applications
2.5. 署名だけアプリケーション
OpenPGP is designed for applications that use both encryption and signatures, but there are a number of problems that are solved by a signature-only implementation. Although this specification requires both encryption and signatures, it is reasonable for there to be subset implementations that are non-conformant only in that they omit encryption.
OpenPGPは暗号化と署名の両方を使用するアプリケーションのために設計されていますが、署名だけ実装によって解決されている多くの問題があります。 この仕様は暗号化と署名の両方を必要としますが、そこに、単に暗号化を省略するので非conformantである部分集合実装であることは妥当です。
3. Data Element Formats
3. データ要素形式
This section describes the data elements used by OpenPGP.
このセクションはOpenPGPによって使用されたデータ要素について説明します。
3.1. Scalar Numbers
3.1. スカラの数
Scalar numbers are unsigned and are always stored in big-endian format. Using n[k] to refer to the kth octet being interpreted, the value of a two-octet scalar is ((n[0] << 8) + n[1]). The value of a four-octet scalar is ((n[0] << 24) + (n[1] << 16) + (n[2] << 8) + n[3]).
スカラの数は、未署名であり、ビッグエンディアン形式でいつも保存されます。 解釈されるkth八重奏について言及するのにn[k]を使用して、2八重奏のスカラの値は(n[0]<<8)+n[1])です。 4八重奏のスカラの値は(n[0]<<24)です。+ + + (n[1]<<16)(n[2]<<8)n[3])。
Callas, et al Standards Track [Page 8] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[8ページ]RFC4880OpenPGP Message Format2007年11月
3.2. Multiprecision Integers
3.2. 多倍精度整数
Multiprecision integers (also called MPIs) are unsigned integers used to hold large integers such as the ones used in cryptographic calculations.
多倍精度整数(また、MPIsと呼ばれる)は暗号の計算に使用されるものなどの大きい整数を保持するのに使用される符号のない整数です。
An MPI consists of two pieces: a two-octet scalar that is the length of the MPI in bits followed by a string of octets that contain the actual integer.
MPIは2つの断片から成ります: 実際の整数を含む一連の八重奏でビットのMPIの長さである2八重奏のスカラは続きました。
These octets form a big-endian number; a big-endian number can be made into an MPI by prefixing it with the appropriate length.
これらの八重奏はビッグエンディアン番号を形成します。 適切な長さでそれを前に置くことによって、ビッグエンディアン番号をMPIにすることができます。
Examples:
例:
(all numbers are in hexadecimal)
(16進にはすべての数があります)
The string of octets [00 01 01] forms an MPI with the value 1. The string [00 09 01 FF] forms an MPI with the value of 511.
八重奏[00 01 01]のストリングは値1でMPIを形成します。 ストリング[00 09 01FF]は511の値でMPIを形成します。
Additional rules:
付則:
The size of an MPI is ((MPI.length + 7) / 8) + 2 octets.
MPIのサイズは((MPI.length+7)/8)+2つの八重奏です。
The length field of an MPI describes the length starting from its most significant non-zero bit. Thus, the MPI [00 02 01] is not formed correctly. It should be [00 01 01].
MPIの長さの分野は始まらせる中で非ゼロ・ビット最も重要である長さについて説明します。 したがって、MPI[00 02 01]は正しく形成されません。 それは[00 01 01]であるべきです。
Unused bits of an MPI MUST be zero.
未使用のビット、MPI MUSTでは、ゼロになってください。
Also note that when an MPI is encrypted, the length refers to the plaintext MPI. It may be ill-formed in its ciphertext.
また、MPIが暗号化されているとき、長さが平文MPIについて言及することに注意してください。 それは暗号文で不適格であるかもしれません。
3.3. Key IDs
3.3. 主要なID
A Key ID is an eight-octet scalar that identifies a key. Implementations SHOULD NOT assume that Key IDs are unique. The section "Enhanced Key Formats" below describes how Key IDs are formed.
Key IDはキーを特定する8八重奏のスカラです。 実装SHOULD NOTは、Key IDがユニークであると仮定します。 下の「主要な形式を高める」というセクションはKey IDがどう形成されるかを説明します。
3.4. Text
3.4. テキスト
Unless otherwise specified, the character set for text is the UTF-8 [RFC3629] encoding of Unicode [ISO10646].
別の方法で指定されない場合、テキストのための文字集合はユニコード[ISO10646]のUTF-8[RFC3629]コード化です。
Callas, et al Standards Track [Page 9] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[9ページ]RFC4880OpenPGP Message Format2007年11月
3.5. Time Fields
3.5. 時間分野
A time field is an unsigned four-octet number containing the number of seconds elapsed since midnight, 1 January 1970 UTC.
時間分野は真夜中、1970年1月1日UTC以来秒数を含む未署名の4八重奏の数が経過したということです。
3.6. Keyrings
3.6. Keyrings
A keyring is a collection of one or more keys in a file or database. Traditionally, a keyring is simply a sequential list of keys, but may be any suitable database. It is beyond the scope of this standard to discuss the details of keyrings or other databases.
keyringはファイルかデータベースで、1個以上のキーの収集です。 keyringは単に伝統的に、キーの連続したリストですが、どんな適当なデータベースもそのようなリストです。 それは、keyringsか他のデータベースの詳細について議論するためにこの規格の範囲を超えています。
3.7. String-to-Key (S2K) Specifiers
3.7. ストリングからキー(S2K)への特許説明書の作成書
String-to-key (S2K) specifiers are used to convert passphrase strings into symmetric-key encryption/decryption keys. They are used in two places, currently: to encrypt the secret part of private keys in the private keyring, and to convert passphrases to encryption keys for symmetrically encrypted messages.
ストリングからキー(S2K)への特許説明書の作成書は、共通鍵暗号/復号化キーにパスフレーズストリングを変換するのに使用されます。 それらは現在、2つの場所に使用されます: 個人的なkeyringにおける秘密鍵の秘密の部分を暗号化して、対称的に暗号化されたメッセージのために暗号化キーにパスフレーズを変換するために。
3.7.1. String-to-Key (S2K) Specifier Types
3.7.1. ストリングからキー(S2K)への特許説明書の作成書タイプ
There are three types of S2K specifiers currently supported, and some reserved values:
現在サポートされている3つのタイプのS2K特許説明書の作成書がありました、そして、或るものは値を予約しました:
ID S2K Type
-- --------
0 Simple S2K
1 Salted S2K
2 Reserved value
3 Iterated and Salted S2K
100 to 110 Private/Experimental S2K
ID S2Kはタイプします---------- 0 簡単なS2K1Salted S2K2Reserved価値3のIteratedとSalted S2K100〜110の兵士/実験的なS2K
These are described in Sections 3.7.1.1 - 3.7.1.3.
これらはセクション3.7.1で.1--3.7に説明されます。.1 .3。
3.7.1.1. Simple S2K
3.7.1.1. 簡単なS2K
This directly hashes the string to produce the key data. See below for how this hashing is done.
これは直接重要なデータを作り出すストリングを論じ尽くします。 この論じ尽くすことがどう完了しているように以下を見てくださいか。
Octet 0: 0x00
Octet 1: hash algorithm
八重奏0: 0×00 八重奏1: ハッシュアルゴリズム
Simple S2K hashes the passphrase to produce the session key. The manner in which this is done depends on the size of the session key (which will depend on the cipher used) and the size of the hash
簡単なS2Kはセッションキーを生産するパスフレーズを論じ尽くします。 これが行われる方法はセッションキー(暗号に使用されるよる)のサイズとハッシュのサイズに依存します。
Callas, et al Standards Track [Page 10] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[10ページ]RFC4880OpenPGP Message Format2007年11月
algorithm's output. If the hash size is greater than the session key size, the high-order (leftmost) octets of the hash are used as the key.
アルゴリズムは出力されました。 ハッシュサイズがセッションの主要なサイズより大きいなら、ハッシュの高位(一番左)八重奏はキーとして使用されます。
If the hash size is less than the key size, multiple instances of the hash context are created -- enough to produce the required key data. These instances are preloaded with 0, 1, 2, ... octets of zeros (that is to say, the first instance has no preloading, the second gets preloaded with 1 octet of zero, the third is preloaded with two octets of zeros, and so forth).
ハッシュサイズが主要なサイズより少ないなら、ハッシュ文脈の複数のインスタンスが作成されます--必要な重要なデータを作り出すためには十分。 これらのインスタンスは0、1、2でプレロードされます… ゼロ(最初のインスタンスには、すなわち、プレロードでないのがあって、2番目はゼロの1つの八重奏によってプレロードされて、3番目はゼロなどの2つの八重奏によってプレロードされる)の八重奏。
As the data is hashed, it is given independently to each hash context. Since the contexts have been initialized differently, they will each produce different hash output. Once the passphrase is hashed, the output data from the multiple hashes is concatenated, first hash leftmost, to produce the key data, with any excess octets on the right discarded.
データを論じ尽くすとき、独自にそれぞれのハッシュ文脈にそれを与えます。 文脈が異なって初期化されたので、それらはそれぞれ異なったハッシュ出力を起こすでしょう。 一度、パスフレーズは論じ尽くされて、複数のハッシュからの出力データは連結されます、最初のハッシュ。一番左では、どんな過剰八重奏も進行中で重要なデータを作り出すために、権利は捨てられました。
3.7.1.2. Salted S2K
3.7.1.2. 塩漬けにしたS2K
This includes a "salt" value in the S2K specifier -- some arbitrary data -- that gets hashed along with the passphrase string, to help prevent dictionary attacks.
これは辞書攻撃を防ぐのを助けるためにパスフレーズストリングと共に論じ尽くされるS2K特許説明書の作成書(いくつかの任意のデータ)に「塩」値を含んでいます。
Octet 0: 0x01
Octet 1: hash algorithm
Octets 2-9: 8-octet salt value
八重奏0: 0×01 八重奏1: アルゴリズムOctets2-9を論じ尽くしてください: 8八重奏の塩の値
Salted S2K is exactly like Simple S2K, except that the input to the hash function(s) consists of the 8 octets of salt from the S2K specifier, followed by the passphrase.
塩漬けにしたS2KはちょうどSimple S2Kに似ています、ハッシュ関数への入力がパスフレーズがあとに続いたS2K特許説明書の作成書からの塩の8つの八重奏から成るのを除いて。
3.7.1.3. Iterated and Salted S2K
3.7.1.3. 繰り返されて塩漬けにしたS2K
This includes both a salt and an octet count. The salt is combined with the passphrase and the resulting value is hashed repeatedly. This further increases the amount of work an attacker must do to try dictionary attacks.
これは塩と八重奏カウントの両方を含んでいます。 塩はパスフレーズに混ぜられます、そして、結果として起こる値は繰り返して論じ尽くされます。 これはさらに、攻撃者が辞書攻撃を試みるためにしなければならない仕事量を増強します。
Octet 0: 0x03
Octet 1: hash algorithm
Octets 2-9: 8-octet salt value
Octet 10: count, a one-octet, coded value
八重奏0: 0×03 八重奏1: アルゴリズムOctets2-9を論じ尽くしてください: 8八重奏の塩の値のOctet10: カウント(1八重奏)は値をコード化しました。
Callas, et al Standards Track [Page 11] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[11ページ]RFC4880OpenPGP Message Format2007年11月
The count is coded into a one-octet number using the following formula:
カウントは以下の公式を使用することで1八重奏の数にコード化されます:
#define EXPBIAS 6
count = ((Int32)16 + (c & 15)) << ((c >> 4) + EXPBIAS);
#EXPBIAS6カウント=((Int32)16+(cと15))<<(+ (c>>4)EXPBIAS)を定義してください。
The above formula is in C, where "Int32" is a type for a 32-bit integer, and the variable "c" is the coded count, Octet 10.
上の公式がCにあります。そこでの「Int32"は32ビットの整数のためのタイプです、そして、Octet10、変数「c」はコード化されたカウントです」。
Iterated-Salted S2K hashes the passphrase and salt data multiple times. The total number of octets to be hashed is specified in the encoded count in the S2K specifier. Note that the resulting count value is an octet count of how many octets will be hashed, not an iteration count.
繰り返されて塩漬けにしたS2Kは複数の回パスフレーズと塩のデータを論じ尽くします。 論じ尽くされるべき八重奏の総数はS2K特許説明書の作成書でコード化されたカウントで指定されます。 結果として起こるカウント値が繰り返しカウントではなく、いくつの八重奏が論じ尽くされるかに関する八重奏カウントであることに注意してください。
Initially, one or more hash contexts are set up as with the other S2K algorithms, depending on how many octets of key data are needed. Then the salt, followed by the passphrase data, is repeatedly hashed until the number of octets specified by the octet count has been hashed. The one exception is that if the octet count is less than the size of the salt plus passphrase, the full salt plus passphrase will be hashed even though that is greater than the octet count. After the hashing is done, the data is unloaded from the hash context(s) as with the other S2K algorithms.
初めは、1つ以上のハッシュ文脈が他のS2Kアルゴリズムで開業されます、重要なデータのいくつの八重奏が必要であるかよって。 次に、八重奏カウントで指定された八重奏の数が論じ尽くされるまで、塩は繰り返して論じ尽くされます、続いて、パスフレーズデータを論じ尽くします。 1つの例外はそれが八重奏カウントよりすばらしいのですが、完全な塩とパスフレーズが八重奏カウントが塩とパスフレーズのサイズ以下であるなら、論じ尽くされるということです。 論じ尽くすことが完了していた後に、データは他のS2Kアルゴリズムのようにハッシュ文脈から降ろされます。
3.7.2. String-to-Key Usage
3.7.2. ストリングからキーへの用法
Implementations SHOULD use salted or iterated-and-salted S2K specifiers, as simple S2K specifiers are more vulnerable to dictionary attacks.
純真なS2K特許説明書の作成書が辞書攻撃により被害を受け易いので、実装SHOULD使用は、S2K特許説明書の作成書を塩味を付けたか、繰り返して、または塩味を付けさせました。
3.7.2.1. Secret-Key Encryption
3.7.2.1. 秘密鍵暗号化
An S2K specifier can be stored in the secret keyring to specify how to convert the passphrase to a key that unlocks the secret data. Older versions of PGP just stored a cipher algorithm octet preceding the secret data or a zero to indicate that the secret data was unencrypted. The MD5 hash function was always used to convert the passphrase to a key for the specified cipher algorithm.
機密データをアンロックするキーにパスフレーズを変換する方法を指定するために秘密のkeyringでS2K特許説明書の作成書を保存できます。 PGPの旧式のバージョンはただ機密データが非暗号化されたのを示すために機密データかゼロに先行する暗号アルゴリズム八重奏を保存しました。 MD5ハッシュ関数は指定された暗号アルゴリズムのためにパスフレーズをキーに変換するのにおいていつも使用されていました。
For compatibility, when an S2K specifier is used, the special value 254 or 255 is stored in the position where the hash algorithm octet would have been in the old data structure. This is then followed immediately by a one-octet algorithm identifier, and then by the S2K specifier as encoded above.
S2K特許説明書の作成書が使用されているとき、互換性において、特別な値254か255は古いデータ構造にはハッシュアルゴリズム八重奏があった位置に保存されます。 そして、これはすぐ1八重奏のアルゴリズム識別子、およびそして、上でコード化されるS2K特許説明書の作成書によって続かれています。
Callas, et al Standards Track [Page 12] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[12ページ]RFC4880OpenPGP Message Format2007年11月
Therefore, preceding the secret data there will be one of these possibilities:
したがって、そこで機密データに先行するのはこれらの可能性の1つになるでしょう:
0: secret data is unencrypted (no passphrase)
255 or 254: followed by algorithm octet and S2K specifier
Cipher alg: use Simple S2K algorithm using MD5 hash
0: 機密データがそうである、255か254を非暗号化しました(パスフレーズがありません): アルゴリズム八重奏とS2K特許説明書の作成書Cipher algによって続かれています: MD5が論じ尽くすSimple S2Kアルゴリズム使用を使用してください。
This last possibility, the cipher algorithm number with an implicit use of MD5 and IDEA, is provided for backward compatibility; it MAY be understood, but SHOULD NOT be generated, and is deprecated.
この最後の可能性(MD5とIDEAの暗黙の使用がある暗号アルゴリズム番号)を後方の互換性に提供します。 それが理解されるかもしれませんが、SHOULD NOTは生成されて、推奨しないです。
These are followed by an Initial Vector of the same length as the block size of the cipher for the decryption of the secret values, if they are encrypted, and then the secret-key values themselves.
これらは秘密の値の復号化のための暗号のブロック・サイズと同じ長さのInitial Vectorによって続かれています、それらが暗号化されていて、次に、秘密鍵が自分たちを評価するなら。
3.7.2.2. Symmetric-Key Message Encryption
3.7.2.2. 対称鍵メッセージ暗号化
OpenPGP can create a Symmetric-key Encrypted Session Key (ESK) packet at the front of a message. This is used to allow S2K specifiers to be used for the passphrase conversion or to create messages with a mix of symmetric-key ESKs and public-key ESKs. This allows a message to be decrypted either with a passphrase or a public-key pair.
OpenPGPはメッセージの前部でSymmetric主要なEncrypted Session Key(ESK)パケットを作成できます。 これは、S2K特許説明書の作成書がパスフレーズ変換に使用されるか、または対称鍵のESKsと公開鍵ESKsのミックスでメッセージを作成するのを許容するのに使用されます。 これはパスフレーズか公開鍵組と共に解読されるべきメッセージを許容します。
PGP 2.X always used IDEA with Simple string-to-key conversion when encrypting a message with a symmetric algorithm. This is deprecated, but MAY be used for backward-compatibility.
左右対称のアルゴリズムでメッセージを暗号化するとき、PGP 2.XはいつもSimpleのストリングからキー変換があるIDEAを使用しました。 これは、推奨しないのですが、後方の互換性に使用されるかもしれません。
4. Packet Syntax
4. パケット構文
This section describes the packets used by OpenPGP.
このセクションはOpenPGPによって使用されたパケットについて説明します。
4.1. Overview
4.1. 概要
An OpenPGP message is constructed from a number of records that are traditionally called packets. A packet is a chunk of data that has a tag specifying its meaning. An OpenPGP message, keyring, certificate, and so forth consists of a number of packets. Some of those packets may contain other OpenPGP packets (for example, a compressed data packet, when uncompressed, contains OpenPGP packets).
OpenPGPメッセージは伝統的にパケットと呼ばれる多くの記録から構成されます。 パケットはタグが意味を指定するデータの塊です。 OpenPGPメッセージ、keyring、証明書などは多くのパケットから成ります。 それらのいくつかのパケットが他のOpenPGPパケットを含むかもしれません(例えば、解凍されると、圧縮されたデータ・パケットはOpenPGPパケットを含んでいます)。
Each packet consists of a packet header, followed by the packet body. The packet header is of variable length.
各パケットはパケットボディーがあとに続いたパケットのヘッダーから成ります。 パケットのヘッダーは可変長のものです。
4.2. Packet Headers
4.2. パケットのヘッダー
The first octet of the packet header is called the "Packet Tag". It determines the format of the header and denotes the packet contents. The remainder of the packet header is the length of the packet.
パケットのヘッダーの最初の八重奏は「パケットタグ」と呼ばれます。 それは、ヘッダーの形式を決定して、パケットコンテンツを指示します。 パケットのヘッダーの残りはパケットの長さです。
Callas, et al Standards Track [Page 13] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[13ページ]RFC4880OpenPGP Message Format2007年11月
Note that the most significant bit is the leftmost bit, called bit 7. A mask for this bit is 0x80 in hexadecimal.
最も重要なビットがビット7と呼ばれる一番左ビットであることに注意してください。 このビットマスクは16進の0×80です。
+---------------+
PTag |7 6 5 4 3 2 1 0|
+---------------+
Bit 7 -- Always one
Bit 6 -- New packet format if set
+---------------+ PTag|7 6 5 4 3 2 1 0| +---------------+ 設定されるなら新しいパケットがフォーマットするビット7(いつも1Bit6)
PGP 2.6.x only uses old format packets. Thus, software that interoperates with those versions of PGP must only use old format packets. If interoperability is not an issue, the new packet format is RECOMMENDED. Note that old format packets have four bits of packet tags, and new format packets have six; some features cannot be used and still be backward-compatible.
PGP 2.6.xは古い方式パケットを使用するだけです。 したがって、PGPのそれらのバージョンで共同利用するソフトウェアは古い方式パケットを使用するだけでよいです。 相互運用性が問題でないなら、新しいパケット・フォーマットはRECOMMENDEDです。 古い方式パケットにはパケットタグの4ビットがあることに注意してください。そうすれば、新しい形式パケットは6を持っています。 いくつかの特徴は、使用されて、まだ互換性があるはずがありません後方の。
Also note that packets with a tag greater than or equal to 16 MUST use new format packets. The old format packets can only express tags less than or equal to 15.
また、タグより多くの16があるパケットが新しい形式パケットを使用しなければならないことに注意してください。 パケットが言い表すことができるだけである古い方式は15以下にタグ付けをします。
Old format packets contain:
古い方式パケットは以下を含んでいます。
Bits 5-2 -- packet tag
Bits 1-0 -- length-type
ビット5-2--パケットタグBits1-0--長さタイプ
New format packets contain:
新しい形式パケットは以下を含んでいます。
Bits 5-0 -- packet tag
ビット5-0--パケットタグ
4.2.1. Old Format Packet Lengths
4.2.1. 古い方式パケット長
The meaning of the length-type in old format packets is:
古い方式パケットの長さタイプの意味は以下の通りです。
0 - The packet has a one-octet length. The header is 2 octets long.
0--パケットには、1八重奏の長さがあります。 長い間、ヘッダーは2つの八重奏です。
1 - The packet has a two-octet length. The header is 3 octets long.
1--パケットには、2八重奏の長さがあります。 長い間、ヘッダーは3つの八重奏です。
2 - The packet has a four-octet length. The header is 5 octets long.
2--パケットには、4八重奏の長さがあります。 長い間、ヘッダーは5つの八重奏です。
3 - The packet is of indeterminate length. The header is 1 octet
long, and the implementation must determine how long the packet
is. If the packet is in a file, this means that the packet
extends until the end of the file. In general, an implementation
SHOULD NOT use indeterminate-length packets except where the end
of the data will be clear from the context, and even then it is
better to use a definite length, or a new format header. The new
format headers described below have a mechanism for precisely
encoding data of indeterminate length.
3--パケットは不確定の長さのものです。 長い間、ヘッダーは1つの八重奏です、そして、実装はパケットがどれくらい長いかを決定しなければなりません。 パケットがファイルにあるなら、これは、パケットがファイルの端まで広がることを意味します。 一般に、SHOULD NOTがデータの終わりがあるところで不確定の長さのパケットを使用する実装は文脈からクリアされます、そして、その時でさえ、明確な長さ、または新しい形式ヘッダーを使用しているほうがよいです。 以下で説明された新しい形式ヘッダーは正確に不確定の長さに関するデータをコード化するためのメカニズムを持っています。
Callas, et al Standards Track [Page 14] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[14ページ]RFC4880OpenPGP Message Format2007年11月
4.2.2. New Format Packet Lengths
4.2.2. 新しい形式パケット長
New format packets have four possible ways of encoding length:
新しい形式パケットには、長さをコード化する4つの可能な方法があります:
1. A one-octet Body Length header encodes packet lengths of up to 191
octets.
1. 1八重奏のBody Lengthヘッダーは最大191の八重奏のパケット長をコード化します。
2. A two-octet Body Length header encodes packet lengths of 192 to
8383 octets.
2. 2八重奏のBody Lengthヘッダーは192〜8383の八重奏のパケット長をコード化します。
3. A five-octet Body Length header encodes packet lengths of up to
4,294,967,295 (0xFFFFFFFF) octets in length. (This actually
encodes a four-octet scalar number.)
3. 5八重奏のBody Lengthヘッダーは長さにおける、最大42億9496万7295(0xFFFFFFFF)の八重奏のパケット長をコード化します。 (これは実際に4八重奏のスカラの数をコード化します。)
4. When the length of the packet body is not known in advance by the
issuer, Partial Body Length headers encode a packet of
indeterminate length, effectively making it a stream.
4. パケットボディーの長さがあらかじめ発行人によって知られていないと、Partial Body Lengthヘッダーは不確定の長さのパケットをコード化します、事実上それをストリームにして。
4.2.2.1. One-Octet Lengths
4.2.2.1. 1八重奏の長さ
A one-octet Body Length header encodes a length of 0 to 191 octets. This type of length header is recognized because the one octet value is less than 192. The body length is equal to:
1八重奏のBody Lengthヘッダーは0〜191の八重奏の長さをコード化します。 1つの八重奏値が192未満であるので、このタイプの長さのヘッダーは見分けられます。 ボディーの長さは以下と等しいです。
bodyLen = 1st_octet;
bodyLenは最初の_八重奏と等しいです。
4.2.2.2. Two-Octet Lengths
4.2.2.2. 2八重奏の長さ
A two-octet Body Length header encodes a length of 192 to 8383 octets. It is recognized because its first octet is in the range 192 to 223. The body length is equal to:
2八重奏のBody Lengthヘッダーは192〜8383の八重奏の長さをコード化します。 最初の八重奏が範囲に192〜223にあるので、それは認識されます。 ボディーの長さは以下と等しいです。
bodyLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192
bodyLen=(最初の_八重奏--192)<<8) + (第2_八重奏)+192
4.2.2.3. Five-Octet Lengths
4.2.2.3. 5八重奏の長さ
A five-octet Body Length header consists of a single octet holding the value 255, followed by a four-octet scalar. The body length is equal to:
5八重奏のBody Lengthヘッダーは4八重奏のスカラがあとに続いていて、値255を保持するただ一つの八重奏から成ります。 ボディーの長さは以下と等しいです。
bodyLen = (2nd_octet << 24) | (3rd_octet << 16) |
(4th_octet << 8) | 5th_octet
bodyLenは(第2_八重奏<<24)と等しいです。| (第3_八重奏<<16) | (第4_八重奏<<8) | 5番目の_八重奏
This basic set of one, two, and five-octet lengths is also used internally to some packets.
また、1、2、およびこの基本的な5八重奏の長さは、内部的にいくつかのパケットに使用されます。
Callas, et al Standards Track [Page 15] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[15ページ]RFC4880OpenPGP Message Format2007年11月
4.2.2.4. Partial Body Lengths
4.2.2.4. 部分的なボディーの長さ
A Partial Body Length header is one octet long and encodes the length of only part of the data packet. This length is a power of 2, from 1 to 1,073,741,824 (2 to the 30th power). It is recognized by its one octet value that is greater than or equal to 224, and less than 255. The Partial Body Length is equal to:
Partial Body Lengthヘッダーは、長い間の1つの八重奏であり、データ・パケットの一部だけの長さをコード化します。 この長さは1〜10億7374万1824までの2(2の30乗)のパワーです。 それは224以上である1つの八重奏値、および255未満によって認識されます。 Partial Body Lengthは以下と等しいです。
partialBodyLen = 1 << (1st_octet & 0x1F);
partialBodyLenは1<<(最初の_八重奏と0x1F)と等しいです。
Each Partial Body Length header is followed by a portion of the packet body data. The Partial Body Length header specifies this portion's length. Another length header (one octet, two-octet, five-octet, or partial) follows that portion. The last length header in the packet MUST NOT be a Partial Body Length header. Partial Body Length headers may only be used for the non-final parts of the packet.
パケットボディーデータの部分はそれぞれのPartial Body Lengthヘッダーのあとに続いています。 Partial Body Lengthヘッダーはこの部分の長さを指定します。 別の長さのヘッダー(2八重奏的、または、5八重奏的、または、部分的な1つの八重奏)はその部分の後をつけます。 パケットにおける最後の長さのヘッダーはPartial Body Lengthヘッダーであるはずがありません。 部分的なBody Lengthヘッダーはパケットの非最終な部分に使用されるだけであるかもしれません。
Note also that the last Body Length header can be a zero-length header.
また、最後のBody Lengthヘッダーがゼロ・レングスヘッダーであるかもしれないことに注意してください。
An implementation MAY use Partial Body Lengths for data packets, be they literal, compressed, or encrypted. The first partial length MUST be at least 512 octets long. Partial Body Lengths MUST NOT be used for any other packet types.
それらが文字通り、圧縮された、または暗号化されていたなら、実装はデータ・パケットにPartial Body Lengthsを使用するかもしれません。 長い間、最初の部分的な長さは少なくとも512の八重奏であるに違いありません。 いかなる他のパケットタイプにも部分的なBody Lengthsを使用してはいけません。
4.2.3. Packet Length Examples
4.2.3. パケット長の例
These examples show ways that new format packets might encode the packet lengths.
これらの例は、新しい形式パケットがパケット長をコード化するかもしれないのを道に示します。
A packet with length 100 may have its length encoded in one octet: 0x64. This is followed by 100 octets of data.
長さ100があるパケットで、1つの八重奏で長さをコード化するかもしれません: 0×64。 データの100の八重奏がこれのあとに続いています。
A packet with length 1723 may have its length encoded in two octets: 0xC5, 0xFB. This header is followed by the 1723 octets of data.
長さ1723があるパケットで、2つの八重奏で長さをコード化するかもしれません: 0xC5、0xFB。 1723年のデータの八重奏はこのヘッダーのあとに続いています。
A packet with length 100000 may have its length encoded in five octets: 0xFF, 0x00, 0x01, 0x86, 0xA0.
長さ100000があるパケットで、5つの八重奏で長さをコード化するかもしれません: 0xFF、0×00、0×01、0×86、0xA0。
It might also be encoded in the following octet stream: 0xEF, first 32768 octets of data; 0xE1, next two octets of data; 0xE0, next one octet of data; 0xF0, next 65536 octets of data; 0xC5, 0xDD, last 1693 octets of data. This is just one possible encoding, and many variations are possible on the size of the Partial Body Length headers, as long as a regular Body Length header encodes the last portion of the data.
また、それは以下の八重奏ストリームでコード化されるかもしれません: 0xEF、最初に、データの32768の八重奏。 0xE1、データの次の2つの八重奏。 0xE0、データの次の1つの八重奏。 0xF0、データの次の65536の八重奏。 0xC5(0xDD)はデータの1693の八重奏が続きます。 レギュラーのBody Lengthヘッダーがデータの語尾をコード化するとき、これはただコード化して、多くの変化がPartial Body Lengthヘッダーのサイズで同じくらい可能であって、同じくらい長いのが可能な1つです。
Callas, et al Standards Track [Page 16] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[16ページ]RFC4880OpenPGP Message Format2007年11月
Please note that in all of these explanations, the total length of the packet is the length of the header(s) plus the length of the body.
これらの説明のすべてでは、パケットの全長は、ヘッダーの長さとボディーの長さです。
4.3. Packet Tags
4.3. パケットタグ
The packet tag denotes what type of packet the body holds. Note that old format headers can only have tags less than 16, whereas new format headers can have tags as great as 63. The defined tags (in decimal) are as follows:
パケットタグはボディーが保持するパケットのすべてのタイプを指示します。 ヘッダーが持つことができるだけである古い方式が16未満にタグ付けをしますが、新しい形式ヘッダーがタグを63と同じくらいすばらしくすることができることに注意してください。 定義されたタグ(小数における)は以下の通りです:
0 -- Reserved - a packet tag MUST NOT have this value
1 -- Public-Key Encrypted Session Key Packet
2 -- Signature Packet
3 -- Symmetric-Key Encrypted Session Key Packet
4 -- One-Pass Signature Packet
5 -- Secret-Key Packet
6 -- Public-Key Packet
7 -- Secret-Subkey Packet
8 -- Compressed Data Packet
9 -- Symmetrically Encrypted Data Packet
10 -- Marker Packet
11 -- Literal Data Packet
12 -- Trust Packet
13 -- User ID Packet
14 -- Public-Subkey Packet
17 -- User Attribute Packet
18 -- Sym. Encrypted and Integrity Protected Data Packet
19 -- Modification Detection Code Packet
60 to 63 -- Private or Experimental Values
0 -- Reserved - a packet tag MUST NOT have this value 1 -- Public-Key Encrypted Session Key Packet 2 -- Signature Packet 3 -- Symmetric-Key Encrypted Session Key Packet 4 -- One-Pass Signature Packet 5 -- Secret-Key Packet 6 -- Public-Key Packet 7 -- Secret-Subkey Packet 8 -- Compressed Data Packet 9 -- Symmetrically Encrypted Data Packet 10 -- Marker Packet 11 -- Literal Data Packet 12 -- Trust Packet 13 -- User ID Packet 14 -- Public-Subkey Packet 17 -- User Attribute Packet 18 -- Sym. 暗号化されるのと保全の保護されたデータ・パケット19--変更検出コードパケット60〜63--個人的であるか実験している値
5. Packet Types
5. パケットタイプ
5.1. Public-Key Encrypted Session Key Packets (Tag 1)
5.1. 公開鍵の暗号化されたセッション主要なパケット(タグ1)
A Public-Key Encrypted Session Key packet holds the session key used to encrypt a message. Zero or more Public-Key Encrypted Session Key packets and/or Symmetric-Key Encrypted Session Key packets may precede a Symmetrically Encrypted Data Packet, which holds an encrypted message. The message is encrypted with the session key, and the session key is itself encrypted and stored in the Encrypted Session Key packet(s). The Symmetrically Encrypted Data Packet is preceded by one Public-Key Encrypted Session Key packet for each OpenPGP key to which the message is encrypted. The recipient of the message finds a session key that is encrypted to their public key, decrypts the session key, and then uses the session key to decrypt the message.
Public主要なEncrypted Session Keyパケットは、セッションキーがメッセージを暗号化するのに使用されるままにします。 ゼロか、よりPublic主要なEncrypted Session Keyパケット、そして/または、Symmetric主要なEncrypted Session KeyパケットがSymmetrically Encrypted Data Packetに先行するかもしれません。(Symmetrically Encrypted Data Packetは暗号化メッセージを保持します)。 メッセージがセッションキーで暗号化されて、セッションキーは、Encrypted Session Keyパケットに暗号化されて、保存されます。 メッセージが暗号化されているそれぞれのOpenPGPキーあたり1つのPublic主要なEncrypted Session KeyパケットがSymmetrically Encrypted Data Packetに先行します。 メッセージの受取人は、それらの公開鍵に暗号化されて、セッションキーを解読して、次にセッションを使用するセッションキーがメッセージを解読するために主要であることがわかります。
Callas, et al Standards Track [Page 17] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[17ページ]RFC4880OpenPGP Message Format2007年11月
The body of this packet consists of:
このパケットのボディーは以下から成ります。
- A one-octet number giving the version number of the packet type.
The currently defined value for packet version is 3.
- パケットタイプのバージョン番号を与える1八重奏の数。 パケットバージョンのための現在定義された値は3です。
- An eight-octet number that gives the Key ID of the public key to
which the session key is encrypted. If the session key is
encrypted to a subkey, then the Key ID of this subkey is used
here instead of the Key ID of the primary key.
- セッションキーが暗号化されている公開鍵をKey IDに与える8八重奏の数。 セッションキーがサブキーに暗号化されるなら、このサブキーのKey IDは主キーのKey IDの代わりにここで使用されます。
- A one-octet number giving the public-key algorithm used.
- 公開鍵アルゴリズムを使用されているのに与える1八重奏の数。
- A string of octets that is the encrypted session key. This
string takes up the remainder of the packet, and its contents are
dependent on the public-key algorithm used.
- 暗号化されたセッションキーである一連の八重奏。 このストリングはパケットの残りを始めます、そして、内容は使用される公開鍵アルゴリズムに依存しています。
Algorithm Specific Fields for RSA encryption
RSA暗号化のためのアルゴリズムSpecificフィールズ
- multiprecision integer (MPI) of RSA encrypted value m**e mod n.
- RSAの多倍精度整数(MPI)は値m**eモッズnを暗号化しました。
Algorithm Specific Fields for Elgamal encryption:
Elgamal暗号化のためのアルゴリズムSpecificフィールズ:
- MPI of Elgamal (Diffie-Hellman) value g**k mod p.
- Elgamal(ディフィー-ヘルマン)値g**kモッズpのMPI。
- MPI of Elgamal (Diffie-Hellman) value m * y**k mod p.
- Elgamal(ディフィー-ヘルマン)値のm*y**kモッズpのMPI。
The value "m" in the above formulas is derived from the session key as follows. First, the session key is prefixed with a one-octet algorithm identifier that specifies the symmetric encryption algorithm used to encrypt the following Symmetrically Encrypted Data Packet. Then a two-octet checksum is appended, which is equal to the sum of the preceding session key octets, not including the algorithm identifier, modulo 65536. This value is then encoded as described in PKCS#1 block encoding EME-PKCS1-v1_5 in Section 7.2.1 of [RFC3447] to form the "m" value used in the formulas above. See Section 13.1 of this document for notes on OpenPGP's use of PKCS#1.
以下のセッションキーから上の定石による値の「m」を得ます。 まず最初に、セッションキーは以下のSymmetrically Encrypted Data Packetを暗号化するのに使用される左右対称の暗号化アルゴリズムを指定する1八重奏のアルゴリズム識別子で前に置かれています。 次に2八重奏のチェックサム(前のセッション主要な八重奏の合計と等しい)を追加します、アルゴリズム識別子(法65536)を含んでいなくて そして、上の定石で使用される「m」値を形成するために.1セクション7.2[RFC3447]でEME-PKCS1-v1_5をコード化しながらPKCS#で1ブロックについて説明するとき、この値はコード化されます。 PKCS#1のOpenPGPの使用に関する注のためのこのドキュメントのセクション13.1を見てください。
Note that when an implementation forms several PKESKs with one session key, forming a message that can be decrypted by several keys, the implementation MUST make a new PKCS#1 encoding for each key.
数個のキーで解読することができるメッセージを形成して、実装が1個のセッションキーで数個のPKESKsを形成するとき、実装が新しいPKCS#、を各キーのためにコード化される1にしなければならないことに注意してください。
An implementation MAY accept or use a Key ID of zero as a "wild card" or "speculative" Key ID. In this case, the receiving implementation would try all available private keys, checking for a valid decrypted session key. This format helps reduce traffic analysis of messages.
実装は、「ワイルドカード」か「投機的な」Key IDとしてゼロのKey IDを認めるか、または使用するかもしれません。 この場合、有効な解読されたセッションキーがないかどうかチェックして、受信実装はすべての利用可能な秘密鍵を試みるでしょう。 この形式は、メッセージのトラヒック分析を抑えるのを助けます。
Callas, et al Standards Track [Page 18] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[18ページ]RFC4880OpenPGP Message Format2007年11月
5.2. Signature Packet (Tag 2)
5.2. 署名パケット(タグ2)
A Signature packet describes a binding between some public key and some data. The most common signatures are a signature of a file or a block of text, and a signature that is a certification of a User ID.
Signatureパケットは何らかの公開鍵といくつかのデータの間の結合について説明します。 最も一般的な署名は、ファイルの署名か1ブロックのテキストと、User IDの証明である署名です。
Two versions of Signature packets are defined. Version 3 provides basic signature information, while version 4 provides an expandable format with subpackets that can specify more information about the signature. PGP 2.6.x only accepts version 3 signatures.
Signatureパケットの2つのバージョンが定義されます。 バージョン3は基本の署名情報を提供します、バージョン4は署名に関する詳しい情報を指定できる「副-パケット」を拡張可能な形式に提供しますが。 PGP 2.6.xはバージョン3署名を受け入れるだけです。
Implementations SHOULD accept V3 signatures. Implementations SHOULD generate V4 signatures.
実装SHOULDはV3署名を受け入れます。 実装SHOULDはV4に署名を生成します。
Note that if an implementation is creating an encrypted and signed message that is encrypted to a V3 key, it is reasonable to create a V3 signature.
実装がV3キーに暗号化される暗号化されて署名しているメッセージを作成しているなら、V3署名を作成するのが妥当であることに注意してください。
5.2.1. Signature Types
5.2.1. 署名タイプ
There are a number of possible meanings for a signature, which are indicated in a signature type octet in any given signature. Please note that the vagueness of these meanings is not a flaw, but a feature of the system. Because OpenPGP places final authority for validity upon the receiver of a signature, it may be that one signer's casual act might be more rigorous than some other authority's positive act. See Section 5.2.4, "Computing Signatures", for detailed information on how to compute and verify signatures of each type.
署名のための多くの可能な意味があります。(意味はどんな与えられた署名でも署名タイプ八重奏で示されます)。 これらの意味のあいまいさは欠点ではなく、システムの特徴です。 OpenPGPが正当性のために最終的な権威を署名の受信機に置くので、多分、1つの署名者のカジュアルな行為はある他の権威の積極的な行為より厳密であるかもしれません。 それぞれのタイプの署名を計算して、どう確かめるかの詳細な情報のために「署名を計算し」て、セクション5.2.4を見てください。
These meanings are as follows:
これらの意味は以下の通りです:
0x00: Signature of a binary document.
This means the signer owns it, created it, or certifies that it
has not been modified.
0×00: 2進のドキュメントの署名。 これは、署名者が、それを所有しているか、それを作成するか、またはそれが変更されていないのを公認することを意味します。
0x01: Signature of a canonical text document.
This means the signer owns it, created it, or certifies that it
has not been modified. The signature is calculated over the text
data with its line endings converted to <CR><LF>.
0×01: 正準なテキストドキュメントの署名。 これは、署名者が、それを所有しているか、それを作成するか、またはそれが変更されていないのを公認することを意味します。 署名は系列結末が<CR><LF>に変換されているテキストデータに関して計算されます。
0x02: Standalone signature.
This signature is a signature of only its own subpacket contents.
It is calculated identically to a signature over a zero-length
binary document. Note that it doesn't make sense to have a V3
standalone signature.
0×02: スタンドアロン署名。 この署名はそれ自身だけの「副-パケット」コンテンツの署名です。 それは同様にゼロ・レングスバイナリードキュメントの上の署名に計算されます。 V3スタンドアロン署名を持つ意味にならないことに注意してください。
Callas, et al Standards Track [Page 19] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[19ページ]RFC4880OpenPGP Message Format2007年11月
0x10: Generic certification of a User ID and Public-Key packet.
The issuer of this certification does not make any particular
assertion as to how well the certifier has checked that the owner
of the key is in fact the person described by the User ID.
0×10: User IDとPublic主要なパケットのジェネリック証明。 この証明の発行人は証明することが、事実上、キーの所有者がUser IDによって説明された人であることをどれくらいよくチェックしたかに関して少しの特定の主張もしません。
0x11: Persona certification of a User ID and Public-Key packet.
The issuer of this certification has not done any verification of
the claim that the owner of this key is the User ID specified.
0×11: User IDとPublic主要なパケットの人格証明。 この証明の発行人はこのキーの所有者がIDが指定したUserであるというクレームの少しの検証もしていません。
0x12: Casual certification of a User ID and Public-Key packet.
The issuer of this certification has done some casual
verification of the claim of identity.
0×12: User IDとPublic主要なパケットのカジュアルな証明。 この証明の発行人はアイデンティティのクレームの何らかのカジュアルな検証をしました。
0x13: Positive certification of a User ID and Public-Key packet.
The issuer of this certification has done substantial
verification of the claim of identity.
0×13: User IDとPublic主要なパケットの積極的な証明。 この証明の発行人はアイデンティティのクレームのかなりの検証をしました。
Most OpenPGP implementations make their "key signatures" as 0x10
certifications. Some implementations can issue 0x11-0x13
certifications, but few differentiate between the types.
ほとんどのOpenPGP実装が0×10の証明としてそれらの「調号」を作ります。 いくつかの実装が0×11-0×13の証明を発行できますが、わずかしかタイプを区別しません。
0x18: Subkey Binding Signature
This signature is a statement by the top-level signing key that
indicates that it owns the subkey. This signature is calculated
directly on the primary key and subkey, and not on any User ID or
other packets. A signature that binds a signing subkey MUST have
an Embedded Signature subpacket in this binding signature that
contains a 0x19 signature made by the signing subkey on the
primary key and subkey.
0×18: サブキーBinding Signature This署名はサブキーを所有しているのを示すトップレベル署名キーによる声明です。 この署名はどんなUser IDや他のパケットの上でも計算されるのではなく、主キーとサブキーの直接上に計算されます。 署名サブキーを縛る署名は主キーとサブキーの上の署名サブキーによってされた0×19署名を含むこの拘束力がある署名でEmbedded Signature subpacketを持たなければなりません。
0x19: Primary Key Binding Signature
This signature is a statement by a signing subkey, indicating
that it is owned by the primary key and subkey. This signature
is calculated the same way as a 0x18 signature: directly on the
primary key and subkey, and not on any User ID or other packets.
0×19: プライマリKey Binding Signature This署名は署名サブキーによる声明です、それが主キーとサブキーによって所有されているのを示して。 この署名は0×18署名として同じように計算されます: どんなUser IDや他のパケットではなく、直接主キーとサブキーに関しても。
0x1F: Signature directly on a key
This signature is calculated directly on a key. It binds the
information in the Signature subpackets to the key, and is
appropriate to be used for subpackets that provide information
about the key, such as the Revocation Key subpacket. It is also
appropriate for statements that non-self certifiers want to make
about the key itself, rather than the binding between a key and a
name.
0x1F: 直接主要なThis署名の署名はキーの直接上に計算されます。 キーの情報を提供する「副-パケット」に使用されるのは、Signature subpacketsの情報をキーに縛って、適切です、Revocation Key subpacketなどのように。 また、それはキーと名前の間の結合よりむしろ非自己証明することがキー自体の周りで作りたがっている適切な繰り返し文です。
Callas, et al Standards Track [Page 20] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[20ページ]RFC4880OpenPGP Message Format2007年11月
0x20: Key revocation signature
The signature is calculated directly on the key being revoked. A
revoked key is not to be used. Only revocation signatures by the
key being revoked, or by an authorized revocation key, should be
considered valid revocation signatures.
0×20: 取消し署名を合わせてください。署名は、キーの直接上に取り消されながら、計算されます。 取り消されたキーは使用されていることになっていません。 取り消されるキー、または認可された取消しキーによる取消し署名だけが有効な取消し署名であると考えられるべきです。
0x28: Subkey revocation signature
The signature is calculated directly on the subkey being revoked.
A revoked subkey is not to be used. Only revocation signatures
by the top-level signature key that is bound to this subkey, or
by an authorized revocation key, should be considered valid
revocation signatures.
0×28: サブキー取消し署名、署名は取り消されるサブキーの直接上に計算されます。 取り消されたサブキーは使用されていることになっていません。 このサブキーに縛られるトップレベル署名キー、または認可された取消しキーによる取消し署名だけが有効な取消し署名であると考えられるべきです。
0x30: Certification revocation signature
This signature revokes an earlier User ID certification signature
(signature class 0x10 through 0x13) or direct-key signature
(0x1F). It should be issued by the same key that issued the
revoked signature or an authorized revocation key. The signature
is computed over the same data as the certificate that it
revokes, and should have a later creation date than that
certificate.
0×30: 証明取消し署名This署名は以前のUser ID証明署名(署名クラス0×10から0x13)かダイレクト調号(0x1F)を取り消します。 それは取り消された署名を発行した同じキーか認可された取消しキーによって発行されるべきです。 署名は、それが取り消す証明書と同じデータに関して計算されて、その証明書より遅い作成日付を持つべきです。
0x40: Timestamp signature.
This signature is only meaningful for the timestamp contained in
it.
0×40: タイムスタンプ署名。 それに含まれたタイムスタンプだけに、この署名は重要です。
0x50: Third-Party Confirmation signature.
This signature is a signature over some other OpenPGP Signature
packet(s). It is analogous to a notary seal on the signed data.
A third-party signature SHOULD include Signature Target
subpacket(s) to give easy identification. Note that we really do
mean SHOULD. There are plausible uses for this (such as a blind
party that only sees the signature, not the key or source
document) that cannot include a target subpacket.
0×50: 第3パーティConfirmation署名。 この署名はある他のOpenPGP Signatureパケットの上の署名です。 それは署名しているデータで公証人シールに類似しています。 SHOULDが簡単な識別を与えるためにSignature Target subpacket(s)を含む第三者署名。 私たちが本当にSHOULDを言っていることに注意してください。 目標「副-パケット」を含むことができないこれ(キーかソースドキュメントではなく、署名を見るだけである盲目のパーティーなどの)へのもっともらしい用途があります。
5.2.2. Version 3 Signature Packet Format
5.2.2. バージョン3署名パケット・フォーマット
The body of a version 3 Signature Packet contains:
バージョン3Signature Packetのボディーは以下を含みます。
- One-octet version number (3).
- 1八重奏のバージョン番号(3)。
- One-octet length of following hashed material. MUST be 5.
- 1八重奏の長さについて論じ尽くされた材料に続くこと。 5はそうであるに違いありませんか?
- One-octet signature type.
- 1八重奏の署名タイプ。
- Four-octet creation time.
- 4八重奏の作成時間。
- Eight-octet Key ID of signer.
- 署名者の8八重奏のKey ID。
Callas, et al Standards Track [Page 21] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[21ページ]RFC4880OpenPGP Message Format2007年11月
- One-octet public-key algorithm.
- 1八重奏の公開鍵アルゴリズム。
- One-octet hash algorithm.
- 1八重奏のハッシュアルゴリズム。
- Two-octet field holding left 16 bits of signed hash value.
- 2八重奏の分野把持は署名しているハッシュ値の16ビットを残しました。
- One or more multiprecision integers comprising the signature.
This portion is algorithm specific, as described below.
- 署名を包括する1つ以上の多倍精度整数。 この部分は以下で説明されるとして特定のアルゴリズムです。
The concatenation of the data to be signed, the signature type, and creation time from the Signature packet (5 additional octets) is hashed. The resulting hash value is used in the signature algorithm. The high 16 bits (first two octets) of the hash are included in the Signature packet to provide a quick test to reject some invalid signatures.
Signatureパケット(5つの追加八重奏)からの署名されるデータの連結、署名タイプ、および作成時間は論じ尽くされます。 結果として起こるハッシュ値は署名アルゴリズムで使用されます。 ハッシュの高い16ビット(最初の2つの八重奏)は、いくつかの無効の署名を拒絶するために迅速なテストを提供するためにSignatureパケットに含まれています。
Algorithm-Specific Fields for RSA signatures:
RSA署名のためのアルゴリズム特有のフィールズ:
- multiprecision integer (MPI) of RSA signature value m**d mod n.
- RSA署名値m**dモッズnの多倍精度整数(MPI)。
Algorithm-Specific Fields for DSA signatures:
DSA署名のためのアルゴリズム特有のフィールズ:
- MPI of DSA value r.
- DSA価値rのMPI。
- MPI of DSA value s.
- DSA価値sのMPI。
The signature calculation is based on a hash of the signed data, as described above. The details of the calculation are different for DSA signatures than for RSA signatures.
署名計算は上で説明されるように署名しているデータのハッシュに基づいています。 DSA署名において、計算の詳細はRSA署名より異なっています。
With RSA signatures, the hash value is encoded using PKCS#1 encoding type EMSA-PKCS1-v1_5 as described in Section 9.2 of RFC 3447. This requires inserting the hash value as an octet string into an ASN.1 structure. The object identifier for the type of hash being used is included in the structure. The hexadecimal representations for the currently defined hash algorithms are as follows:
RSA署名で、ハッシュ値は、RFC3447のセクション9.2で説明されるようにタイプEMSA-PKCS1-v1_5をコード化するPKCS#1を使用することでコード化されます。 これは、八重奏ストリングとしてASN.1構造にハッシュ値を挿入するのを必要とします。 使用されるハッシュのタイプへのオブジェクト識別子は構造に含まれています。 現在定義されたハッシュアルゴリズムの16進表現は以下の通りです:
- MD5: 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05
- MD5: 0x2A、0×86 0×48 0×86 0xF7、0x0D、0×02、0×05
- RIPEMD-160: 0x2B, 0x24, 0x03, 0x02, 0x01
- RIPEMD-160: 0x2B、0×24、0×03、0×02、0×01
- SHA-1: 0x2B, 0x0E, 0x03, 0x02, 0x1A
- SHA-1: 0x2B、0x0E、0×03、0×02、0x1A
- SHA224: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x04
- SHA224: 0×60、0×86、0×48、0×01、0×65、0×03、0×04、0×02、0×04
- SHA256: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01
- SHA256: 0×60、0×86、0×48、0×01、0×65、0×03、0×04、0×02、0×01
- SHA384: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02
- SHA384: 0×60、0×86、0×48、0×01、0×65、0×03、0×04、0×02、0×02
Callas, et al Standards Track [Page 22] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[22ページ]RFC4880OpenPGP Message Format2007年11月
- SHA512: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03
- SHA512: 0×60、0×86、0×48、0×01、0×65、0×03、0×04、0×02、0×03
The ASN.1 Object Identifiers (OIDs) are as follows:
ASN.1Object Identifiers(OIDs)は以下の通りです:
- MD5: 1.2.840.113549.2.5
- MD5: 1.2.840.113549.2.5
- RIPEMD-160: 1.3.36.3.2.1
- RIPEMD-160: 1.3.36.3.2.1
- SHA-1: 1.3.14.3.2.26
- SHA-1: 1.3.14.3.2.26
- SHA224: 2.16.840.1.101.3.4.2.4
- SHA224: 2.16.840.1.101.3.4.2.4
- SHA256: 2.16.840.1.101.3.4.2.1
- SHA256: 2.16.840.1.101.3.4.2.1
- SHA384: 2.16.840.1.101.3.4.2.2
- SHA384: 2.16.840.1.101.3.4.2.2
- SHA512: 2.16.840.1.101.3.4.2.3
- SHA512: 2.16.840.1.101.3.4.2.3
The full hash prefixes for these are as follows:
これらのための完全なハッシュ接頭語は以下の通りです:
MD5: 0x30, 0x20, 0x30, 0x0C, 0x06, 0x08, 0x2A, 0x86,
0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05, 0x05, 0x00,
0x04, 0x10
MD5: 0×30 0×20 0×30 0x0C、0×06、0×08、0x2A、0×86、0×48、0×86、0xF7、0x0D、0×02、0×05、0×05、0×00、0×04、0×10
RIPEMD-160: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2B, 0x24,
0x03, 0x02, 0x01, 0x05, 0x00, 0x04, 0x14
RIPEMD-160: 0×30、0×21、0×30、0×09、0×06、0×05、0x2B、0×24、0×03、0×02、0×01、0×05、0×00、0×04、0×14
SHA-1: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2b, 0x0E,
0x03, 0x02, 0x1A, 0x05, 0x00, 0x04, 0x14
SHA-1: 0×30 0×21 0×30 0×09 0×06 0×05 0x2b、0x0E、0×03、0×02、0x1A、0×05、0×00、0×04、0×14
SHA224: 0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x04, 0x05,
0x00, 0x04, 0x1C
SHA224: 0×30 0×31、0×30、0x0d、0×06、0×09、0×60、0×86、0×48、0×01、0×65、0×03、0×04、0×02、0×04、0×05、0×00、0×04、0x1C
SHA256: 0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01, 0x05,
0x00, 0x04, 0x20
SHA256: 0×30、0×31、0×30、0x0d、0×06、0×09、0×60、0×86、0×48、0×01、0×65、0×03、0×04、0×02、0×01、0×05、0×00、0×04、0×20
SHA384: 0x30, 0x41, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02, 0x05,
0x00, 0x04, 0x30
SHA384: 0×30、0×41、0×30、0x0d、0×06、0×09、0×60、0×86、0×48、0×01、0×65、0×03、0×04、0×02、0×02、0×05、0×00、0×04、0×30
SHA512: 0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03, 0x05,
0x00, 0x04, 0x40
SHA512: 0×30、0×51、0×30、0x0d、0×06、0×09、0×60、0×86、0×48、0×01、0×65、0×03、0×04、0×02、0×03、0×05、0×00、0×04、0×40
DSA signatures MUST use hashes that are equal in size to the number of bits of q, the group generated by the DSA key's generator value.
DSA署名はサイズにおいてq(DSAキーのジェネレータ値によって作られたグループ)のビットの数と等しいハッシュを使用しなければなりません。
Callas, et al Standards Track [Page 23] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[23ページ]RFC4880OpenPGP Message Format2007年11月
If the output size of the chosen hash is larger than the number of bits of q, the hash result is truncated to fit by taking the number of leftmost bits equal to the number of bits of q. This (possibly truncated) hash function result is treated as a number and used directly in the DSA signature algorithm.
選ばれたハッシュの出力サイズがqのビットの数より大きいなら、ハッシュ結果は、qのビットの数と等しい一番左ビットの数を取ることによって合うように先端を切られます。 この(ことによると端が欠ける)のハッシュ関数結果は、数として扱われて、直接DSA署名アルゴリズムで使用されます。
5.2.3. Version 4 Signature Packet Format
5.2.3. バージョン4署名パケット・フォーマット
The body of a version 4 Signature packet contains:
バージョン4Signatureパケットのボディーは以下を含みます。
- One-octet version number (4).
- 1八重奏のバージョン番号(4)。
- One-octet signature type.
- 1八重奏の署名タイプ。
- One-octet public-key algorithm.
- 1八重奏の公開鍵アルゴリズム。
- One-octet hash algorithm.
- 1八重奏のハッシュアルゴリズム。
- Two-octet scalar octet count for following hashed subpacket data.
Note that this is the length in octets of all of the hashed
subpackets; a pointer incremented by this number will skip over
the hashed subpackets.
- 論じ尽くされた「副-パケット」データに従うための2八重奏のスカラの八重奏カウント。 これが論じ尽くされた「副-パケット」のすべての八重奏で長さであることに注意してください。 この数によって増加された指針は論じ尽くされた「副-パケット」を飛ばすでしょう。
- Hashed subpacket data set (zero or more subpackets).
- 「副-パケット」データセット(ゼロか、より多くの「副-パケット」)を論じ尽くしました。
- Two-octet scalar octet count for the following unhashed subpacket
data. Note that this is the length in octets of all of the
unhashed subpackets; a pointer incremented by this number will
skip over the unhashed subpackets.
- 以下のunhashed subpacketデータのための2八重奏のスカラの八重奏カウント。 これがunhashed subpacketsのすべての八重奏で長さであることに注意してください。 この数によって増加された指針はunhashed subpacketsを飛ばすでしょう。
- Unhashed subpacket data set (zero or more subpackets).
- Unhashed subpacketデータセット(ゼロか、より多くの「副-パケット」)。
- Two-octet field holding the left 16 bits of the signed hash
value.
- 署名しているハッシュ値の左の16ビットを持っている2八重奏の分野。
- One or more multiprecision integers comprising the signature.
This portion is algorithm specific, as described above.
- 署名を包括する1つ以上の多倍精度整数。 この部分は上で説明されるとして特定のアルゴリズムです。
The concatenation of the data being signed and the signature data from the version number through the hashed subpacket data (inclusive) is hashed. The resulting hash value is what is signed. The left 16 bits of the hash are included in the Signature packet to provide a quick test to reject some invalid signatures.
バージョン番号から論じ尽くされた「副-パケット」データ(包括的な)の署名されるデータと署名データの連結は論じ尽くされます。 結果として起こるハッシュ値は署名されることです。 ハッシュの左の16ビットは、いくつかの無効の署名を拒絶するために迅速なテストを提供するためにSignatureパケットに含まれています。
There are two fields consisting of Signature subpackets. The first field is hashed with the rest of the signature data, while the second is unhashed. The second set of subpackets is not cryptographically
Signature subpacketsから成る2つの分野があります。 署名データの残りに従って、最初の分野は論じ尽くされますが、2番目は「非-論じ尽く」されます。 「副-パケット」の2番目のセットは暗号でそうではありません。
Callas, et al Standards Track [Page 24] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[24ページ]RFC4880OpenPGP Message Format2007年11月
protected by the signature and should include only advisory information.
署名で保護して、顧問情報だけを含むべきです。
The algorithms for converting the hash function result to a signature are described in a section below.
ハッシュ関数結果を署名に変換するためのアルゴリズムは下のセクションで説明されます。
5.2.3.1. Signature Subpacket Specification
5.2.3.1. 署名Subpacket仕様
A subpacket data set consists of zero or more Signature subpackets. In Signature packets, the subpacket data set is preceded by a two- octet scalar count of the length in octets of all the subpackets. A pointer incremented by this number will skip over the subpacket data set.
「副-パケット」データセットはゼロか、より多くのSignature subpacketsから成ります。 Signatureパケットでは、すべての「副-パケット」の八重奏における、長さの2八重奏スカラカウントで「副-パケット」データセットは先行されています。 この数によって増加された指針は「副-パケット」データセットを飛ばすでしょう。
Each subpacket consists of a subpacket header and a body. The header consists of:
各「副-パケット」は「副-パケット」ヘッダーとボディーから成ります。 ヘッダーは以下から成ります。
- the subpacket length (1, 2, or 5 octets),
- 「副-パケット」の長さ(1、2、または5つの八重奏)
- the subpacket type (1 octet),
- 「副-パケット」タイプ(1つの八重奏)
and is followed by the subpacket-specific data.
そして、「副-パケット」特有のデータはあとに続いています。
The length includes the type octet but not this length. Its format is similar to the "new" format packet header lengths, but cannot have Partial Body Lengths. That is:
長さは、タイプ八重奏を含んでいますが、この長さに含んでいるというわけではありません。 形式は、「新しい」形式パケットヘッダ長と同様ですが、Partial Body Lengthsを持つことができません。 それは以下の通りです。
if the 1st octet < 192, then
lengthOfLength = 1
subpacketLen = 1st_octet
1最初の八重奏<192、当時のlengthOfLength=subpacketLenが最初の_八重奏と等しいなら
if the 1st octet >= 192 and < 255, then
lengthOfLength = 2
subpacketLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192
+ 最初の八重奏であるなら、>は192と<255と等しく、2次に、lengthOfLength=subpacketLen=((最初の_八重奏--192)<<8)は(第2_八重奏)+192です。
if the 1st octet = 255, then
lengthOfLength = 5
subpacket length = [four-octet scalar starting at 2nd_octet]
最初の八重奏が5「副-パケット」の255、当時のlengthOfLength=長さ=と等しいなら[2番目の_八重奏における4八重奏のスカラの始め]
The value of the subpacket type octet may be:
「副-パケット」タイプ八重奏の値は以下の通りです。
0 = Reserved
1 = Reserved
2 = Signature Creation Time
3 = Signature Expiration Time
4 = Exportable Certification
5 = Trust Signature
6 = Regular Expression
0 =は1つの=予約された2=署名作成時間3=署名満了時間4=輸出向きの証明5=信頼署名6=正規表現を控えました。
Callas, et al Standards Track [Page 25] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[25ページ]RFC4880OpenPGP Message Format2007年11月
7 = Revocable
8 = Reserved
9 = Key Expiration Time
10 = Placeholder for backward compatibility
11 = Preferred Symmetric Algorithms
12 = Revocation Key
13 = Reserved
14 = Reserved
15 = Reserved
16 = Issuer
17 = Reserved
18 = Reserved
19 = Reserved
20 = Notation Data
21 = Preferred Hash Algorithms
22 = Preferred Compression Algorithms
23 = Key Server Preferences
24 = Preferred Key Server
25 = Primary User ID
26 = Policy URI
27 = Key Flags
28 = Signer's User ID
29 = Reason for Revocation
30 = Features
31 = Signature Target
32 = Embedded Signature
100 To 110 = Private or experimental
7 = 予約された16=発行人17予約された予約された取消し都合のよい後方の互換性11のための主要なExpiration Time10=予約された廃止可能な8=9=プレースホルダ=Symmetric Algorithms12=Key13=14=15==は都合のよい予約された20=記法予約された18=19=Data21=Hash Algorithmsを予約しました; 22 = 署名Revocation30の主要なFlags28=方針プライマリUser都合のよい主要な都合のよいCompression Algorithms23=Server Preferences24=Key Server25=ID26=URI27=署名者のUser ID29=理由=特徴31=Target32は埋め込まれたSignature100とTo110=個人的であるか、または実験的に等しいです。
An implementation SHOULD ignore any subpacket of a type that it does not recognize.
実装SHOULDはそれが見分けないタイプのどんな「副-パケット」も無視します。
Bit 7 of the subpacket type is the "critical" bit. If set, it denotes that the subpacket is one that is critical for the evaluator of the signature to recognize. If a subpacket is encountered that is marked critical but is unknown to the evaluating software, the evaluator SHOULD consider the signature to be in error.
「副-パケット」タイプのビット7は「重要な」ビットです。 設定されるなら、それは、「副-パケット」が署名の評価者が認識するように重要なものであることを指示します。 重要であるとマークされましたが、評価ソフトウェアにおいて、未知であることの「副-パケット」が遭遇するなら、評価者SHOULDは、署名が間違っていると考えます。
An evaluator may "recognize" a subpacket, but not implement it. The purpose of the critical bit is to allow the signer to tell an evaluator that it would prefer a new, unknown feature to generate an error than be ignored.
評価者は、「副-パケット」を「認識します」が、それを実装しないかもしれません。 重要なビットの目的は署名者が、無視されるよりエラーを起こす新しくて、未知の特徴を好むと評価者に言うのを許容することです。
Implementations SHOULD implement the three preferred algorithm subpackets (11, 21, and 22), as well as the "Reason for Revocation" subpacket. Note, however, that if an implementation chooses not to implement some of the preferences, it is required to behave in a polite manner to respect the wishes of those users who do implement these preferences.
実装SHOULDは、3の都合のよいアルゴリズムが「副-パケット」(11、21、および22)と、「取消しの理由」「副-パケット」であると実装します。 しかしながら、実装が、好みのいくつかを実装しないのを選ぶなら、それがこれらの好みを実装するユーザの願望を尊敬するために丁寧な物腰で振る舞うのに必要であることに注意してください。
Callas, et al Standards Track [Page 26] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[26ページ]RFC4880OpenPGP Message Format2007年11月
5.2.3.2. Signature Subpacket Types
5.2.3.2. 署名Subpacketタイプ
A number of subpackets are currently defined. Some subpackets apply to the signature itself and some are attributes of the key. Subpackets that are found on a self-signature are placed on a certification made by the key itself. Note that a key may have more than one User ID, and thus may have more than one self-signature, and differing subpackets.
多くの「副-パケット」が現在、定義されます。 いくつかの「副-パケット」が署名自体に適用されます、そして、何かがキーの属性です。 自己署名に見つけられるSubpacketsはキー自体によってされた証明に置かれます。 キーが1UserのIDを持っていて、その結果、1つ以上の自己署名、および異なった「副-パケット」を持っているかもしれないことに注意してください。
A subpacket may be found either in the hashed or unhashed subpacket sections of a signature. If a subpacket is not hashed, then the information in it cannot be considered definitive because it is not part of the signature proper.
「副-パケット」は署名の論じ尽くすかunhashed subpacket部で見つけられるかもしれません。 「副-パケット」が論じ尽くされないなら、それが署名自体の一部でないので、決定的であるとそれの情報を考えることができません。
5.2.3.3. Notes on Self-Signatures
5.2.3.3. 自己署名に関する注
A self-signature is a binding signature made by the key to which the signature refers. There are three types of self-signatures, the certification signatures (types 0x10-0x13), the direct-key signature (type 0x1F), and the subkey binding signature (type 0x18). For certification self-signatures, each User ID may have a self- signature, and thus different subpackets in those self-signatures. For subkey binding signatures, each subkey in fact has a self- signature. Subpackets that appear in a certification self-signature apply to the user name, and subpackets that appear in the subkey self-signature apply to the subkey. Lastly, subpackets on the direct-key signature apply to the entire key.
自己署名は署名が参照されるキーによってされた拘束力がある署名です。 3つのタイプの自己署名、証明署名(0×10-0×13をタイプする)、ダイレクト調号(0x1Fをタイプする)、およびサブキーの拘束力がある署名があります(0×18をタイプしてください)。 証明自己署名のために、それぞれのUser IDはそれらの自己署名で自己署名、およびその結果異なった「副-パケット」を持っているかもしれません。 サブキーの拘束力がある署名のために、各サブキーには、事実上、自己署名があります。 証明自己署名に現れるSubpacketsがユーザ名に適用します、そして、サブキー自己署名に現れる「副-パケット」はサブキーに適用されます。 最後に、ダイレクト調号の「副-パケット」は全体のキーに適用されます。
Implementing software should interpret a self-signature's preference subpackets as narrowly as possible. For example, suppose a key has two user names, Alice and Bob. Suppose that Alice prefers the symmetric algorithm CAST5, and Bob prefers IDEA or TripleDES. If the software locates this key via Alice's name, then the preferred algorithm is CAST5; if software locates the key via Bob's name, then the preferred algorithm is IDEA. If the key is located by Key ID, the algorithm of the primary User ID of the key provides the preferred symmetric algorithm.
ソフトウェアを実装するのは、自己シグネチャーの好みの「副-パケット」が狭さ同じくらい可能であると解釈するべきです。 例えば、キーには2人のユーザの名前、アリス、およびボブがいると仮定してください。 アリスが左右対称のアルゴリズムCAST5を好むと仮定してください。そうすれば、ボブはIDEAかTripleDESを好みます。 ソフトウェアがアリスの名前でこのキーの場所を見つけるなら、都合のよいアルゴリズムはCAST5です。 ソフトウェアがボブの名前でキーの場所を見つけるなら、都合のよいアルゴリズムはIDEAです。 キーがKey IDによって見つけられているなら、キーのプライマリUser IDのアルゴリズムは都合のよい左右対称のアルゴリズムを提供します。
Revoking a self-signature or allowing it to expire has a semantic meaning that varies with the signature type. Revoking the self- signature on a User ID effectively retires that user name. The self-signature is a statement, "My name X is tied to my signing key K" and is corroborated by other users' certifications. If another user revokes their certification, they are effectively saying that they no longer believe that name and that key are tied together. Similarly, if the users themselves revoke their self-signature, then the users no longer go by that name, no longer have that email address, etc. Revoking a binding signature effectively retires that
自己署名を取り消すか、またはそれが期限が切れるのを許容するのにおいて、署名タイプに従って異なる意味意味があります。 Userで自己署名を取り消して、事実上、IDはそのユーザ名を回収します。 自己署名は、声明、「私の名前Xは私の署名キーKに結ばれ」て、他のユーザの証明で確証されます。 別のユーザが彼らの証明を取り消すなら、事実上、彼らは、もう名前とそのキーが結びつけられると信じていないと言っています。 同様に、ユーザ自身が彼らの自己署名を取り消すなら、ユーザは、もうその名前で行かないで、またもうそのEメールアドレスを持っていませんなど。 結合を取り消して、事実上、署名はそれを引退させます。
Callas, et al Standards Track [Page 27] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[27ページ]RFC4880OpenPGP Message Format2007年11月
subkey. Revoking a direct-key signature cancels that signature. Please see the "Reason for Revocation" subpacket (Section 5.2.3.23) for more relevant detail.
サブキー。 ダイレクト調号を取り消すと、その署名は中止されます。 「取消しの理由」「副-パケット」を見てください、(セクション5.2 .3 .23) より関連している詳細のために。
Since a self-signature contains important information about the key's use, an implementation SHOULD allow the user to rewrite the self- signature, and important information in it, such as preferences and key expiration.
自己署名がキーの使用に関する重要情報を含んで以来、SHOULDがそれで自己署名、および重要情報をユーザを書き直させる好みや主要な満了などの実装です。
It is good practice to verify that a self-signature imported into an implementation doesn't advertise features that the implementation doesn't support, rewriting the signature as appropriate.
実装にインポートされた自己署名が実装がサポートしない特徴の広告を出さないことを確かめるのは、良い習慣です、適宜署名を書き直して。
An implementation that encounters multiple self-signatures on the same object may resolve the ambiguity in any way it sees fit, but it is RECOMMENDED that priority be given to the most recent self- signature.
同じオブジェクトにおける複数の自己署名に遭遇する実装はそれが適していると決めるどんな方法でもあいまいさを取り除くかもしれませんが、最新の自己署名が優先するのは、RECOMMENDEDです。
5.2.3.4. Signature Creation Time
5.2.3.4. 署名作成時間
(4-octet time field)
(4八重奏の時間分野)
The time the signature was made.
署名がされた時。
MUST be present in the hashed area.
論じ尽くすところのプレゼントが領域であったならそうしなければなりません。
5.2.3.5. Issuer
5.2.3.5. 発行人
(8-octet Key ID)
(8八重奏の主要なID)
The OpenPGP Key ID of the key issuing the signature.
署名を発行するキーのOpenPGP Key ID。
5.2.3.6. Key Expiration Time
5.2.3.6. 主要な満了時間
(4-octet time field)
(4八重奏の時間分野)
The validity period of the key. This is the number of seconds after the key creation time that the key expires. If this is not present or has a value of zero, the key never expires. This is found only on a self-signature.
キーの有効期間。 キーが期限が切れる時間、これは主要な作成の後の秒数です。 これに、存在していないか、またはゼロの値があるなら、キーは決して期限が切れません。 これは自己署名だけに見つけられます。
5.2.3.7. Preferred Symmetric Algorithms
5.2.3.7. 都合のよい左右対称のアルゴリズム
(array of one-octet values)
(1八重奏の値の勢ぞろい)
Symmetric algorithm numbers that indicate which algorithms the key holder prefers to use. The subpacket body is an ordered list of octets with the most preferred listed first. It is assumed that only
主要な所有者が、どのアルゴリズムを使用するのを好むかを示す左右対称のアルゴリズム番号。 「副-パケット」ボディーは最初にリストアップされた大部分が好まれている八重奏の規則正しいリストです。 それが想定される、それ専用
Callas, et al Standards Track [Page 28] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[28ページ]RFC4880OpenPGP Message Format2007年11月
algorithms listed are supported by the recipient's software. Algorithm numbers are in Section 9. This is only found on a self- signature.
記載されたアルゴリズムは受取人のソフトウェアによってサポートされます。 アルゴリズム番号がセクション9にあります。 これは自己署名に見つけられるだけです。
5.2.3.8. Preferred Hash Algorithms
5.2.3.8. 都合のよいハッシュアルゴリズム
(array of one-octet values)
(1八重奏の値の勢ぞろい)
Message digest algorithm numbers that indicate which algorithms the key holder prefers to receive. Like the preferred symmetric algorithms, the list is ordered. Algorithm numbers are in Section 9. This is only found on a self-signature.
主要な所有者が、どのアルゴリズムを受けるのを好むかを示すメッセージダイジェストアルゴリズム番号。 都合のよい左右対称のアルゴリズムのように、リストは注文されます。 アルゴリズム番号がセクション9にあります。 これは自己署名に見つけられるだけです。
5.2.3.9. Preferred Compression Algorithms
5.2.3.9. 都合のよい圧縮アルゴリズム
(array of one-octet values)
(1八重奏の値の勢ぞろい)
Compression algorithm numbers that indicate which algorithms the key holder prefers to use. Like the preferred symmetric algorithms, the list is ordered. Algorithm numbers are in Section 9. If this subpacket is not included, ZIP is preferred. A zero denotes that uncompressed data is preferred; the key holder's software might have no compression software in that implementation. This is only found on a self-signature.
主要な所有者が、どのアルゴリズムを使用するのを好むかを示す圧縮アルゴリズム番号。 都合のよい左右対称のアルゴリズムのように、リストは注文されます。 アルゴリズム番号がセクション9にあります。 この「副-パケット」が含まれていないなら、ZIPは好まれます。 ゼロは、解凍されたデータが好まれるのを指示します。 主要な所有者のソフトウェアはその実装で圧縮ソフトを全く持っていないかもしれません。 これは自己署名に見つけられるだけです。
5.2.3.10. Signature Expiration Time
5.2.3.10. 署名満了時間
(4-octet time field)
(4八重奏の時間分野)
The validity period of the signature. This is the number of seconds after the signature creation time that the signature expires. If this is not present or has a value of zero, it never expires.
署名の有効期間。 署名が期限が切れる時間、これは署名作成の後の秒数です。 これに、存在していないか、またはゼロの値があるなら、それは決して期限が切れません。
5.2.3.11. Exportable Certification
5.2.3.11. 輸出向きの証明
(1 octet of exportability, 0 for not, 1 for exportable)
(「外-移植性」、0の1つの八重奏、1、輸出向き、)
This subpacket denotes whether a certification signature is "exportable", to be used by other users than the signature's issuer. The packet body contains a Boolean flag indicating whether the signature is exportable. If this packet is not present, the certification is exportable; it is equivalent to a flag containing a 1.
シグネチャーの発行人以外のユーザによって使用されるように証明署名が「輸出向きである」か否かに関係なく、この「副-パケット」は指示します。 パケットボディーは署名が輸出向きであるかどうかを示すブール旗を含みます。 このパケットが存在していないなら、証明は輸出向きです。 それは1を含む旗に同等です。
Non-exportable, or "local", certifications are signatures made by a user to mark a key as valid within that user's implementation only.
非輸出向き、または「地方です」、証明はそのユーザの実装だけの中で有効であるとしてキーをマークするのがユーザによってされた署名です。
Callas, et al Standards Track [Page 29] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[29ページ]RFC4880OpenPGP Message Format2007年11月
Thus, when an implementation prepares a user's copy of a key for transport to another user (this is the process of "exporting" the key), any local certification signatures are deleted from the key.
実装が輸送のためにユーザのキーのコピーを別のユーザに準備するとき(これはキーの「エクスポートする」であるプロセスです)、したがって、どんな地方の証明署名もキーから削除されます。
The receiver of a transported key "imports" it, and likewise trims any local certifications. In normal operation, there won't be any, assuming the import is performed on an exported key. However, there are instances where this can reasonably happen. For example, if an implementation allows keys to be imported from a key database in addition to an exported key, then this situation can arise.
輸送されたキーの受信機は、それ、および同様にトリムがあらゆる地方の証明であると「インポートします」。 通常、輸入がエクスポートしているキーに実行されると仮定すると、いずれも稼働中でないでしょう。 しかしながら、インスタンスがこれが合理的に起こることができるところにあります。 例えば、キーが実装でエクスポートしているキーに加えて主要なデータベースからインポートするなら、この状況は起こることができます。
Some implementations do not represent the interest of a single user (for example, a key server). Such implementations always trim local certifications from any key they handle.
いくつかの実装はシングルユーザー(例えば、主要なサーバ)の関心を表しません。 そのような実装はそれらが扱うどんなキーからも地方の証明をいつも整えます。
5.2.3.12. Revocable
5.2.3.12. 廃止可能
(1 octet of revocability, 0 for not, 1 for revocable)
(revocability、0の1つの八重奏、1、廃止可能である、)
Signature's revocability status. The packet body contains a Boolean flag indicating whether the signature is revocable. Signatures that are not revocable have any later revocation signatures ignored. They represent a commitment by the signer that he cannot revoke his signature for the life of his key. If this packet is not present, the signature is revocable.
シグネチャーのrevocability状態。 パケットボディーは署名が廃止可能であるかどうかを示すブール旗を含みます。 廃止可能でない署名で、どんな後の取消し署名も無視します。 彼らは署名者で委任を表します。彼は彼のキーの寿命のための署名を取り消すことができません。 このパケットが存在していないなら、署名は廃止可能です。
5.2.3.13. Trust Signature
5.2.3.13. 信頼署名
(1 octet "level" (depth), 1 octet of trust amount)
(1八重奏「レベル」(深さ)、信頼量の1つの八重奏)
Signer asserts that the key is not only valid but also trustworthy at the specified level. Level 0 has the same meaning as an ordinary validity signature. Level 1 means that the signed key is asserted to be a valid trusted introducer, with the 2nd octet of the body specifying the degree of trust. Level 2 means that the signed key is asserted to be trusted to issue level 1 trust signatures, i.e., that it is a "meta introducer". Generally, a level n trust signature asserts that a key is trusted to issue level n-1 trust signatures. The trust amount is in a range from 0-255, interpreted such that values less than 120 indicate partial trust and values of 120 or greater indicate complete trust. Implementations SHOULD emit values of 60 for partial trust and 120 for complete trust.
署名者は、キーが有効であるだけではなく、指定されたレベルで信頼できもすると断言します。 レベル0に、普通の正当性署名と同じ意味があります。 レベル1は、署名しているキーが有効な信じられた誘導子であると断言されることを意味します、ボディーの2番目の八重奏が信頼の度合いを指定していて。 レベル2は署名しているキーが問題レベル1信頼署名に任せられるために断言されて、すなわち、それが「メタ誘導子」であると意味します。 一般に、平らなn信頼署名は、キーが平らなn-1信頼署名を発行すると信じられると断言します。 信頼量は範囲で0-255から来ています、120未満が、120以上の部分的な信頼と値が示すのを示す値が信頼を完成するように解釈されて。 実装SHOULDは部分的な信頼のための60と完全な信頼のための120の値を放ちます。
Callas, et al Standards Track [Page 30] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[30ページ]RFC4880OpenPGP Message Format2007年11月
5.2.3.14. Regular Expression
5.2.3.14. 正規表現
(null-terminated regular expression)
(ヌルで終えられた正規表現)
Used in conjunction with trust Signature packets (of level > 0) to limit the scope of trust that is extended. Only signatures by the target key on User IDs that match the regular expression in the body of this packet have trust extended by the trust Signature subpacket. The regular expression uses the same syntax as the Henry Spencer's "almost public domain" regular expression [REGEX] package. A description of the syntax is found in Section 8 below.
信頼Signatureパケット(平らな>0の)に関連して、拡張信頼の範囲を制限するのに使用されます。 このパケットのボディーで正規表現に合っているUser IDで主要な目標による署名だけで、信頼Signature subpacketは信頼を広げます。 正規表現はヘンリー・スペンサーの「ほとんど公共の場」正規表現[REGEX]パッケージと同じ構文を使用します。 構文の記述は以下のセクション8で見つけられます。
5.2.3.15. Revocation Key
5.2.3.15. 取消しキー
(1 octet of class, 1 octet of public-key algorithm ID, 20 octets of fingerprint)
(クラスの1つの八重奏、公開鍵アルゴリズムIDの1つの八重奏、指紋の20の八重奏)
Authorizes the specified key to issue revocation signatures for this key. Class octet must have bit 0x80 set. If the bit 0x40 is set, then this means that the revocation information is sensitive. Other bits are for future expansion to other kinds of authorizations. This is found on a self-signature.
指定されたキーがこのキーのための取消し署名を発行するのを認可します。 クラス八重奏で、ビット0x80を設定しなければなりません。 ビット0x40が設定されるなら、これは、取消し情報が機密であることを意味します。 他のビットは他の種類の承認への今後の拡張のためのものです。 これは自己署名に見つけられます。
If the "sensitive" flag is set, the keyholder feels this subpacket contains private trust information that describes a real-world sensitive relationship. If this flag is set, implementations SHOULD NOT export this signature to other users except in cases where the data needs to be available: when the signature is being sent to the designated revoker, or when it is accompanied by a revocation signature from that revoker. Note that it may be appropriate to isolate this subpacket within a separate signature so that it is not combined with other subpackets that need to be exported.
「敏感な」旗が設定されるなら、keyholderは、この「副-パケット」が本当の世界の敏感な関係について説明する個人信託情報を含むと感じます。 この旗が設定されるなら、データが利用可能である必要があるケースの中を除いて、実装SHOULD NOTは他のユーザにこの署名をエクスポートします: 指定されたrevokerかそれともそのrevokerからの取消し署名でそれがいつ伴われるかに署名を送るとき。 それがエクスポートされる必要がある他の「副-パケット」に結合されないように、別々の署名の中でこの「副-パケット」を隔離するのが適切であるかもしれないことに注意してください。
5.2.3.16. Notation Data
5.2.3.16. 記法データ
(4 octets of flags, 2 octets of name length (M),
2 octets of value length (N),
M octets of name data,
N octets of value data)
(旗の4つの八重奏、名前の長さ(M)の2つの八重奏、値の長さ(N)の2つの八重奏、名前データのM八重奏、値のデータのN八重奏)
This subpacket describes a "notation" on the signature that the issuer wishes to make. The notation has a name and a value, each of which are strings of octets. There may be more than one notation in a signature. Notations can be used for any extension the issuer of the signature cares to make. The "flags" field holds four octets of flags.
この「副-パケット」は発行人がしたがっている署名のときに「記法」について説明します。 記法には、名前と値があります。それはそれぞれ八重奏のストリングです。 署名には1つ以上の記法があるかもしれません。 署名の発行人がするのを気にかけるどんな拡大にも記法を使用できます。 「旗」分野は旗の4つの八重奏を保持します。
Callas, et al Standards Track [Page 31] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[31ページ]RFC4880OpenPGP Message Format2007年11月
All undefined flags MUST be zero. Defined flags are as follows:
すべての未定義の旗がゼロであるに違いありません。 定義された旗は以下の通りです:
First octet: 0x80 = human-readable. This note value is text.
Other octets: none.
最初の八重奏: 0×80が等しい、人間読み込み可能です。 この注意値はテキストです。 他の八重奏: なし。
Notation names are arbitrary strings encoded in UTF-8. They reside in two namespaces: The IETF namespace and the user namespace.
記法名はUTF-8でコード化された任意のストリングです。 彼らは2つの名前空間で住んでいます: IETF名前空間とユーザ名前空間。
The IETF namespace is registered with IANA. These names MUST NOT contain the "@" character (0x40). This is a tag for the user namespace.
IETF名前空間はIANAに登録されます。 これらの名前は"@"キャラクタ(0×40)を含んではいけません。 これはユーザ名前空間のためのタグです。
Names in the user namespace consist of a UTF-8 string tag followed by "@" followed by a DNS domain name. Note that the tag MUST NOT contain an "@" character. For example, the "sample" tag used by Example Corporation could be "sample@example.com".
ユーザ名前空間における名前はDNSドメイン名があとに続いた"@"によって続かれたUTF-8ストリングタグから成ります。 タグが"@"キャラクタを含んではいけないことに注意してください。 例えば、Example社によって使用された「サンプル」タグは" sample@example.com "であるかもしれません。
Names in a user space are owned and controlled by the owners of that domain. Obviously, it's bad form to create a new name in a DNS space that you don't own.
ユーザスペースの名前は、そのドメインの所有者によって所有されて、制御されます。 明らかに、それはあなたが所有していないDNSスペースで新しい名前を作成する無作法です。
Since the user namespace is in the form of an email address, implementers MAY wish to arrange for that address to reach a person who can be consulted about the use of the named tag. Note that due to UTF-8 encoding, not all valid user space name tags are valid email addresses.
ユーザ名前空間がEメールアドレスの形にあるので、implementersは、そのアドレスが命名されたタグの使用に関して相談できる人に届くように手配したがっているかもしれません。 UTF-8コード化のために、すべての正規ユーザースペース名札が有効なEメールアドレスであるというわけではないことに注意してください。
If there is a critical notation, the criticality applies to that specific notation and not to notations in general.
重要な記法があれば、臨界は一般に、記法ではなく、その特定の記法に適用されます。
5.2.3.17. Key Server Preferences
5.2.3.17. 主要なサーバ好み
(N octets of flags)
(旗のN八重奏)
This is a list of one-bit flags that indicate preferences that the key holder has about how the key is handled on a key server. All undefined flags MUST be zero.
これはキーが主要なサーバでどう扱われるかに関して主要な所有者が持っている好みを示す1ビットの旗のリストです。すべての未定義の旗がゼロであるに違いありません。
First octet: 0x80 = No-modify
the key holder requests that this key only be modified or updated
by the key holder or an administrator of the key server.
最初の八重奏: 0×80 = このキーが主要な所有者か主要なサーバの管理者によって変更されるか、またはアップデートされるだけであるという主要な所有者要求を変更しないでください。
This is found only on a self-signature.
これは自己署名だけに見つけられます。
Callas, et al Standards Track [Page 32] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[32ページ]RFC4880OpenPGP Message Format2007年11月
5.2.3.18. Preferred Key Server
5.2.3.18. 都合のよい主要なサーバ
(String)
(ストリング)
This is a URI of a key server that the key holder prefers be used for updates. Note that keys with multiple User IDs can have a preferred key server for each User ID. Note also that since this is a URI, the key server can actually be a copy of the key retrieved by ftp, http, finger, etc.
これによるaのURIがアップデートにおいて使用されていた状態で所有者が好むキーがあるサーバを合わせるということです。 複数のUser IDがあるキーが都合のよいそれぞれのUser IDに、主要なサーバを持つことができることに注意してください。 また、主要なサーバがこれがURIであるので実際にftp、http、指などによって検索されたキーのコピーであるかもしれないことに注意してください。
5.2.3.19. Primary User ID
5.2.3.19. 主たる利用者ID
(1 octet, Boolean)
(1つの八重奏と、ブール)です。
This is a flag in a User ID's self-signature that states whether this User ID is the main User ID for this key. It is reasonable for an implementation to resolve ambiguities in preferences, etc. by referring to the primary User ID. If this flag is absent, its value is zero. If more than one User ID in a key is marked as primary, the implementation may resolve the ambiguity in any way it sees fit, but it is RECOMMENDED that priority be given to the User ID with the most recent self-signature.
これはこのキーのためにこのUser IDが主なUser IDであるかどうかと述べるUser IDの自己署名で旗です。 実装がプライマリUser IDについて言及することによって好みなどにおけるあいまいさを取り除くのは、妥当です。 この旗が欠けるなら、値はゼロです。 キーの1UserのIDがプライマリであることが示されるなら、実装はそれが適していると決めるどんな方法でもあいまいさを取り除くかもしれませんが、User IDが最新の自己署名と共に優先するのは、RECOMMENDEDです。
When appearing on a self-signature on a User ID packet, this subpacket applies only to User ID packets. When appearing on a self-signature on a User Attribute packet, this subpacket applies only to User Attribute packets. That is to say, there are two different and independent "primaries" -- one for User IDs, and one for User Attributes.
User IDパケットの上で自己署名に見えるとき、この「副-パケット」はUser IDパケットだけに適用されます。 User Attributeパケットの上で自己署名に見えるとき、この「副-パケット」はUser Attributeパケットだけに適用されます。 すなわち、2異なって独立している「予備選挙」--1つがUser ID、およびUser Attributesのためのもののためにあります。
5.2.3.20. Policy URI
5.2.3.20. 方針URI
(String)
(ストリング)
This subpacket contains a URI of a document that describes the policy under which the signature was issued.
この「副-パケット」は署名が発行された方針を説明するドキュメントのURIを含んでいます。
5.2.3.21. Key Flags
5.2.3.21. 主要な旗
(N octets of flags)
(旗のN八重奏)
This subpacket contains a list of binary flags that hold information about a key. It is a string of octets, and an implementation MUST NOT assume a fixed size. This is so it can grow over time. If a list is shorter than an implementation expects, the unstated flags are considered to be zero. The defined flags are as follows:
この「副-パケット」はキーの情報を保持する2進の旗のリストを含んでいます。 それは一連の八重奏です、そして、実装は固定サイズを仮定してはいけません。 これは、時間がたつにつれて成長できるようにそうです。 リストが実装が予想するより短いなら、非論述された旗はゼロであると考えられます。 定義された旗は以下の通りです:
Callas, et al Standards Track [Page 33] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[33ページ]RFC4880OpenPGP Message Format2007年11月
First octet:
最初の八重奏:
0x01 - This key may be used to certify other keys.
0×01--このキーは、他のキーを公認するのに使用されるかもしれません。
0x02 - This key may be used to sign data.
0×02--このキーは、データに署名するのに使用されるかもしれません。
0x04 - This key may be used to encrypt communications.
0×04--このキーは、コミュニケーションを暗号化するのに使用されるかもしれません。
0x08 - This key may be used to encrypt storage.
0×08--このキーは、ストレージを暗号化するのに使用されるかもしれません。
0x10 - The private component of this key may have been split
by a secret-sharing mechanism.
0×10--このキーの個人的な部品は秘密を共有しているメカニズムによって分けられたかもしれません。
0x20 - This key may be used for authentication.
0×20--このキーは認証に使用されるかもしれません。
0x80 - The private component of this key may be in the
possession of more than one person.
0×80--このキーの個人的な部品が複数の人の所有物にあるかもしれません。
Usage notes:
使用上の注意:
The flags in this packet may appear in self-signatures or in certification signatures. They mean different things depending on who is making the statement -- for example, a certification signature that has the "sign data" flag is stating that the certification is for that use. On the other hand, the "communications encryption" flag in a self-signature is stating a preference that a given key be used for communications. Note however, that it is a thorny issue to determine what is "communications" and what is "storage". This decision is left wholly up to the implementation; the authors of this document do not claim any special wisdom on the issue and realize that accepted opinion may change.
このパケットの旗は自己署名か証明署名に現れるかもしれません。 彼らはだれが声明を出しているかによる別物を意味します--例えば、「サインデータ」旗を持っている証明署名は、証明がその使用のためのものであると述べています。 他方では、自己署名における「コミュニケーション暗号化」旗はコミュニケーションにおいて使用されていた状態で与えられたキーがある優先を述べています。 しかしながら、なにかを決定するかが、とげがある問題であることが「コミュニケーション」と何が「ストレージ」であるかということであることに注意してください。 この決定は完全に実装に任せられます。 このドキュメントの作者は、問題でどんな特別な知恵も主張して、一般世論が変化するかもしれないとわかりません。
The "split key" (0x10) and "group key" (0x80) flags are placed on a self-signature only; they are meaningless on a certification signature. They SHOULD be placed only on a direct-key signature (type 0x1F) or a subkey signature (type 0x18), one that refers to the key the flag applies to.
(0×80)「分裂キー」(0×10)と「グループキー」旗が自己署名だけに置かれます。 それらは証明署名のときに無意味です。 それら、SHOULD、ダイレクト調号(0x1Fをタイプする)かサブキー署名(0×18をタイプします)(旗が当てはまるキーについて言及するもの)だけに置かれてください。
5.2.3.22. Signer's User ID
5.2.3.22. 署名者のユーザID
(String)
(ストリング)
This subpacket allows a keyholder to state which User ID is responsible for the signing. Many keyholders use a single key for different purposes, such as business communications as well as personal communications. This subpacket allows such a keyholder to state which of their roles is making a signature.
この「副-パケット」はどのUser IDが署名に責任があるかをkeyholderを述べさせます。 多くのkeyholdersが個人的なコミュニケーションと同様に商用通信などの異なる役割に単一のキーを使用します。 この「副-パケット」はそれらの役割で署名をしている州にそのようなkeyholderを許容します。
Callas, et al Standards Track [Page 34] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[34ページ]RFC4880OpenPGP Message Format2007年11月
This subpacket is not appropriate to use to refer to a User Attribute packet.
この「副-パケット」はUser Attributeパケットについて言及するのに使用するのが適切ではありません。
5.2.3.23. Reason for Revocation
5.2.3.23. 取消しの理由
(1 octet of revocation code, N octets of reason string)
(取消しコードの1つの八重奏、理由ストリングのN八重奏)
This subpacket is used only in key revocation and certification revocation signatures. It describes the reason why the key or certificate was revoked.
この「副-パケット」は主要な取消しと証明取消し署名だけに使用されます。 それはキーか証明書が取り消された理由について説明します。
The first octet contains a machine-readable code that denotes the reason for the revocation:
最初の八重奏は取消しの理由を指示する機械可読コードを含んでいます:
0 - No reason specified (key revocations or cert revocations)
1 - Key is superseded (key revocations)
2 - Key material has been compromised (key revocations)
3 - Key is retired and no longer used (key revocations)
32 - User ID information is no longer valid (cert revocations)
100-110 - Private Use
0--指定されて(主要な取消しか本命取消し)、1--キーによる取って代わられて(主要な取消し)、2--主要な材料が3であると感染されたという(主要な取消し)ことです--キーは退職してもう使用されなかった(主要な取消し)32です--ユーザID情報がもう100-110に有効でない(本命取消し)理由がありません--個人的なUse
Following the revocation code is a string of octets that gives information about the Reason for Revocation in human-readable form (UTF-8). The string may be null, that is, of zero length. The length of the subpacket is the length of the reason string plus one. An implementation SHOULD implement this subpacket, include it in all revocation signatures, and interpret revocations appropriately. There are important semantic differences between the reasons, and there are thus important reasons for revoking signatures.
取消しコードに従うのは、Revocationのために人間読み込み可能なフォーム(UTF-8)でReasonに関して知らせる一連の八重奏です。 ストリングがヌルであるかもしれない、それはゼロ・レングスがそうです。 「副-パケット」の長さは理由ストリングと1の長さです。 実装SHOULDは適切にこの「副-パケット」を実装して、すべての取消し署名にそれを含んで、取消しを解釈します。 理由の間には、重要な意味違いがあります、そして、その結果、署名を取り消す重要な理由があります。
If a key has been revoked because of a compromise, all signatures created by that key are suspect. However, if it was merely superseded or retired, old signatures are still valid. If the revoked signature is the self-signature for certifying a User ID, a revocation denotes that that user name is no longer in use. Such a revocation SHOULD include a 0x20 code.
キーが感染で取り消されたなら、そのキーによって作成されたすべての署名が疑わしいです。 しかしながら、それが単に取って代わられるか、または退職していたなら、古い署名はまだ有効です。 取り消された署名がUser IDを公認するための自己署名であるなら、取消しは、そのユーザ名がもう使用中でないことを指示します。 そのような取消しSHOULDは0×20コードを含んでいます。
Note that any signature may be revoked, including a certification on some other person's key. There are many good reasons for revoking a certification signature, such as the case where the keyholder leaves the employ of a business with an email address. A revoked certification is no longer a part of validity calculations.
ある他の人のキーにおける証明を含んでいて、どんな署名も取り消されるかもしれないことに注意してください。 証明署名を取り消す多くのもっともな理由があります、keyholderが企業の雇用をEメールアドレスに預けるケースなどのように。 取り消された証明はもう正当性計算の一部ではありません。
Callas, et al Standards Track [Page 35] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[35ページ]RFC4880OpenPGP Message Format2007年11月
5.2.3.24. Features
5.2.3.24. 特徴
(N octets of flags)
(旗のN八重奏)
The Features subpacket denotes which advanced OpenPGP features a user's implementation supports. This is so that as features are added to OpenPGP that cannot be backwards-compatible, a user can state that they can use that feature. The flags are single bits that indicate that a given feature is supported.
Features subpacketはユーザの実装がサポートするどの高度なOpenPGPの特徴を指示するか。 これは、特徴が後方に互換性があるはずがないOpenPGPに加えられるときユーザが、その特徴を使用できると述べることができるためのそうです。 旗は与えられた特徴がサポートされるのを示す単一のビットです。
This subpacket is similar to a preferences subpacket, and only appears in a self-signature.
この「副-パケット」は、好みの「副-パケット」と同様であり、自己署名に現れるだけです。
An implementation SHOULD NOT use a feature listed when sending to a user who does not state that they can use it.
彼らがそれを使用できると述べないユーザに発信するとき特徴が記載した実装SHOULD NOT使用。
Defined features are as follows:
定義された特徴は以下の通りです:
First octet:
最初の八重奏:
0x01 - Modification Detection (packets 18 and 19)
0×01--変更検出(パケット18と19)
If an implementation implements any of the defined features, it SHOULD implement the Features subpacket, too.
実装は、定義のどれかが特徴であると実装して、それはSHOULDです。また、Features subpacketを実装してください。
An implementation may freely infer features from other suitable implementation-dependent mechanisms.
実装は自由に他の適当な実装依存性機序からの特徴を推論するかもしれません。
5.2.3.25. Signature Target
5.2.3.25. 署名目標
(1 octet public-key algorithm, 1 octet hash algorithm, N octets hash)
(1つの八重奏公開鍵アルゴリズム、N八重奏が論じ尽くす1つの八重奏ハッシュアルゴリズム)
This subpacket identifies a specific target signature to which a signature refers. For revocation signatures, this subpacket provides explicit designation of which signature is being revoked. For a third-party or timestamp signature, this designates what signature is signed. All arguments are an identifier of that target signature.
この「副-パケット」は署名が参照される特定の目標署名を特定します。 取消し署名のために、この「副-パケット」はどの署名が取り消されるかに関する明白な名称を提供します。 第三者かタイムスタンプ署名のために、これは署名が署名されることを指定します。 すべての議論がその目標署名に関する識別子です。
The N octets of hash data MUST be the size of the hash of the signature. For example, a target signature with a SHA-1 hash MUST have 20 octets of hash data.
ハッシュデータのN八重奏が署名のハッシュのサイズであるに違いありません。 例えば、SHA-1ハッシュがある目標署名には、ハッシュデータの20の八重奏がなければなりません。
Callas, et al Standards Track [Page 36] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[36ページ]RFC4880OpenPGP Message Format2007年11月
5.2.3.26. Embedded Signature
5.2.3.26. 埋め込まれた署名
(1 signature packet body)
(1つの署名パケット本体)
This subpacket contains a complete Signature packet body as specified in Section 5.2 above. It is useful when one signature needs to refer to, or be incorporated in, another signature.
この「副-パケット」は上のセクション5.2における指定されるとしての完全なSignatureパケットボディーを含んでいます。 言及するか、または組み込む1つの署名の必要性であるときに、それは役に立って、別のものは署名です。
5.2.4. Computing Signatures
5.2.4. 署名を計算します。
All signatures are formed by producing a hash over the signature data, and then using the resulting hash in the signature algorithm.
すべての署名が、署名データの上にハッシュを生産して、次に、署名アルゴリズムで結果として起こるハッシュを使用することによって、形成されます。
For binary document signatures (type 0x00), the document data is hashed directly. For text document signatures (type 0x01), the document is canonicalized by converting line endings to <CR><LF>, and the resulting data is hashed.
2進のドキュメント署名(0×00をタイプする)において、ドキュメントデータは直接論じ尽くされます。 テキストドキュメント署名(0×01をタイプする)において、ドキュメントは<CR><LF>の系列結末を変換することによって、canonicalizedされます、そして、結果として起こるデータは論じ尽くされます。
When a signature is made over a key, the hash data starts with the octet 0x99, followed by a two-octet length of the key, and then body of the key packet. (Note that this is an old-style packet header for a key packet with two-octet length.) A subkey binding signature (type 0x18) or primary key binding signature (type 0x19) then hashes the subkey using the same format as the main key (also using 0x99 as the first octet). Key revocation signatures (types 0x20 and 0x28) hash only the key being revoked.
キーであることを署名を変更されると、ハッシュデータは、キーの2八重奏の長さがあとに続いた八重奏0x99から始まって、主要なパケットのボディーから始まります。 (これが2八重奏の長さがある主要なパケットのための古いスタイルパケットのヘッダーであることに注意してください。) そして、メインキーと同じ形式を使用することで(また、最初の八重奏として0×99を使用して)サブキーの拘束力がある署名(0×18をタイプする)か主キーの拘束力がある署名(0×19をタイプする)がサブキーを論じ尽くします。 主要な取消し署名(0×20と0×28をタイプする)は取り消されるキーだけを論じ尽くします。
A certification signature (type 0x10 through 0x13) hashes the User ID being bound to the key into the hash context after the above data. A V3 certification hashes the contents of the User ID or attribute packet packet, without any header. A V4 certification hashes the constant 0xB4 for User ID certifications or the constant 0xD1 for User Attribute certifications, followed by a four-octet number giving the length of the User ID or User Attribute data, and then the User ID or User Attribute data.
証明署名(0×10から0×13に、タイプする)は上記のデータの後のハッシュ文脈にキーに縛られるUser IDを論じ尽くします。 V3証明は少しもヘッダーなしでUser IDか属性パケットパケットのコンテンツを論じ尽くします。 V4証明は、User IDかUser Attributeデータの長さを与える4八重奏の数があとに続いたUser ID証明のための一定の0xB4かUser Attribute証明のための一定の0xD1を論じ尽くして、次に、User IDかUser Attributeデータを論じ尽くします。
When a signature is made over a Signature packet (type 0x50), the hash data starts with the octet 0x88, followed by the four-octet length of the signature, and then the body of the Signature packet. (Note that this is an old-style packet header for a Signature packet with the length-of-length set to zero.) The unhashed subpacket data of the Signature packet being hashed is not included in the hash, and the unhashed subpacket data length value is set to zero.
Signatureパケットであることを署名を変更されると(0×50をタイプしてください)、ハッシュデータは、署名の4八重奏の長さがあとに続いた八重奏0x88から始まって、Signatureパケットのボディーから始まります。 (これがゼロに設定された長さの長さがあるSignatureパケットのための古いスタイルパケットのヘッダーであることに注意してください。) 論じ尽くされるSignatureパケットに関するunhashed subpacketデータはハッシュ、および合わせてください値が設定されるゼロunhashed subpacketデータの長さに含まれていません。
Once the data body is hashed, then a trailer is hashed. A V3 signature hashes five octets of the packet body, starting from the signature type field. This data is the signature type, followed by the four-octet signature time. A V4 signature hashes the packet body
一度、データ本体は論じ尽くされて、次に、トレーラは論じ尽くされます。 署名タイプ野原から始めて、V3署名はパケットボディーの5つの八重奏を論じ尽くします。 このデータは4八重奏の署名時間までにいうことになられる署名タイプです。 V4署名はパケットボディーを論じ尽くします。
Callas, et al Standards Track [Page 37] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[37ページ]RFC4880OpenPGP Message Format2007年11月
starting from its first field, the version number, through the end of the hashed subpacket data. Thus, the fields hashed are the signature version, the signature type, the public-key algorithm, the hash algorithm, the hashed subpacket length, and the hashed subpacket body.
論じ尽くされた「副-パケット」データの終わりまで最初の分野、バージョン番号から始めます。 したがって、論じ尽くされた分野は、署名バージョンと、署名タイプと、公開鍵アルゴリズムと、ハッシュアルゴリズムと、論じ尽くされた「副-パケット」の長さと、論じ尽くされた「副-パケット」ボディーです。
V4 signatures also hash in a final trailer of six octets: the version of the Signature packet, i.e., 0x04; 0xFF; and a four-octet, big-endian number that is the length of the hashed data from the Signature packet (note that this number does not include these final six octets).
また、V4署名は6の最終的なトレーラで八重奏を論じ尽くします: すなわち、Signatureパケットのバージョン、0×04。 0xFF。 そして、4八重奏(Signatureパケット(この数がこれらの最終的な6つの八重奏を含んでいないことに注意する)からの論じ尽くされたデータの長さであるビッグエンディアン番号)。
After all this has been hashed in a single hash context, the resulting hash field is used in the signature algorithm and placed at the end of the Signature packet.
このすべてがただ一つのハッシュ文脈で論じ尽くされた後に、結果として起こるハッシュ野原は、署名アルゴリズムで使用されて、Signatureパケットの端に置かれます。
5.2.4.1. Subpacket Hints
5.2.4.1. Subpacketは暗示します。
It is certainly possible for a signature to contain conflicting information in subpackets. For example, a signature may contain multiple copies of a preference or multiple expiration times. In most cases, an implementation SHOULD use the last subpacket in the signature, but MAY use any conflict resolution scheme that makes more sense. Please note that we are intentionally leaving conflict resolution to the implementer; most conflicts are simply syntax errors, and the wishy-washy language here allows a receiver to be generous in what they accept, while putting pressure on a creator to be stingy in what they generate.
確かに、署名が「副-パケット」に闘争情報を含むのは、可能です。 例えば、署名は優先の複数のコピーか複数の満了回を含むかもしれません。 多くの場合、実装SHOULDは署名における最後の「副-パケット」を使用しますが、より多く理解できるどんな紛争解決体系も使用するかもしれません。 私たちは故意に紛争解決をimplementerに残しています。 ほとんどの闘争が単に構文エラーです、そして、ここの薄い言語はそれらが生成することでけちになるようにクリエイターに圧力を加えている間、受信機がそれらが受け入れるもので豊富であることを許容します。
Some apparent conflicts may actually make sense -- for example, suppose a keyholder has a V3 key and a V4 key that share the same RSA key material. Either of these keys can verify a signature created by the other, and it may be reasonable for a signature to contain an issuer subpacket for each key, as a way of explicitly tying those keys to the signature.
いくつかの明らかな矛盾が実際に理解できるかもしれません--例えば、keyholderには同じRSAの主要な材料を共有するV3キーとV4キーがあると仮定してください。 これらのキーのどちらかがもう片方によって作成された署名について確かめることができます、そして、署名が各キーのための発行人「副-パケット」を含むのは、妥当であるかもしれません、明らかにそれらのキーを署名に結ぶ方法として。
5.3. Symmetric-Key Encrypted Session Key Packets (Tag 3)
5.3. 対称鍵の暗号化されたセッション主要なパケット(タグ3)
The Symmetric-Key Encrypted Session Key packet holds the symmetric-key encryption of a session key used to encrypt a message. Zero or more Public-Key Encrypted Session Key packets and/or Symmetric-Key Encrypted Session Key packets may precede a Symmetrically Encrypted Data packet that holds an encrypted message. The message is encrypted with a session key, and the session key is itself encrypted and stored in the Encrypted Session Key packet or the Symmetric-Key Encrypted Session Key packet.
Symmetric主要なEncrypted Session Keyパケットは、セッションキーの共通鍵暗号がメッセージを暗号化するのに使用されるままにします。 ゼロか、よりPublic主要なEncrypted Session Keyパケット、そして/または、Symmetric主要なEncrypted Session Keyパケットが暗号化メッセージを保持するSymmetrically Encrypted Dataパケットに先行するかもしれません。 メッセージがセッションキーで暗号化されて、セッションキーは、Encrypted Session KeyパケットかSymmetric主要なEncrypted Session Keyパケットに暗号化されて、保存されます。
Callas, et al Standards Track [Page 38] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[38ページ]RFC4880OpenPGP Message Format2007年11月
If the Symmetrically Encrypted Data packet is preceded by one or more Symmetric-Key Encrypted Session Key packets, each specifies a passphrase that may be used to decrypt the message. This allows a message to be encrypted to a number of public keys, and also to one or more passphrases. This packet type is new and is not generated by PGP 2.x or PGP 5.0.
1つ以上のSymmetric主要なEncrypted Session KeyパケットがSymmetrically Encrypted Dataパケットに先行するなら、それぞれがメッセージを解読するのに使用されるかもしれないパスフレーズを指定します。 これは多くの公開鍵と、そして、1つ以上のパスフレーズにも暗号化されるべきメッセージを許容します。 このパケットタイプは、新しく、PGP 2.xかPGP5.0によって生成されません。
The body of this packet consists of:
このパケットのボディーは以下から成ります。
- A one-octet version number. The only currently defined version
is 4.
- 1八重奏のバージョン番号。 唯一の現在定義されたバージョンが4です。
- A one-octet number describing the symmetric algorithm used.
- 使用される左右対称のアルゴリズムを説明する1八重奏の数。
- A string-to-key (S2K) specifier, length as defined above.
- キーへのストリング(S2K)特許説明書の作成書、上で定義される長さ。
- Optionally, the encrypted session key itself, which is decrypted
with the string-to-key object.
- 任意に、暗号化されたセッションキー自体であり、どれがストリングからキーで解読されるかは反対します。
If the encrypted session key is not present (which can be detected on the basis of packet length and S2K specifier size), then the S2K algorithm applied to the passphrase produces the session key for decrypting the file, using the symmetric cipher algorithm from the Symmetric-Key Encrypted Session Key packet.
暗号化されたセッションキーが存在していないなら(パケット長とS2K特許説明書の作成書サイズに基づいて検出できます)、パスフレーズに適用されたS2Kアルゴリズムはファイルを解読するのに、主要なセッションを起こします、Symmetric主要なEncrypted Session Keyパケットから左右対称の暗号アルゴリズムを使用して。
If the encrypted session key is present, the result of applying the S2K algorithm to the passphrase is used to decrypt just that encrypted session key field, using CFB mode with an IV of all zeros. The decryption result consists of a one-octet algorithm identifier that specifies the symmetric-key encryption algorithm used to encrypt the following Symmetrically Encrypted Data packet, followed by the session key octets themselves.
暗号化されたセッションキーが存在しているなら、S2Kアルゴリズムをパスフレーズに適用するという結果はまさしくその暗号化されたセッションキーフィールドを解読するのに使用されます、すべてのゼロのIVがあるCFBモードを使用して。 復号化結果はセッションの主要な八重奏自体があとに続いた以下のSymmetrically Encrypted Dataパケットを暗号化するのに使用される共通鍵暗号アルゴリズムを指定する1八重奏のアルゴリズム識別子から成ります。
Note: because an all-zero IV is used for this decryption, the S2K specifier MUST use a salt value, either a Salted S2K or an Iterated-Salted S2K. The salt value will ensure that the decryption key is not repeated even if the passphrase is reused.
以下に注意してください。 この復号化において、オールゼロIVが使用されているので、S2K特許説明書の作成書は塩の値(Salted S2KかIteratedが塩漬けにしたS2Kのどちらか)を使用しなければなりません。 塩の値は、パスフレーズが再利用されても復号化キーが繰り返されないのを確実にするでしょう。
5.4. One-Pass Signature Packets (Tag 4)
5.4. 1パスの署名パケット(タグ4)
The One-Pass Signature packet precedes the signed data and contains enough information to allow the receiver to begin calculating any hashes needed to verify the signature. It allows the Signature packet to be placed at the end of the message, so that the signer can compute the entire signed message in one pass.
One-パスSignatureパケットは、署名しているデータに先行して、受信機が、どんなハッシュも、署名について確かめる必要だったと見込み始めるのを許容できるくらいの情報を含んでいます。 それは、Signatureパケットがメッセージの終わりに置かれるのを許容します、署名者が1個のパスで全体の署名しているメッセージを計算できるように。
A One-Pass Signature does not interoperate with PGP 2.6.x or earlier.
A One-パスSignatureはPGP 2.6.x以前で共同利用しません。
Callas, et al Standards Track [Page 39] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[39ページ]RFC4880OpenPGP Message Format2007年11月
The body of this packet consists of:
このパケットのボディーは以下から成ります。
- A one-octet version number. The current version is 3.
- 1八重奏のバージョン番号。 最新版は3です。
- A one-octet signature type. Signature types are described in
Section 5.2.1.
- 1八重奏の署名タイプ。 署名タイプはセクション5.2.1で説明されます。
- A one-octet number describing the hash algorithm used.
- 使用されるハッシュアルゴリズムを説明する1八重奏の数。
- A one-octet number describing the public-key algorithm used.
- 使用される公開鍵アルゴリズムを説明する1八重奏の数。
- An eight-octet number holding the Key ID of the signing key.
- 署名キーのKey IDを保持する8八重奏の数。
- A one-octet number holding a flag showing whether the signature
is nested. A zero value indicates that the next packet is
another One-Pass Signature packet that describes another
signature to be applied to the same message data.
- 署名が入れ子にされるか否かに関係なく、旗の表示を保持する1八重奏の数。 ゼロは、次のパケットが同じメッセージデータに適用されるために別の署名について説明する別のOne-パスSignatureパケットであることを示すのを評価します。
Note that if a message contains more than one one-pass signature, then the Signature packets bracket the message; that is, the first Signature packet after the message corresponds to the last one-pass packet and the final Signature packet corresponds to the first one-pass packet.
メッセージが1つ以上の1パスの署名を含んでいるならSignatureパケットがメッセージに腕木を付けることに注意してください。 メッセージが最後の1パスのパケットと最終的なSignatureパケットに対応した後にすなわち、最初のSignatureパケットは最初の1パスのパケットに対応しています。
5.5. Key Material Packet
5.5. キー材料パケット
A key material packet contains all the information about a public or private key. There are four variants of this packet type, and two major versions. Consequently, this section is complex.
キー材料パケットは公衆か秘密鍵のすべての情報を含んでいます。 このパケットタイプの4つの異形、および2つの主要なバージョンがあります。 その結果、このセクションは複雑です。
5.5.1. Key Packet Variants
5.5.1. 主要なパケット異形
5.5.1.1. Public-Key Packet (Tag 6)
5.5.1.1. 公開鍵パケット(タグ6)
A Public-Key packet starts a series of packets that forms an OpenPGP key (sometimes called an OpenPGP certificate).
Public主要なパケットはOpenPGPキー(時々OpenPGP証明書と呼ばれる)を形成する一連のパケットを始めます。
5.5.1.2. Public-Subkey Packet (Tag 14)
5.5.1.2. 公共のサブキーパケット(タグ14)
A Public-Subkey packet (tag 14) has exactly the same format as a Public-Key packet, but denotes a subkey. One or more subkeys may be associated with a top-level key. By convention, the top-level key provides signature services, and the subkeys provide encryption services.
Public-サブキーパケット(タグ14)は、まさにPublic主要なパケットと同じ形式を持っていますが、サブキーを指示します。 1個以上のサブキーがトップレベルキーに関連しているかもしれません。 コンベンションで、トップレベルキーは署名サービスを提供します、そして、サブキーは暗号化サービスを提供します。
Note: in PGP 2.6.x, tag 14 was intended to indicate a comment packet. This tag was selected for reuse because no previous version of PGP ever emitted comment packets but they did properly ignore
以下に注意してください。 PGP 2.6.xでは、タグ14がコメントパケットを示すことを意図しました。 PGPのどんな旧バージョンも今までにパケットにもかかわらず、彼らが適切に無視したコメントを放たなかったので、このタグは再利用のために選択されました。
Callas, et al Standards Track [Page 40] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[40ページ]RFC4880OpenPGP Message Format2007年11月
them. Public-Subkey packets are ignored by PGP 2.6.x and do not cause it to fail, providing a limited degree of backward compatibility.
それら。 公共のサブキーパケットは、PGP 2.6.xによって無視されて、失敗されません、限られた度合いの後方の互換性を提供して。
5.5.1.3. Secret-Key Packet (Tag 5)
5.5.1.3. 秘密鍵パケット(タグ5)
A Secret-Key packet contains all the information that is found in a Public-Key packet, including the public-key material, but also includes the secret-key material after all the public-key fields.
Secret主要なパケットは、公開鍵の材料を含むPublic主要なパケットで見つけられるすべての情報を含んでいますが、すべての公開鍵分野の後に秘密鍵の材料をまた含んでいます。
5.5.1.4. Secret-Subkey Packet (Tag 7)
5.5.1.4. 秘密のサブキーパケット(タグ7)
A Secret-Subkey packet (tag 7) is the subkey analog of the Secret Key packet and has exactly the same format.
Secret-サブキーパケット(タグ7)は、Secret Keyパケットのサブキーアナログであり、まさに同じ形式を持っています。
5.5.2. Public-Key Packet Formats
5.5.2. 公開鍵パケット・フォーマット
There are two versions of key-material packets. Version 3 packets were first generated by PGP 2.6. Version 4 keys first appeared in PGP 5.0 and are the preferred key version for OpenPGP.
主要な材料パケットの2つのバージョンがあります。 バージョン3パケットは最初に、PGP2.6によって生成されました。 バージョン4キーは、最初に、PGP5.0に現れて、都合のよいOpenPGPに、主要なバージョンです。
OpenPGP implementations MUST create keys with version 4 format. V3 keys are deprecated; an implementation MUST NOT generate a V3 key, but MAY accept it.
OpenPGP実装はバージョン4形式でキーを作成しなければなりません。 V3キーは推奨しないです。 実装は、V3キーを生成してはいけませんが、それを受け入れるかもしれません。
A version 3 public key or public-subkey packet contains:
バージョン3公開鍵か公共のサブキーパケットは以下を含んでいます。
- A one-octet version number (3).
- 1八重奏のバージョン番号(3)。
- A four-octet number denoting the time that the key was created.
- キーが作成された時間を指示する4八重奏の数。
- A two-octet number denoting the time in days that this key is
valid. If this number is zero, then it does not expire.
- 何日もの時にこのキーが有効であることを指示する2八重奏の数。 この数がゼロであるなら、それは期限が切れません。
- A one-octet number denoting the public-key algorithm of this key.
- このキーの公開鍵アルゴリズムを指示する1八重奏の数。
- A series of multiprecision integers comprising the key material:
- 主要な材料を含む一連の多倍精度整数:
- a multiprecision integer (MPI) of RSA public modulus n;
- RSAの公共の係数nの多倍精度整数(MPI)。
- an MPI of RSA public encryption exponent e.
- RSAの公共の暗号化解説者eのMPI。
V3 keys are deprecated. They contain three weaknesses. First, it is relatively easy to construct a V3 key that has the same Key ID as any other key because the Key ID is simply the low 64 bits of the public modulus. Secondly, because the fingerprint of a V3 key hashes the key material, but not its length, there is an increased opportunity for fingerprint collisions. Third, there are weaknesses in the MD5
V3キーは推奨しないです。 それらは3つの弱点を含んでいます。 まず最初に、Key IDが単に公共の係数の低64ビットであるのでいかなる他のキーとも同じKey IDを持っているV3キーを組み立てるのは比較的簡単です。 第二に、V3キーの指紋が長さではなく、主要な材料を論じ尽くすので、指紋衝突の増強された機会があります。 3番目に、弱点がMD5にあります。
Callas, et al Standards Track [Page 41] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[41ページ]RFC4880OpenPGP Message Format2007年11月
hash algorithm that make developers prefer other algorithms. See below for a fuller discussion of Key IDs and fingerprints.
開発者が他のアルゴリズムを好むアルゴリズムを論じ尽くしてください。Key IDと指紋の、よりふくよかな議論に関して以下を見てください。
V2 keys are identical to the deprecated V3 keys except for the version number. An implementation MUST NOT generate them and MAY accept or reject them as it sees fit.
V2キーはバージョン番号以外の推奨しないV3キーと同じです。 実装は、適していると決めるようにそれらをそれらを生成してはいけなくて、受け入れるか、または拒絶するかもしれません。
The version 4 format is similar to the version 3 format except for the absence of a validity period. This has been moved to the Signature packet. In addition, fingerprints of version 4 keys are calculated differently from version 3 keys, as described in the section "Enhanced Key Formats".
バージョン4形式は有効期間の不在以外のバージョン3形式と同様です。 これはSignatureパケットに動かされました。 さらに、バージョン4キーの指紋はバージョン3キーと異なって計算されます、「主要な形式を高める」というセクションで説明されるように。
A version 4 packet contains:
バージョン4パケットは以下を含んでいます。
- A one-octet version number (4).
- 1八重奏のバージョン番号(4)。
- A four-octet number denoting the time that the key was created.
- キーが作成された時間を指示する4八重奏の数。
- A one-octet number denoting the public-key algorithm of this key.
- このキーの公開鍵アルゴリズムを指示する1八重奏の数。
- A series of multiprecision integers comprising the key material.
This algorithm-specific portion is:
- 主要な材料を含む一連の多倍精度整数。 このアルゴリズム特定部位は以下の通りです。
Algorithm-Specific Fields for RSA public keys:
RSA公開鍵のためのアルゴリズム特有のフィールズ:
- multiprecision integer (MPI) of RSA public modulus n;
- RSAの公共の係数nの多倍精度整数(MPI)。
- MPI of RSA public encryption exponent e.
- RSAの公共の暗号化解説者eのMPI。
Algorithm-Specific Fields for DSA public keys:
DSA公開鍵のためのアルゴリズム特有のフィールズ:
- MPI of DSA prime p;
- DSA第1pのMPI。
- MPI of DSA group order q (q is a prime divisor of p-1);
- DSA共同注文q(qはp-1の主要な除数です)のMPI。
- MPI of DSA group generator g;
- DSAグループジェネレータgのMPI。
- MPI of DSA public-key value y (= g**x mod p where x
is secret).
- DSA公開鍵価値y(xが秘密であるg**xモッズpと等しいです)のMPI。
Algorithm-Specific Fields for Elgamal public keys:
Elgamal公開鍵のためのアルゴリズム特有のフィールズ:
- MPI of Elgamal prime p;
- Elgamal第1pのMPI。
- MPI of Elgamal group generator g;
- ElgamalグループジェネレータgのMPI。
Callas, et al Standards Track [Page 42] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[42ページ]RFC4880OpenPGP Message Format2007年11月
- MPI of Elgamal public key value y (= g**x mod p where x
is secret).
- Elgamal公開鍵価値y(xが秘密であるg**xモッズpと等しいです)のMPI。
5.5.3. Secret-Key Packet Formats
5.5.3. 秘密鍵パケット・フォーマット
The Secret-Key and Secret-Subkey packets contain all the data of the Public-Key and Public-Subkey packets, with additional algorithm- specific secret-key data appended, usually in encrypted form.
Secret-キーとSecret-サブキーパケットはPublic-キーとPublic-サブキーパケットに関するすべてのデータを含んでいます、追加アルゴリズム特定の秘密鍵データを追加していて、通常暗号化されたフォームで。
The packet contains:
パケットは以下を含んでいます。
- A Public-Key or Public-Subkey packet, as described above.
- 上で説明されるとしてのPublic-キーかPublic-サブキーパケット。
- One octet indicating string-to-key usage conventions. Zero
indicates that the secret-key data is not encrypted. 255 or 254
indicates that a string-to-key specifier is being given. Any
other value is a symmetric-key encryption algorithm identifier.
- ストリングから重要への用法コンベンションを示す1つの八重奏。 ゼロは、秘密鍵データが暗号化されていないのを示します。 255か254が、ストリングからキーへの特許説明書の作成書が与えられているのを示します。 いかなる他の値も共通鍵暗号アルゴリズム識別子です。
- [Optional] If string-to-key usage octet was 255 or 254, a one-
octet symmetric encryption algorithm.
- [任意の] ストリングからキーへの用法であるなら、八重奏は、255か254であり、1つの八重奏が左右対称の暗号化アルゴリズムです。
- [Optional] If string-to-key usage octet was 255 or 254, a
string-to-key specifier. The length of the string-to-key
specifier is implied by its type, as described above.
- [任意の] ストリングからキーへの用法八重奏が255かストリングからキーへの254、特許説明書の作成書であったなら。 ストリングからキーへの特許説明書の作成書の長さは上で説明されるようにタイプによって暗示されます。
- [Optional] If secret data is encrypted (string-to-key usage octet
not zero), an Initial Vector (IV) of the same length as the
cipher's block size.
- [任意の] 暗号化された機密データ(ゼロではなく、ストリングからキーへの用法八重奏)、暗号のブロック・サイズと同じ長さのInitial Vector(IV)であるなら。
- Plain or encrypted multiprecision integers comprising the secret
key data. These algorithm-specific fields are as described
below.
- 秘密鍵データを包括する明瞭であるか暗号化された多倍精度整数。 以下で説明されるとしてこれらのアルゴリズム特有の分野があります。
- If the string-to-key usage octet is zero or 255, then a two-octet
checksum of the plaintext of the algorithm-specific portion (sum
of all octets, mod 65536). If the string-to-key usage octet was
254, then a 20-octet SHA-1 hash of the plaintext of the
algorithm-specific portion. This checksum or hash is encrypted
together with the algorithm-specific fields (if string-to-key
usage octet is not zero). Note that for all other values, a
two-octet checksum is required.
- ストリングからキーへの用法八重奏がゼロか255であるなら、そして、アルゴリズム特定部位(すべての八重奏の合計、モッズ風の65536)の平文の2八重奏のチェックサムです。 ストリングからキーへの用法八重奏が254であったなら、そして、アルゴリズム特定部位の平文の20八重奏のSHA-1ハッシュです。 このチェックサムかハッシュがアルゴリズム特有の分野と共に暗号化されます(ストリングからキーへの用法八重奏がゼロでないなら)。 他のすべての値に、2八重奏のチェックサムが必要であることに注意してください。
Algorithm-Specific Fields for RSA secret keys:
RSA秘密鍵のためのアルゴリズム特有のフィールズ:
- multiprecision integer (MPI) of RSA secret exponent d.
- RSAの秘密の解説者dの多倍精度整数(MPI)。
- MPI of RSA secret prime value p.
- RSAの秘密の主要な価値pのMPI。
Callas, et al Standards Track [Page 43] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[43ページ]RFC4880OpenPGP Message Format2007年11月
- MPI of RSA secret prime value q (p < q).
- RSAの秘密の主要な価値q(p<q)のMPI。
- MPI of u, the multiplicative inverse of p, mod q.
- uのMPI、pの乗法的な逆、モッズq。
Algorithm-Specific Fields for DSA secret keys:
DSA秘密鍵のためのアルゴリズム特有のフィールズ:
- MPI of DSA secret exponent x.
- DSAの秘密の解説者xのMPI。
Algorithm-Specific Fields for Elgamal secret keys:
Elgamal秘密鍵のためのアルゴリズム特有のフィールズ:
- MPI of Elgamal secret exponent x.
- Elgamalの秘密の解説者xのMPI。
Secret MPI values can be encrypted using a passphrase. If a string- to-key specifier is given, that describes the algorithm for converting the passphrase to a key, else a simple MD5 hash of the passphrase is used. Implementations MUST use a string-to-key specifier; the simple hash is for backward compatibility and is deprecated, though implementations MAY continue to use existing private keys in the old format. The cipher for encrypting the MPIs is specified in the Secret-Key packet.
パスフレーズを使用することで秘密のMPI値を暗号化できます。 キーへのストリング特許説明書の作成書を与えるなら、それはパスフレーズをキーに変換するためのアルゴリズムを説明して、ほかに、パスフレーズの簡単なMD5ハッシュは使用されています。 実装はストリングからキーへの特許説明書の作成書を使用しなければなりません。 簡単なハッシュは、後方の互換性のためにあって、推奨しないです、実装は、古い方式に既存の秘密鍵を使用し続けるかもしれませんが。 MPIsを暗号化するための暗号はSecret主要なパケットで指定されます。
Encryption/decryption of the secret data is done in CFB mode using the key created from the passphrase and the Initial Vector from the packet. A different mode is used with V3 keys (which are only RSA) than with other key formats. With V3 keys, the MPI bit count prefix (i.e., the first two octets) is not encrypted. Only the MPI non- prefix data is encrypted. Furthermore, the CFB state is resynchronized at the beginning of each new MPI value, so that the CFB block boundary is aligned with the start of the MPI data.
パスフレーズとInitial Vectorからパケットから作成されたキーを使用しながら、CFBモードで機密データの暗号化/復号化をします。 他の主要な形式と異なったモードはV3キー(RSAにすぎない)と共に使用されます。 V3キーで、MPIビットカウント接頭語(すなわち、最初の2つの八重奏)は暗号化されていません。 MPIの非接頭語のデータだけが暗号化されています。 その上、CFB状態はそれぞれの新しいMPI価値の始めに再連動します、CFBブロック境界がMPIデータの始まりに並べられるように。
With V4 keys, a simpler method is used. All secret MPI values are encrypted in CFB mode, including the MPI bitcount prefix.
V4キーで、より簡単なメソッドは使用されています。 すべての秘密のMPI値がMPI bitcount接頭語を含むCFBモードで暗号化されます。
The two-octet checksum that follows the algorithm-specific portion is the algebraic sum, mod 65536, of the plaintext of all the algorithm- specific octets (including MPI prefix and data). With V3 keys, the checksum is stored in the clear. With V4 keys, the checksum is encrypted like the algorithm-specific data. This value is used to check that the passphrase was correct. However, this checksum is deprecated; an implementation SHOULD NOT use it, but should rather use the SHA-1 hash denoted with a usage octet of 254. The reason for this is that there are some attacks that involve undetectably modifying the secret key.
アルゴリズム特定部位に続く2八重奏のチェックサムは代数和、すべてのアルゴリズムの特定の八重奏の65536のモッズ風の平文(MPI接頭語とデータを含んでいて)です。 V3キーで、チェックサムは明確に保存されます。 V4キーで、チェックサムはアルゴリズム特有のデータのように暗号化されます。 この値は、パスフレーズが正しかったのをチェックするのに使用されます。 しかしながら、このチェックサムは推奨しないです。 実装SHOULD NOTはそれを使用しますが、むしろ254の用法八重奏で指示されたSHA-1ハッシュを使用するはずです。 この理由はundetectablyに秘密鍵を変更することを伴ういくつかの攻撃があるということです。
Callas, et al Standards Track [Page 44] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[44ページ]RFC4880OpenPGP Message Format2007年11月
5.6. Compressed Data Packet (Tag 8)
5.6. 圧縮されたデータ・パケット(タグ8)
The Compressed Data packet contains compressed data. Typically, this packet is found as the contents of an encrypted packet, or following a Signature or One-Pass Signature packet, and contains a literal data packet.
Compressed Dataパケットは圧縮されたデータを含んでいます。 このパケットは、通常、暗号化されたパケットのコンテンツとして見つけられるか、またはSignatureかOne-パスSignatureパケットに続いていて、文字通りのデータ・パケットを含んでいます。
The body of this packet consists of:
このパケットのボディーは以下から成ります。
- One octet that gives the algorithm used to compress the packet.
- アルゴリズムを与える1つの八重奏が以前はよくパケットを圧縮していました。
- Compressed data, which makes up the remainder of the packet.
- 圧縮されたデータ。(そのデータはパケットの残りを補います)。
A Compressed Data Packet's body contains an block that compresses some set of packets. See section "Packet Composition" for details on how messages are formed.
Compressed Data Packetのボディーは何らかのセットのパケットを圧縮するブロックを含みます。 メッセージがどう形成されるかに関する詳細のための「パケット構成」というセクションを見てください。
ZIP-compressed packets are compressed with raw RFC 1951 [RFC1951] DEFLATE blocks. Note that PGP V2.6 uses 13 bits of compression. If an implementation uses more bits of compression, PGP V2.6 cannot decompress it.
ZIPによって圧縮されたパケットは生のRFC1951[RFC1951]DEFLATEブロックで圧縮されます。 PGP V2.6が圧縮の13ビットを使用することに注意してください。 実装が圧縮の、より多くのビットを使用するなら、PGP V2.6はそれを減圧できません。
ZLIB-compressed packets are compressed with RFC 1950 [RFC1950] ZLIB- style blocks.
ZLIBによって圧縮されたパケットはRFCと共に1950[RFC1950]ZLIBスタイルブロック圧縮されます。
BZip2-compressed packets are compressed using the BZip2 [BZ2] algorithm.
BZip2によって圧縮されたパケットは、BZip2[BZ2]アルゴリズムを使用することで圧縮されます。
5.7. Symmetrically Encrypted Data Packet (Tag 9)
5.7. 対称的に暗号化されたデータ・パケット(タグ9)
The Symmetrically Encrypted Data packet contains data encrypted with a symmetric-key algorithm. When it has been decrypted, it contains other packets (usually a literal data packet or compressed data packet, but in theory other Symmetrically Encrypted Data packets or sequences of packets that form whole OpenPGP messages).
Symmetrically Encrypted Dataパケットは対称鍵アルゴリズムで暗号化されたデータを含んでいます。 解読されたとき、それは他のパケット(全体のOpenPGPメッセージを形成するパケットの通常文字通りのデータ・パケット、圧縮されたデータ・パケットの、しかし、理論上他のSymmetrically Encrypted Dataパケットまたは系列)を含んでいます。
The body of this packet consists of:
このパケットのボディーは以下から成ります。
- Encrypted data, the output of the selected symmetric-key cipher
operating in OpenPGP's variant of Cipher Feedback (CFB) mode.
- 暗号化されたデータ、OpenPGPのCipher Feedback(CFB)モードの異形での選択された対称鍵暗号作動の出力。
The symmetric cipher used may be specified in a Public-Key or Symmetric-Key Encrypted Session Key packet that precedes the Symmetrically Encrypted Data packet. In that case, the cipher algorithm octet is prefixed to the session key before it is encrypted. If no packets of these types precede the encrypted data, the IDEA algorithm is used with the session key calculated as the MD5 hash of the passphrase, though this use is deprecated.
使用される左右対称の暗号はSymmetrically Encrypted Dataパケットに先行するPublic主要であるかSymmetric主要なEncrypted Session Keyパケットで指定されるかもしれません。 その場合、それが暗号化されている前に暗号アルゴリズム八重奏はセッションキーへ前に置かれています。 これらのタイプのどんなパケットも暗号化されたデータに先行しないなら、IDEAアルゴリズムはパスフレーズのMD5ハッシュとして計算されるセッションキーと共に使用されます、この使用が推奨しないのですが。
Callas, et al Standards Track [Page 45] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[45ページ]RFC4880OpenPGP Message Format2007年11月
The data is encrypted in CFB mode, with a CFB shift size equal to the cipher's block size. The Initial Vector (IV) is specified as all zeros. Instead of using an IV, OpenPGP prefixes a string of length equal to the block size of the cipher plus two to the data before it is encrypted. The first block-size octets (for example, 8 octets for a 64-bit block length) are random, and the following two octets are copies of the last two octets of the IV. For example, in an 8-octet block, octet 9 is a repeat of octet 7, and octet 10 is a repeat of octet 8. In a cipher of length 16, octet 17 is a repeat of octet 15 and octet 18 is a repeat of octet 16. As a pedantic clarification, in both these examples, we consider the first octet to be numbered 1.
データは暗号のブロック・サイズと等しいCFBシフトサイズでCFBモードで暗号化されます。 Initial Vector(IV)はすべてのゼロとして指定されます。 IVを使用することの代わりに、それが暗号化されている前にOpenPGPは暗号と2つのもののブロック・サイズと等しい長さのストリングをデータへ前に置きます。 最初のブロック・サイズ八重奏(例えば、64ビットのブロック長のための8つの八重奏)は無作為です、そして、以下の2つの八重奏はIVの最後の2つの八重奏のコピーです。 例えば、八重奏9は8八重奏のブロックでは、八重奏7の反復です、そして、八重奏10は八重奏8の反復です。 長さ16の暗号では、八重奏17は八重奏15の反復です、そして、八重奏18は八重奏16の反復です。 衒学的な明確化として、これらの例の両方では、私たちは、最初の八重奏が番号付の1であると考えます。
After encrypting the first block-size-plus-two octets, the CFB state is resynchronized. The last block-size octets of ciphertext are passed through the cipher and the block boundary is reset.
最初のブロックサイズと2八重奏を暗号化した後に、CFB状態は再連動します。 暗号文の最後のブロック・サイズ八重奏は暗号を通り抜けます、そして、ブロック境界はリセットされます。
The repetition of 16 bits in the random data prefixed to the message allows the receiver to immediately check whether the session key is incorrect. See the "Security Considerations" section for hints on the proper use of this "quick check".
メッセージへ前に置かれた無作為のデータにおける、16ビットの反復で、受信機は、すぐに、セッションキーが不正確であるかどうかチェックできます。 ヒントに関してこの「迅速なチェック」の適切な使用に「セキュリティ問題」セクションを見てください。
5.8. Marker Packet (Obsolete Literal Packet) (Tag 10)
5.8. マーカーパケット(時代遅れの文字通りのパケット)(タグ10)
An experimental version of PGP used this packet as the Literal packet, but no released version of PGP generated Literal packets with this tag. With PGP 5.x, this packet has been reassigned and is reserved for use as the Marker packet.
Literalパケットが生成しますが、PGPのどんなリリースされたバージョンもこのタグでLiteralにパケットを生成しなかったとき、PGPの実験バージョンはこのパケットを使用しました。 このパケットは、PGP 5.xと共に、再選任されて、使用のためにMarkerパケットとして予約されます。
The body of this packet consists of:
このパケットのボディーは以下から成ります。
- The three octets 0x50, 0x47, 0x50 (which spell "PGP" in UTF-8).
- 3つの八重奏0×50、0×47、0x50(UTF-8のどのスペル"PGP")。
Such a packet MUST be ignored when received. It may be placed at the beginning of a message that uses features not available in PGP 2.6.x in order to cause that version to report that newer software is necessary to process the message.
受け取ると、そのようなパケットを無視しなければなりません。 それはそのバージョンが、より新しいソフトウェアがメッセージを処理するのに必要であると報告することを引き起こすのにPGP 2.6.xで利用可能でない特徴を使用するメッセージの始めに置かれるかもしれません。
5.9. Literal Data Packet (Tag 11)
5.9. 文字通りのデータ・パケット(タグ11)
A Literal Data packet contains the body of a message; data that is not to be further interpreted.
Literal Dataパケットはメッセージのボディーを含んでいます。 さらに解釈してはいけないデータ。
The body of this packet consists of:
このパケットのボディーは以下から成ります。
- A one-octet field that describes how the data is formatted.
- データがどうフォーマットされるかを説明する1八重奏の分野。
Callas, et al Standards Track [Page 46] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[46ページ]RFC4880OpenPGP Message Format2007年11月
If it is a 'b' (0x62), then the Literal packet contains binary data. If it is a 't' (0x74), then it contains text data, and thus may need line ends converted to local form, or other text-mode changes. The tag 'u' (0x75) means the same as 't', but also indicates that implementation believes that the literal data contains UTF-8 text.
それが'b'(0×62)であるなら、Literalパケットはバイナリ・データを含んでいます。 ''(0×74)でないなら、それは、テキストデータを含んでいて、その結果、地方で変えられる列の最後尾のフォーム、または他のテキストモード変化を必要とするかもしれません。 'タグ'u'(0×75)が同じであることを意味する、'も実装が、文字通りのデータがUTF-8テキストを含むと信じているのを示します。
Early versions of PGP also defined a value of 'l' as a 'local' mode for machine-local conversions. RFC 1991 [RFC1991] incorrectly stated this local mode flag as '1' (ASCII numeral one). Both of these local modes are deprecated.
また、PGPの早めのバージョンはマシン地方の変換のための'地方'のモードと'l'の値を定義しました。 RFC1991[RFC1991]は'1'(ASCIIの数字のもの)として不当にこのローカルのモード旗を述べました。 これらのローカルのモードの両方が推奨しないです。
- File name as a string (one-octet length, followed by a file
name). This may be a zero-length string. Commonly, if the
source of the encrypted data is a file, this will be the name of
the encrypted file. An implementation MAY consider the file name
in the Literal packet to be a more authoritative name than the
actual file name.
- ストリング(ファイル名があとに続いた1八重奏の長さ)として名前をファイルしてください。 これはゼロ長ストリングであるかもしれません。 一般的に、暗号化されたデータの源がファイルであるなら、これは暗号化されたファイルの名前になるでしょう。 実装は、Literalパケットのファイル名が実際のファイル名より正式の名前であると考えるかもしれません。
If the special name "_CONSOLE" is used, the message is considered to be "for your eyes only". This advises that the message data is unusually sensitive, and the receiving program should process it more carefully, perhaps avoiding storing the received data to disk, for example.
「」 コンソールという特別な名前_です」、使用されていて、メッセージが「あなたの目専用」のためにあると考えられます。 これは、メッセージデータが異常に機密であり、受信プログラムが、より慎重にそれを処理するはずであると忠告します、恐らく例えば、ディスクとして受信データを保存するのを避けて
- A four-octet number that indicates a date associated with the
literal data. Commonly, the date might be the modification date
of a file, or the time the packet was created, or a zero that
indicates no specific time.
- 文字通りのデータに関連している期日を示す4八重奏の数。 一般的に、日付は、ファイルの変更日付、パケットが作成された時、またはどんな特定の時間も示さないゼロであるかもしれません。
- The remainder of the packet is literal data.
- パケットの残りは文字通りのデータです。
Text data is stored with <CR><LF> text endings (i.e., network-
normal line endings). These should be converted to native line
endings by the receiving software.
テキストデータは<CR><LF>テキスト結末(すなわち、ネットワーク正常な系列結末)で保存されます。 これらは受信ソフトウェアによって自然な系列結末に変換されるべきです。
5.10. Trust Packet (Tag 12)
5.10. 信頼パケット(タグ12)
The Trust packet is used only within keyrings and is not normally exported. Trust packets contain data that record the user's specifications of which key holders are trustworthy introducers, along with other information that implementing software uses for trust information. The format of Trust packets is defined by a given implementation.
Trustパケットは、keyringsだけの中で使用されて、通常、エクスポートされません。 信頼パケットはユーザのそれの主要な所有者の仕様が信頼できる誘導子であるそんなに記録的なデータを含んでいます、ソフトウェアを実装すると情報が信頼に使用されるという他の情報と共に。 Trustパケットの書式は与えられた実装によって定義されます。
Trust packets SHOULD NOT be emitted to output streams that are transferred to other users, and they SHOULD be ignored on any input other than local keyring files.
パケットSHOULD NOTが他のユーザに移される出力ストリームに放たれていると信じてください、彼ら、SHOULD、ローカルのkeyringファイル以外のあらゆる入力のときに、無視されてください。
Callas, et al Standards Track [Page 47] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[47ページ]RFC4880OpenPGP Message Format2007年11月
5.11. User ID Packet (Tag 13)
5.11. ユーザIDパケット(タグ13)
A User ID packet consists of UTF-8 text that is intended to represent the name and email address of the key holder. By convention, it includes an RFC 2822 [RFC2822] mail name-addr, but there are no restrictions on its content. The packet length in the header specifies the length of the User ID.
User IDパケットは主要な所有者の名前とEメールアドレスを表すことを意図するUTF-8テキストから成ります。 コンベンションで、RFC2822[RFC2822]メール名前-addrを含んでいますが、制限が全く内容にありません。 ヘッダーのパケット長はUser IDの長さを指定します。
5.12. User Attribute Packet (Tag 17)
5.12. ユーザ属性パケット(タグ17)
The User Attribute packet is a variation of the User ID packet. It
is capable of storing more types of data than the User ID packet,
which is limited to text. Like the User ID packet, a User Attribute
packet may be certified by the key owner ("self-signed") or any other
key owner who cares to certify it. Except as noted, a User Attribute
packet may be used anywhere that a User ID packet may be used.
User AttributeパケットはUser IDパケットの変化です。 それはUser IDパケットよりデータのタイプを保存できます。(パケットはテキストに制限されます)。 User IDパケットのように、User Attributeパケットは主要な所有者(「自己に署名される」)かそれを公認するのを気にかけるいかなる他の主要な所有者によっても公認されるかもしれません。 注意されるのを除いて、User Attributeパケットはどこでもそのa User IDパケットが使用されるかもしれない使用されるかもしれません。
While User Attribute packets are not a required part of the OpenPGP standard, implementations SHOULD provide at least enough compatibility to properly handle a certification signature on the User Attribute packet. A simple way to do this is by treating the User Attribute packet as a User ID packet with opaque contents, but an implementation may use any method desired.
User AttributeパケットはOpenPGP規格の必要な部分ではありませんが、実装SHOULDは、User Attributeパケットの上で適切に証明署名を扱うために十分少なくとも互換性を提供します。 これをする簡単な方法は不透明なコンテンツがあるUser IDパケットとしてUser Attributeパケットを扱うことですが、実装は望まれていたどんなメソッドも使用するかもしれません。
The User Attribute packet is made up of one or more attribute subpackets. Each subpacket consists of a subpacket header and a body. The header consists of:
User Attributeパケットは1つ以上の属性「副-パケット」で作られます。 各「副-パケット」は「副-パケット」ヘッダーとボディーから成ります。 ヘッダーは以下から成ります。
- the subpacket length (1, 2, or 5 octets)
- 「副-パケット」の長さ(1、2、または5つの八重奏)
- the subpacket type (1 octet)
- 「副-パケット」タイプ(1つの八重奏)
and is followed by the subpacket specific data.
そして、「副-パケット」の特定のデータはあとに続いています。
The only currently defined subpacket type is 1, signifying an image. An implementation SHOULD ignore any subpacket of a type that it does not recognize. Subpacket types 100 through 110 are reserved for private or experimental use.
唯一の現在定義された「副-パケット」タイプが1歳であり、意味はイメージです。 実装SHOULDはそれが見分けないタイプのどんな「副-パケット」も無視します。 Subpacketタイプ100〜110は個人的であるか実験的な使用のために予約されます。
5.12.1. The Image Attribute Subpacket
5.12.1. イメージ属性Subpacket
The Image Attribute subpacket is used to encode an image, presumably (but not required to be) that of the key owner.
Image Attribute subpacketはおそらく、イメージをコード化するのにおいて中古、そして、(必要でない。)です。主要な所有者のもの。
The Image Attribute subpacket begins with an image header. The first two octets of the image header contain the length of the image header. Note that unlike other multi-octet numerical values in this document, due to a historical accident this value is encoded as a
Image Attribute subpacketはイメージヘッダーと共に始まります。 イメージヘッダーの最初の2つの八重奏がイメージヘッダーの長さを含んでいます。 歴史的な事故のため、このドキュメントの他のマルチ八重奏数値と異なって、この値がaとしてコード化されることに注意してください。
Callas, et al Standards Track [Page 48] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[48ページ]RFC4880OpenPGP Message Format2007年11月
little-endian number. The image header length is followed by a single octet for the image header version. The only currently defined version of the image header is 1, which is a 16-octet image header. The first three octets of a version 1 image header are thus 0x10, 0x00, 0x01.
リトルエンディアン番号。 イメージヘッダーバージョンのためのただ一つの八重奏はイメージヘッダ長のあとに続いています。 イメージヘッダーの唯一の現在定義されたバージョンが1です。(その1は16八重奏のイメージヘッダーです)。 その結果、バージョン1イメージヘッダーの最初の3つの八重奏が0×10、0×00、0×01です。
The fourth octet of a version 1 image header designates the encoding format of the image. The only currently defined encoding format is the value 1 to indicate JPEG. Image format types 100 through 110 are reserved for private or experimental use. The rest of the version 1 image header is made up of 12 reserved octets, all of which MUST be set to 0.
バージョン1イメージヘッダーの4番目の八重奏はイメージのコード化形式を指定します。 現在形式をコード化しながら定義されているだけであるのは、値1です。JPEGを示すために。 画像形式タイプ100〜110は個人的であるか実験的な使用のために予約されます。 バージョン1イメージヘッダーの残りは12の予約された八重奏で補われます。そのすべてを0に設定しなければなりません。
The rest of the image subpacket contains the image itself. As the only currently defined image type is JPEG, the image is encoded in the JPEG File Interchange Format (JFIF), a standard file format for JPEG images [JFIF].
イメージ「副-パケット」の残りはイメージ自体を含んでいます。 唯一の現在定義されたイメージタイプがJPEGであるので、イメージはJPEG File Interchange Format(JFIF)(JPEGイメージ[JFIF]のための標準ファイル形式)でコード化されます。
An implementation MAY try to determine the type of an image by examination of the image data if it is unable to handle a particular version of the image header or if a specified encoding format value is not recognized.
イメージヘッダーの特定のバージョンを扱うことができないか、または指定されたコード化形式値が認識されないなら、実装はイメージデータの調査でイメージのタイプを決定しようとするかもしれません。
5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18)
5.13. Sym。 暗号化された保全はデータ・パケットを保護しました。(タグ18)
The Symmetrically Encrypted Integrity Protected Data packet is a variant of the Symmetrically Encrypted Data packet. It is a new feature created for OpenPGP that addresses the problem of detecting a modification to encrypted data. It is used in combination with a Modification Detection Code packet.
Symmetrically Encrypted Integrity Protected DataパケットはSymmetrically Encrypted Dataパケットの異形です。 暗号化されたデータへの変更を検出するというその問題を訴えるのは、OpenPGPのために作成された新機能です。 それはModification Detection Codeパケットと組み合わせて使用されます。
There is a corresponding feature in the features Signature subpacket that denotes that an implementation can properly use this packet type. An implementation MUST support decrypting these packets and SHOULD prefer generating them to the older Symmetrically Encrypted Data packet when possible. Since this data packet protects against modification attacks, this standard encourages its proliferation. While blanket adoption of this data packet would create interoperability problems, rapid adoption is nevertheless important. An implementation SHOULD specifically denote support for this packet, but it MAY infer it from other mechanisms.
対応する特徴が実装が適切にこのパケットタイプを使用できるのを指示する特徴Signature subpacketにあります。 実装は、解読するのがこれらのパケットであるとサポートしなければなりません、そして、SHOULDは可能であるときに、より古いSymmetrically Encrypted Dataパケットにそれらを生成するのを好みます。 このデータ・パケットが変更攻撃から守るので、この規格は増殖を奨励します。 このデータ・パケットの毛布採用は相互運用性問題を生じさせるでしょうが、それにもかかわらず、急速な採用は重要です。 実装SHOULDは明確にこのパケットのサポートを指示しますが、それは他のメカニズムからそれを推論するかもしれません。
For example, an implementation might infer from the use of a cipher such as Advanced Encryption Standard (AES) or Twofish that a user supports this feature. It might place in the unhashed portion of another user's key signature a Features subpacket. It might also present a user with an opportunity to regenerate their own self- signature with a Features subpacket.
例えば、実装は、エー・イー・エス(AES)かTwofishなどの暗号の使用からユーザがこの特徴をサポートすると推論するかもしれません。 それは別のユーザの調号の「非-論じ尽く」された部分にFeatures subpacketを置くかもしれません。 また、それはFeatures subpacketとのそれら自身の自己署名を作り直す機会をユーザに与えるかもしれません。
Callas, et al Standards Track [Page 49] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[49ページ]RFC4880OpenPGP Message Format2007年11月
This packet contains data encrypted with a symmetric-key algorithm and protected against modification by the SHA-1 hash algorithm. When it has been decrypted, it will typically contain other packets (often a Literal Data packet or Compressed Data packet). The last decrypted packet in this packet's payload MUST be a Modification Detection Code packet.
このパケットは、対称鍵アルゴリズムで暗号化されたデータを含んで、SHA-1ハッシュアルゴリズムで変更から守りました。 解読されたとき、それは他のパケット(しばしばLiteral DataパケットかCompressed Dataパケット)を通常含むでしょう。 このパケットのペイロードの最後に解読されたパケットはModification Detection Codeパケットであるに違いありません。
The body of this packet consists of:
このパケットのボディーは以下から成ります。
- A one-octet version number. The only currently defined value is
1.
- 1八重奏のバージョン番号。 唯一の現在定義された値が1です。
- Encrypted data, the output of the selected symmetric-key cipher
operating in Cipher Feedback mode with shift amount equal to the
block size of the cipher (CFB-n where n is the block size).
- 暗号化されたデータ(暗号(nがブロック・サイズであるCFB-n)のブロック・サイズと等しいシフト量でCipher Feedbackモードで作動する選択された対称鍵暗号の出力)。
The symmetric cipher used MUST be specified in a Public-Key or Symmetric-Key Encrypted Session Key packet that precedes the Symmetrically Encrypted Data packet. In either case, the cipher algorithm octet is prefixed to the session key before it is encrypted.
Symmetrically Encrypted Dataパケットに先行するPublic主要であるかSymmetric主要なEncrypted Session Keyパケットで使用される左右対称の暗号を指定しなければなりません。 どちらの場合ではも、それが暗号化されている前に暗号アルゴリズム八重奏はセッションキーへ前に置かれています。
The data is encrypted in CFB mode, with a CFB shift size equal to the cipher's block size. The Initial Vector (IV) is specified as all zeros. Instead of using an IV, OpenPGP prefixes an octet string to the data before it is encrypted. The length of the octet string equals the block size of the cipher in octets, plus two. The first octets in the group, of length equal to the block size of the cipher, are random; the last two octets are each copies of their 2nd preceding octet. For example, with a cipher whose block size is 128 bits or 16 octets, the prefix data will contain 16 random octets, then two more octets, which are copies of the 15th and 16th octets, respectively. Unlike the Symmetrically Encrypted Data Packet, no special CFB resynchronization is done after encrypting this prefix data. See "OpenPGP CFB Mode" below for more details.
データは暗号のブロック・サイズと等しいCFBシフトサイズでCFBモードで暗号化されます。 Initial Vector(IV)はすべてのゼロとして指定されます。 IVを使用することの代わりに、それが暗号化されている前にOpenPGPは八重奏ストリングをデータへ前に置きます。 八重奏ストリングの長さは八重奏、および2における、暗号のブロック・サイズと等しいです。 暗号のブロック・サイズと等しい長さでは、グループにおける最初の八重奏は無作為です。 最後の2つの八重奏はそれぞれが彼らの2番目の前の八重奏をコピーするということです。 例えば、ブロック・サイズが128ビットか16の八重奏である暗号で、接頭語データは16の無作為の八重奏、次にもう2つの八重奏を含むでしょう。(八重奏はそれぞれ15番目と16番目の八重奏のコピーです)。 Symmetrically Encrypted Data Packetと異なって、この接頭語データを暗号化した後に、どんな特別なCFB resynchronizationもしません。 その他の詳細に関して以下の「OpenPGP CFBモード」を見てください。
The repetition of 16 bits in the random data prefixed to the message allows the receiver to immediately check whether the session key is incorrect.
メッセージへ前に置かれた無作為のデータにおける、16ビットの反復で、受信機は、すぐに、セッションキーが不正確であるかどうかチェックできます。
The plaintext of the data to be encrypted is passed through the SHA-1 hash function, and the result of the hash is appended to the plaintext in a Modification Detection Code packet. The input to the hash function includes the prefix data described above; it includes all of the plaintext, and then also includes two octets of values 0xD3, 0x14. These represent the encoding of a Modification Detection Code packet tag and length field of 20 octets.
SHA-1ハッシュ関数を暗号化されるべきデータの平文を通り抜けます、そして、Modification Detection Codeパケットの平文にハッシュの結果を追加します。 ハッシュ関数への入力は上で説明された接頭語データを含んでいます。 それは、平文のすべてを含んでいて、また、次に、値0xD3、0x14の2つの八重奏を含んでいます。 これらは20の八重奏のModification Detection Codeパケットタグと長さの分野のコード化を表します。
Callas, et al Standards Track [Page 50] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[50ページ]RFC4880OpenPGP Message Format2007年11月
The resulting hash value is stored in a Modification Detection Code (MDC) packet, which MUST use the two octet encoding just given to represent its tag and length field. The body of the MDC packet is the 20-octet output of the SHA-1 hash.
結果として起こるハッシュ値はModification Detection Code(MDC)パケットに保存されます。(それは、タグを表すためにただ与えられたコード化と長さがさばく2八重奏を使用しなければなりません)。 MDCパケットのボディーはSHA-1ハッシュの20八重奏の出力です。
The Modification Detection Code packet is appended to the plaintext and encrypted along with the plaintext using the same CFB context.
Modification Detection Codeパケットは、同じCFB文脈を使用することで平文に追加されて、平文と共に暗号化されます。
During decryption, the plaintext data should be hashed with SHA-1, including the prefix data as well as the packet tag and length field of the Modification Detection Code packet. The body of the MDC packet, upon decryption, is compared with the result of the SHA-1 hash.
復号化の間、平文データはSHA-1と共に論じ尽くされるべきです、Modification Detection Codeパケットのパケットタグと長さの分野と同様に接頭語データを含んでいて。 復号化では、MDCパケットのボディーはSHA-1ハッシュの結果と比較されます。
Any failure of the MDC indicates that the message has been modified and MUST be treated as a security problem. Failures include a difference in the hash values, but also the absence of an MDC packet, or an MDC packet in any position other than the end of the plaintext. Any failure SHOULD be reported to the user.
MDCのどんな失敗もメッセージを変更されて、警備上の問題として扱わなければならないのを示します。 失敗はハッシュ値の違い、MDCパケットの不在も、または平文の終わり以外のどんな位置のMDCパケットだけも含んでいます。 どんな失敗SHOULD、もユーザに報告されてください。
Note: future designs of new versions of this packet should consider rollback attacks since it will be possible for an attacker to change the version back to 1.
以下に注意してください。 攻撃者がバージョンの1にもとに戻るのが、可能であるので、このパケットの新しいバージョンの将来のデザインはロールバック攻撃を考えるべきです。
NON-NORMATIVE EXPLANATION
非標準の説明
The MDC system, as packets 18 and 19 are called, were created to
provide an integrity mechanism that is less strong than a
signature, yet stronger than bare CFB encryption.
パケット18と19が呼ばれるようにMDCシステムは署名ほど強くない保全メカニズムを提供するために作成されました、むき出しのCFB暗号化よりまだ強いです。
It is a limitation of CFB encryption that damage to the ciphertext
will corrupt the affected cipher blocks and the block following.
Additionally, if data is removed from the end of a CFB-encrypted
block, that removal is undetectable. (Note also that CBC mode has
a similar limitation, but data removed from the front of the block
is undetectable.)
続いて、それが暗号文に破損するCFB暗号化の制限が影響を受ける暗号ブロックとブロックを崩壊させるということです。 さらに、データがCFBによって暗号化されたブロックの端から取り除かれるなら、その取り外しは検知されないです。 (また、CBCモードには同様の制限がありますが、ブロックの前から取り除かれたデータが検知されないことに注意してください。)
The obvious way to protect or authenticate an encrypted block is
to digitally sign it. However, many people do not wish to
habitually sign data, for a large number of reasons beyond the
scope of this document. Suffice it to say that many people
consider properties such as deniability to be as valuable as
integrity.
暗号化されたブロックを保護するか、または認証する当たり前の方法はそれにデジタルに署名することです。 しかしながら、多くの人々は習慣的にデータに署名したがっていません、このドキュメントの範囲を超えた多くの理由で。 それを満足させて、多くの人々が、否認権などの特性が保全と同じくらい貴重であると考えると言ってください。
OpenPGP addresses this desire to have more security than raw
encryption and yet preserve deniability with the MDC system. An
MDC is intentionally not a MAC. Its name was not selected by
accident. It is analogous to a checksum.
OpenPGPはMDCシステムで生の暗号化にもかかわらず、否認権より保護区多くのセキュリティを持つこの願望を扱います。 MDCは故意にそうです。MACでない。 名前は偶然に選択されませんでした。 それはチェックサムに類似しています。
Callas, et al Standards Track [Page 51] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[51ページ]RFC4880OpenPGP Message Format2007年11月
Despite the fact that it is a relatively modest system, it has
proved itself in the real world. It is an effective defense to
several attacks that have surfaced since it has been created. It
has met its modest goals admirably.
それが比較的穏やかなシステムであるという事実にもかかわらず、それは本当の世界でそれ自体に判明しました。 それはそれが作成されて以来表面化しているいくつかの攻撃への効果的な防衛です。 それは見事に穏やかな目標を達成しました。
Consequently, because it is a modest security system, it has
modest requirements on the hash function(s) it employs. It does
not rely on a hash function being collision-free, it relies on a
hash function being one-way. If a forger, Frank, wishes to send
Alice a (digitally) unsigned message that says, "I've always
secretly loved you, signed Bob", it is far easier for him to
construct a new message than it is to modify anything intercepted
from Bob. (Note also that if Bob wishes to communicate secretly
with Alice, but without authentication or identification and with
a threat model that includes forgers, he has a problem that
transcends mere cryptography.)
穏やかなセキュリティシステムであるので、その結果、それにはそれが使うハッシュ関数に関する穏やかな要件があります。 それは衝突なしであるハッシュ関数を当てにしないで、一方向であるハッシュ関数を当てにします。 「私はいつも秘かにあなたを愛していました、署名しているボブ」、捏造者(フランク)が言う(デジタルな)未署名のメッセージをアリスに送りたいなら、それは彼がボブから妨害されたものは何でも変更することになっているよりはるかに新しいメッセージを構成しやすいです。 (また、ボブが秘かに認証か識別なしでアリスにもかかわらず、捏造者を含んでいる脅威モデルと交信したいなら、彼には単なる暗号を超えている問題があることに注意してください。)
Note also that unlike nearly every other OpenPGP subsystem, there
are no parameters in the MDC system. It hard-defines SHA-1 as its
hash function. This is not an accident. It is an intentional
choice to avoid downgrade and cross-grade attacks while making a
simple, fast system. (A downgrade attack would be an attack that
replaced SHA-256 with SHA-1, for example. A cross-grade attack
would replace SHA-1 with another 160-bit hash, such as RIPE-
MD/160, for example.)
また、他のほとんどあらゆるOpenPGPサブシステムと異なって、MDCシステムにはパラメタが全くあるというわけではないことに注意してください。 それ、困難である、-、定義、ハッシュとしてのSHA-1は機能します。 これは事故ではありません。 簡単で、速いシステムを作っている間のダウングレードと交差しているグレード攻撃を避けるのは、意図的な選択です。 (例えば、ダウングレード攻撃はSHA-256をSHA-1に取り替えた攻撃でしょう。 例えば、交差しているグレード攻撃はSHA-1をRIPE MD/160などの別の160ビットのハッシュに取り替えるでしょう。)
However, given the present state of hash function cryptanalysis
and cryptography, it may be desirable to upgrade the MDC system to
a new hash function. See Section 13.11 in the "IANA
Considerations" for guidance.
しかしながら、暗号文解読術と暗号をハッシュ関数の現状に考えて、MDCシステムを新しいハッシュ関数にアップグレードさせるのは望ましいかもしれません。 指導に関して「IANA問題」でセクション13.11を見てください。
5.14. Modification Detection Code Packet (Tag 19)
5.14. 変更検出コードパケット(タグ19)
The Modification Detection Code packet contains a SHA-1 hash of plaintext data, which is used to detect message modification. It is only used with a Symmetrically Encrypted Integrity Protected Data packet. The Modification Detection Code packet MUST be the last packet in the plaintext data that is encrypted in the Symmetrically Encrypted Integrity Protected Data packet, and MUST appear in no other place.
Modification Detection Codeパケットは平文データのSHA-1ハッシュを含んでいます。(データは、メッセージ変更を検出するのに使用されます)。 それはSymmetrically Encrypted Integrity Protected Dataパケットと共に使用されるだけです。 Modification Detection CodeパケットはSymmetrically Encrypted Integrity Protected Dataパケットで暗号化されて、他の場所でないところに現れなければならない平文データで最後のパケットであるに違いありません。
A Modification Detection Code packet MUST have a length of 20 octets.
Modification Detection Codeパケットには、20の八重奏の長さがなければなりません。
Callas, et al Standards Track [Page 52] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[52ページ]RFC4880OpenPGP Message Format2007年11月
The body of this packet consists of:
このパケットのボディーは以下から成ります。
- A 20-octet SHA-1 hash of the preceding plaintext data of the
Symmetrically Encrypted Integrity Protected Data packet,
including prefix data, the tag octet, and length octet of the
Modification Detection Code packet.
- 接頭語データ、タグ八重奏を含むSymmetrically Encrypted Integrity Protected Dataパケットの前の平文データの20八重奏のSHA-1ハッシュとModification Detection Codeパケットの長さの八重奏。
Note that the Modification Detection Code packet MUST always use a new format encoding of the packet tag, and a one-octet encoding of the packet length. The reason for this is that the hashing rules for modification detection include a one-octet tag and one-octet length in the data hash. While this is a bit restrictive, it reduces complexity.
Modification Detection Codeパケットがいつもパケットタグをコード化する新しい形式、およびパケット長をコード化する1八重奏を使用しなければならないことに注意してください。 この理由は変更検出のための論じ尽くす規則がデータハッシュに1八重奏のタグと1八重奏の長さを含んでいるということです。 これは少し制限していますが、それは複雑さを減少させます。
6. Radix-64 Conversions
6. 基数-64の変換
As stated in the introduction, OpenPGP's underlying native representation for objects is a stream of arbitrary octets, and some systems desire these objects to be immune to damage caused by character set translation, data conversions, etc.
序論、OpenPGPがオブジェクトの固有の表現の基礎となる際に述べられているのが、任意の八重奏のストリームであり、いくつかのシステムが、これらのオブジェクトは文字集合翻訳でもたらされた損害に免疫があることを望んでいるので、データ変換しますなど。
In principle, any printable encoding scheme that met the requirements of the unsafe channel would suffice, since it would not change the underlying binary bit streams of the native OpenPGP data structures. The OpenPGP standard specifies one such printable encoding scheme to ensure interoperability.
原則として、危険なチャンネルに関する必要条件を満たしたどんな印刷可能なコード化体系も十分でしょう、固有のOpenPGPデータ構造の基本的な2進のビットストリームを変えないでしょう、したがって。 OpenPGP規格は、相互運用性を確実にするためにそのような体系の印刷可能なコード化1つを指定します。
OpenPGP's Radix-64 encoding is composed of two parts: a base64 encoding of the binary data and a checksum. The base64 encoding is identical to the MIME base64 content-transfer-encoding [RFC2045].
OpenPGPのRadix-64コード化は2つの部品で構成されます: バイナリ・データとチェックサムをコード化するbase64。 base64コード化はMIMEのbase64の満足している転送コード化[RFC2045]と同じです。
The checksum is a 24-bit Cyclic Redundancy Check (CRC) converted to four characters of radix-64 encoding by the same MIME base64 transformation, preceded by an equal sign (=). The CRC is computed by using the generator 0x864CFB and an initialization of 0xB704CE. The accumulation is done on the data before it is converted to radix-64, rather than on the converted data. A sample implementation of this algorithm is in the next section.
チェックサムは等号(=)が先行した同じMIMEでbase64をコード化する基数-64変換の4つのキャラクタに変換された24ビットのCyclic Redundancy Check(CRC)です。 CRCは、ジェネレータ0x864CFBと0xB704CEの初期化を使用することによって、計算されます。 データでは、変換されたデータに関してというよりむしろ基数-64にそれを変換する前に蓄積します。 このアルゴリズムのサンプル実装が次のセクションにあります。
The checksum with its leading equal sign MAY appear on the first line after the base64 encoded data.
base64がデータを暗号化した後に主な等号があるチェックサムは最初の系列に現れるかもしれません。
Rationale for CRC-24: The size of 24 bits fits evenly into printable base64. The nonzero initialization can detect more errors than a zero initialization.
CRC-24のための原理: 24ビットのサイズは均等に印刷可能なbase64に収まります。 非零初期化はaゼロ初期化より多くの誤りを検出できます。
Callas, et al Standards Track [Page 53] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[53ページ]RFC4880OpenPGP Message Format2007年11月
6.1. An Implementation of the CRC-24 in "C"
6.1. 「C」のCRC-24の実装
#define CRC24_INIT 0xB704CEL
#define CRC24_POLY 0x1864CFBL
#定義、CRC24_INIT 0xB704CEL#はCRC24_POLY 0x1864CFBLを定義します。
typedef long crc24;
crc24 crc_octets(unsigned char *octets, size_t len)
{
crc24 crc = CRC24_INIT;
int i;
while (len--) {
crc ^= (*octets++) << 16;
for (i = 0; i < 8; i++) {
crc <<= 1;
if (crc & 0x1000000)
crc ^= CRC24_POLY;
}
}
return crc & 0xFFFFFFL;
}
typedefの長いcrc24。 crc24 crc_八重奏(未署名の炭*八重奏、サイズ_t len)crc24 crcがINIT(int i)がゆったり過ごすCRC24_と等しい、(len--、)、(iは0と等しいです; i<8; i++) crc<<=1(crcと0×1000000)が^=CRC24_POLYをcrcするなら}というリターンcrcと0xFFFFFFLのためのcrc^=(*八重奏++)<<16
6.2. Forming ASCII Armor
6.2. ASCIIよろいかぶとを形成します。
When OpenPGP encodes data into ASCII Armor, it puts specific headers around the Radix-64 encoded data, so OpenPGP can reconstruct the data later. An OpenPGP implementation MAY use ASCII armor to protect raw binary data. OpenPGP informs the user what kind of data is encoded in the ASCII armor through the use of the headers.
OpenPGPがASCII Armorにデータを暗号化するとき、Radix-64の周りの特定のヘッダーのためにコード化されたデータを置くので、OpenPGPは後でデータを再建できます。 OpenPGP実装は、生のバイナリ・データを保護するのにASCIIよろいかぶとを使用するかもしれません。 OpenPGPは、どういうデータがASCIIよろいかぶとでヘッダーの使用でコード化されるかをユーザに知らせます。
Concatenating the following data creates ASCII Armor:
以下のデータを連結すると、ASCII Armorは作成されます:
- An Armor Header Line, appropriate for the type of data
- データのタイプに、適切なArmor Header線
- Armor Headers
- よろいかぶとヘッダー
- A blank (zero-length, or containing only whitespace) line
- 空白(ゼロ・レングス、または空白だけを含む)の系列
- The ASCII-Armored data
- ASCII武具のデータ
- An Armor Checksum
- よろいかぶとチェックサム
- The Armor Tail, which depends on the Armor Header Line
- Armor Tail。(そのArmor TailはArmor Header線に依存します)。
An Armor Header Line consists of the appropriate header line text
surrounded by five (5) dashes ('-', 0x2D) on either side of the
header line text. The header line text is chosen based upon the type
of data that is being encoded in Armor, and how it is being encoded.
Header line texts include the following strings:
Armor Header線は5(5)ダッシュ('--'、0x2D)でヘッダー系列テキストのどちらの側でも囲まれた適切なヘッダー系列テキストから成ります。 ヘッダー系列テキストはArmorでコード化されているデータと、それがどうコード化されるかに関するタイプに基づいた状態で選ばれています。 ヘッダー系列テキストは以下のストリングを含んでいます:
Callas, et al Standards Track [Page 54] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[54ページ]RFC4880OpenPGP Message Format2007年11月
BEGIN PGP MESSAGE
Used for signed, encrypted, or compressed files.
署名しているか、暗号化されたか、圧縮されたファイルのためのBEGIN PGP MESSAGE Used。
BEGIN PGP PUBLIC KEY BLOCK
Used for armoring public keys.
装甲公開鍵のためのBEGIN PGP PUBLIC KEY BLOCK Used。
BEGIN PGP PRIVATE KEY BLOCK
Used for armoring private keys.
装甲秘密鍵のためのBEGIN PGP PRIVATE KEY BLOCK Used。
BEGIN PGP MESSAGE, PART X/Y
Used for multi-part messages, where the armor is split amongst Y
parts, and this is the Xth part out of Y.
BEGIN PGP MESSAGE、複合メッセージのためのPART X/Y Used(よろいかぶとはYの部品の中で分けられて、これはXthである)はYから離れています。
BEGIN PGP MESSAGE, PART X
Used for multi-part messages, where this is the Xth part of an
unspecified number of parts. Requires the MESSAGE-ID Armor
Header to be used.
BEGIN PGP MESSAGE、複合メッセージのためのPART X Used。そこでは、これが不特定の数の一部分のXth部分です。 MESSAGE-ID Armor Headerが使用されるのが必要です。
BEGIN PGP SIGNATURE
Used for detached signatures, OpenPGP/MIME signatures, and
cleartext signatures. Note that PGP 2.x uses BEGIN PGP MESSAGE
for detached signatures.
離れている署名、OpenPGP/MIME署名、およびcleartext署名のためのBEGIN PGP SIGNATURE Used。 PGP 2.xが離れている署名にBEGIN PGP MESSAGEを使用することに注意してください。
Note that all these Armor Header Lines are to consist of a complete line. That is to say, there is always a line ending preceding the starting five dashes, and following the ending five dashes. The header lines, therefore, MUST start at the beginning of a line, and MUST NOT have text other than whitespace following them on the same line. These line endings are considered a part of the Armor Header Line for the purposes of determining the content they delimit. This is particularly important when computing a cleartext signature (see below).
これらのすべてのArmor Header線が完全な系列から成ることであることに注意してください。 すなわち、始めの5つのダッシュに先行する系列結末がいつもあります、そして、結末fiveに続くのを突進されます。 ヘッダー系列は、したがって、系列の始めに始まらなければならなくて、同じ系列でそれらに続いて、空白以外に、テキストを持ってはいけません。 これらの系列結末はそれらが区切る内容を決定する目的のためのArmor Header線の一部であると考えられます。 cleartext署名を計算するとき、これは特に重要です(以下を見てください)。
The Armor Headers are pairs of strings that can give the user or the receiving OpenPGP implementation some information about how to decode or use the message. The Armor Headers are a part of the armor, not a part of the message, and hence are not protected by any signatures applied to the message.
The Armor Headers are pairs of strings that can give the user or the receiving OpenPGP implementation some information about how to decode or use the message. The Armor Headers are a part of the armor, not a part of the message, and hence are not protected by any signatures applied to the message.
The format of an Armor Header is that of a key-value pair. A colon
(':' 0x38) and a single space (0x20) separate the key and value.
OpenPGP should consider improperly formatted Armor Headers to be
corruption of the ASCII Armor. Unknown keys should be reported to
the user, but OpenPGP should continue to process the message.
The format of an Armor Header is that of a key-value pair. A colon (':' 0x38) and a single space (0x20) separate the key and value. OpenPGP should consider improperly formatted Armor Headers to be corruption of the ASCII Armor. Unknown keys should be reported to the user, but OpenPGP should continue to process the message.
Note that some transport methods are sensitive to line length. While there is a limit of 76 characters for the Radix-64 data (Section 6.3), there is no limit to the length of Armor Headers. Care should
Note that some transport methods are sensitive to line length. While there is a limit of 76 characters for the Radix-64 data (Section 6.3), there is no limit to the length of Armor Headers. Care should
Callas, et al Standards Track [Page 55] RFC 4880 OpenPGP Message Format November 2007
Callas, et al Standards Track [Page 55] RFC 4880 OpenPGP Message Format November 2007
be taken that the Armor Headers are short enough to survive transport. One way to do this is to repeat an Armor Header key multiple times with different values for each so that no one line is overly long.
be taken that the Armor Headers are short enough to survive transport. One way to do this is to repeat an Armor Header key multiple times with different values for each so that no one line is overly long.
Currently defined Armor Header Keys are as follows:
Currently defined Armor Header Keys are as follows:
- "Version", which states the OpenPGP implementation and version
used to encode the message.
- "Version", which states the OpenPGP implementation and version used to encode the message.
- "Comment", a user-defined comment. OpenPGP defines all text to
be in UTF-8. A comment may be any UTF-8 string. However, the
whole point of armoring is to provide seven-bit-clean data.
Consequently, if a comment has characters that are outside the
US-ASCII range of UTF, they may very well not survive transport.
- "Comment", a user-defined comment. OpenPGP defines all text to be in UTF-8. A comment may be any UTF-8 string. However, the whole point of armoring is to provide seven-bit-clean data. Consequently, if a comment has characters that are outside the US-ASCII range of UTF, they may very well not survive transport.
- "MessageID", a 32-character string of printable characters. The
string must be the same for all parts of a multi-part message
that uses the "PART X" Armor Header. MessageID strings should be
unique enough that the recipient of the mail can associate all
the parts of a message with each other. A good checksum or
cryptographic hash function is sufficient.
- "MessageID", a 32-character string of printable characters. The string must be the same for all parts of a multi-part message that uses the "PART X" Armor Header. MessageID strings should be unique enough that the recipient of the mail can associate all the parts of a message with each other. A good checksum or cryptographic hash function is sufficient.
The MessageID SHOULD NOT appear unless it is in a multi-part
message. If it appears at all, it MUST be computed from the
finished (encrypted, signed, etc.) message in a deterministic
fashion, rather than contain a purely random value. This is to
allow the legitimate recipient to determine that the MessageID
cannot serve as a covert means of leaking cryptographic key
information.
The MessageID SHOULD NOT appear unless it is in a multi-part message. If it appears at all, it MUST be computed from the finished (encrypted, signed, etc.) message in a deterministic fashion, rather than contain a purely random value. This is to allow the legitimate recipient to determine that the MessageID cannot serve as a covert means of leaking cryptographic key information.
- "Hash", a comma-separated list of hash algorithms used in this
message. This is used only in cleartext signed messages.
- "Hash", a comma-separated list of hash algorithms used in this message. This is used only in cleartext signed messages.
- "Charset", a description of the character set that the plaintext
is in. Please note that OpenPGP defines text to be in UTF-8. An
implementation will get best results by translating into and out
of UTF-8. However, there are many instances where this is easier
said than done. Also, there are communities of users who have no
need for UTF-8 because they are all happy with a character set
like ISO Latin-5 or a Japanese character set. In such instances,
an implementation MAY override the UTF-8 default by using this
header key. An implementation MAY implement this key and any
translations it cares to; an implementation MAY ignore it and
assume all text is UTF-8.
- "Charset", a description of the character set that the plaintext is in. Please note that OpenPGP defines text to be in UTF-8. An implementation will get best results by translating into and out of UTF-8. However, there are many instances where this is easier said than done. Also, there are communities of users who have no need for UTF-8 because they are all happy with a character set like ISO Latin-5 or a Japanese character set. In such instances, an implementation MAY override the UTF-8 default by using this header key. An implementation MAY implement this key and any translations it cares to; an implementation MAY ignore it and assume all text is UTF-8.
Callas, et al Standards Track [Page 56] RFC 4880 OpenPGP Message Format November 2007
Callas, et al Standards Track [Page 56] RFC 4880 OpenPGP Message Format November 2007
The Armor Tail Line is composed in the same manner as the Armor
Header Line, except the string "BEGIN" is replaced by the string
"END".
The Armor Tail Line is composed in the same manner as the Armor Header Line, except the string "BEGIN" is replaced by the string "END".
6.3. Encoding Binary in Radix-64
6.3. Encoding Binary in Radix-64
The encoding process represents 24-bit groups of input bits as output strings of 4 encoded characters. Proceeding from left to right, a 24-bit input group is formed by concatenating three 8-bit input groups. These 24 bits are then treated as four concatenated 6-bit groups, each of which is translated into a single digit in the Radix-64 alphabet. When encoding a bit stream with the Radix-64 encoding, the bit stream must be presumed to be ordered with the most significant bit first. That is, the first bit in the stream will be the high-order bit in the first 8-bit octet, and the eighth bit will be the low-order bit in the first 8-bit octet, and so on.
The encoding process represents 24-bit groups of input bits as output strings of 4 encoded characters. Proceeding from left to right, a 24-bit input group is formed by concatenating three 8-bit input groups. These 24 bits are then treated as four concatenated 6-bit groups, each of which is translated into a single digit in the Radix-64 alphabet. When encoding a bit stream with the Radix-64 encoding, the bit stream must be presumed to be ordered with the most significant bit first. That is, the first bit in the stream will be the high-order bit in the first 8-bit octet, and the eighth bit will be the low-order bit in the first 8-bit octet, and so on.
+--first octet--+-second octet--+--third octet--+
|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
+-----------+---+-------+-------+---+-----------+
|5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|
+--1.index--+--2.index--+--3.index--+--4.index--+
+--first octet--+-second octet--+--third octet--+ |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| +-----------+---+-------+-------+---+-----------+ |5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0| +--1.index--+--2.index--+--3.index--+--4.index--+
Each 6-bit group is used as an index into an array of 64 printable characters from the table below. The character referenced by the index is placed in the output string.
Each 6-bit group is used as an index into an array of 64 printable characters from the table below. The character referenced by the index is placed in the output string.
Value Encoding Value Encoding Value Encoding Value Encoding
0 A 17 R 34 i 51 z
1 B 18 S 35 j 52 0
2 C 19 T 36 k 53 1
3 D 20 U 37 l 54 2
4 E 21 V 38 m 55 3
5 F 22 W 39 n 56 4
6 G 23 X 40 o 57 5
7 H 24 Y 41 p 58 6
8 I 25 Z 42 q 59 7
9 J 26 a 43 r 60 8
10 K 27 b 44 s 61 9
11 L 28 c 45 t 62 +
12 M 29 d 46 u 63 /
13 N 30 e 47 v
14 O 31 f 48 w (pad) =
15 P 32 g 49 x
16 Q 33 h 50 y
Value Encoding Value Encoding Value Encoding Value Encoding 0 A 17 R 34 i 51 z 1 B 18 S 35 j 52 0 2 C 19 T 36 k 53 1 3 D 20 U 37 l 54 2 4 E 21 V 38 m 55 3 5 F 22 W 39 n 56 4 6 G 23 X 40 o 57 5 7 H 24 Y 41 p 58 6 8 I 25 Z 42 q 59 7 9 J 26 a 43 r 60 8 10 K 27 b 44 s 61 9 11 L 28 c 45 t 62 + 12 M 29 d 46 u 63 / 13 N 30 e 47 v 14 O 31 f 48 w (pad) = 15 P 32 g 49 x 16 Q 33 h 50 y
The encoded output stream must be represented in lines of no more than 76 characters each.
The encoded output stream must be represented in lines of no more than 76 characters each.
Callas, et al Standards Track [Page 57] RFC 4880 OpenPGP Message Format November 2007
Callas, et al Standards Track [Page 57] RFC 4880 OpenPGP Message Format November 2007
Special processing is performed if fewer than 24 bits are available at the end of the data being encoded. There are three possibilities:
Special processing is performed if fewer than 24 bits are available at the end of the data being encoded. There are three possibilities:
1. The last data group has 24 bits (3 octets). No special processing
is needed.
1. The last data group has 24 bits (3 octets). No special processing is needed.
2. The last data group has 16 bits (2 octets). The first two 6-bit
groups are processed as above. The third (incomplete) data group
has two zero-value bits added to it, and is processed as above. A
pad character (=) is added to the output.
2. The last data group has 16 bits (2 octets). The first two 6-bit groups are processed as above. The third (incomplete) data group has two zero-value bits added to it, and is processed as above. A pad character (=) is added to the output.
3. The last data group has 8 bits (1 octet). The first 6-bit group
is processed as above. The second (incomplete) data group has
four zero-value bits added to it, and is processed as above. Two
pad characters (=) are added to the output.
3. The last data group has 8 bits (1 octet). The first 6-bit group is processed as above. The second (incomplete) data group has four zero-value bits added to it, and is processed as above. Two pad characters (=) are added to the output.
6.4. Decoding Radix-64
6.4. Decoding Radix-64
In Radix-64 data, characters other than those in the table, line breaks, and other white space probably indicate a transmission error, about which a warning message or even a message rejection might be appropriate under some circumstances. Decoding software must ignore all white space.
In Radix-64 data, characters other than those in the table, line breaks, and other white space probably indicate a transmission error, about which a warning message or even a message rejection might be appropriate under some circumstances. Decoding software must ignore all white space.
Because it is used only for padding at the end of the data, the occurrence of any "=" characters may be taken as evidence that the end of the data has been reached (without truncation in transit). No such assurance is possible, however, when the number of octets transmitted was a multiple of three and no "=" characters are present.
Because it is used only for padding at the end of the data, the occurrence of any "=" characters may be taken as evidence that the end of the data has been reached (without truncation in transit). No such assurance is possible, however, when the number of octets transmitted was a multiple of three and no "=" characters are present.
Callas, et al Standards Track [Page 58] RFC 4880 OpenPGP Message Format November 2007
Callas, et al Standards Track [Page 58] RFC 4880 OpenPGP Message Format November 2007
6.5. Examples of Radix-64
6.5. Examples of Radix-64
Input data: 0x14FB9C03D97E
Hex: 1 4 F B 9 C | 0 3 D 9 7 E
8-bit: 00010100 11111011 10011100 | 00000011 11011001 11111110
6-bit: 000101 001111 101110 011100 | 000000 111101 100111 111110
Decimal: 5 15 46 28 0 61 37 62
Output: F P u c A 9 l +
Input data: 0x14FB9C03D9
Hex: 1 4 F B 9 C | 0 3 D 9
8-bit: 00010100 11111011 10011100 | 00000011 11011001
pad with 00
6-bit: 000101 001111 101110 011100 | 000000 111101 100100
Decimal: 5 15 46 28 0 61 36
pad with =
Output: F P u c A 9 k =
Input data: 0x14FB9C03
Hex: 1 4 F B 9 C | 0 3
8-bit: 00010100 11111011 10011100 | 00000011
pad with 0000
6-bit: 000101 001111 101110 011100 | 000000 110000
Decimal: 5 15 46 28 0 48
pad with = =
Output: F P u c A w = =
Input data: 0x14FB9C03D97E Hex: 1 4 F B 9 C | 0 3 D 9 7 E 8-bit: 00010100 11111011 10011100 | 00000011 11011001 11111110 6-bit: 000101 001111 101110 011100 | 000000 111101 100111 111110 Decimal: 5 15 46 28 0 61 37 62 Output: F P u c A 9 l + Input data: 0x14FB9C03D9 Hex: 1 4 F B 9 C | 0 3 D 9 8-bit: 00010100 11111011 10011100 | 00000011 11011001 pad with 00 6-bit: 000101 001111 101110 011100 | 000000 111101 100100 Decimal: 5 15 46 28 0 61 36 pad with = Output: F P u c A 9 k = Input data: 0x14FB9C03 Hex: 1 4 F B 9 C | 0 3 8-bit: 00010100 11111011 10011100 | 00000011 pad with 0000 6-bit: 000101 001111 101110 011100 | 000000 110000 Decimal: 5 15 46 28 0 48 pad with = = Output: F P u c A w = =
6.6. Example of an ASCII Armored Message
6.6. Example of an ASCII Armored Message
-----BEGIN PGP MESSAGE----- Version: OpenPrivacy 0.99
-----BEGIN PGP MESSAGE----- Version: OpenPrivacy 0.99
yDgBO22WxBHv7O8X7O/jygAEzol56iUKiXmV+XmpCtmpqQUKiQrFqclFqUDBovzS vBSFjNSiVHsuAA== =njUN -----END PGP MESSAGE-----
yDgBO22WxBHv7O8X7O/jygAEzol56iUKiXmV+XmpCtmpqQUKiQrFqclFqUDBovzS vBSFjNSiVHsuAA== =njUN -----END PGP MESSAGE-----
Note that this example has extra indenting; an actual armored message would have no leading whitespace.
Note that this example has extra indenting; an actual armored message would have no leading whitespace.
7. Cleartext Signature Framework
7. Cleartext Signature Framework
It is desirable to be able to sign a textual octet stream without ASCII armoring the stream itself, so the signed text is still readable without special software. In order to bind a signature to such a cleartext, this framework is used. (Note that this framework is not intended to be reversible. RFC 3156 [RFC3156] defines another way to sign cleartext messages for environments that support MIME.)
It is desirable to be able to sign a textual octet stream without ASCII armoring the stream itself, so the signed text is still readable without special software. In order to bind a signature to such a cleartext, this framework is used. (Note that this framework is not intended to be reversible. RFC 3156 [RFC3156] defines another way to sign cleartext messages for environments that support MIME.)
Callas, et al Standards Track [Page 59] RFC 4880 OpenPGP Message Format November 2007
Callas, et al Standards Track [Page 59] RFC 4880 OpenPGP Message Format November 2007
The cleartext signed message consists of:
The cleartext signed message consists of:
- The cleartext header '-----BEGIN PGP SIGNED MESSAGE-----' on a
single line,
- The cleartext header '-----BEGIN PGP SIGNED MESSAGE-----' on a single line,
- One or more "Hash" Armor Headers,
- One or more "Hash" Armor Headers,
- Exactly one empty line not included into the message digest,
- Exactly one empty line not included into the message digest,
- The dash-escaped cleartext that is included into the message
digest,
- The dash-escaped cleartext that is included into the message digest,
- The ASCII armored signature(s) including the '-----BEGIN PGP
SIGNATURE-----' Armor Header and Armor Tail Lines.
- The ASCII armored signature(s) including the '-----BEGIN PGP SIGNATURE-----' Armor Header and Armor Tail Lines.
If the "Hash" Armor Header is given, the specified message digest algorithm(s) are used for the signature. If there are no such headers, MD5 is used. If MD5 is the only hash used, then an implementation MAY omit this header for improved V2.x compatibility. If more than one message digest is used in the signature, the "Hash" armor header contains a comma-delimited list of used message digests.
If the "Hash" Armor Header is given, the specified message digest algorithm(s) are used for the signature. If there are no such headers, MD5 is used. If MD5 is the only hash used, then an implementation MAY omit this header for improved V2.x compatibility. If more than one message digest is used in the signature, the "Hash" armor header contains a comma-delimited list of used message digests.
Current message digest names are described below with the algorithm IDs.
Current message digest names are described below with the algorithm IDs.
An implementation SHOULD add a line break after the cleartext, but MAY omit it if the cleartext ends with a line break. This is for visual clarity.
An implementation SHOULD add a line break after the cleartext, but MAY omit it if the cleartext ends with a line break. This is for visual clarity.
7.1. Dash-Escaped Text
7.1. Dash-Escaped Text
The cleartext content of the message must also be dash-escaped.
The cleartext content of the message must also be dash-escaped.
Dash-escaped cleartext is the ordinary cleartext where every line starting with a dash '-' (0x2D) is prefixed by the sequence dash '-' (0x2D) and space ' ' (0x20). This prevents the parser from recognizing armor headers of the cleartext itself. An implementation MAY dash-escape any line, SHOULD dash-escape lines commencing "From" followed by a space, and MUST dash-escape any line commencing in a dash. The message digest is computed using the cleartext itself, not the dash-escaped form.
Dash-escaped cleartext is the ordinary cleartext where every line starting with a dash '-' (0x2D) is prefixed by the sequence dash '-' (0x2D) and space ' ' (0x20). This prevents the parser from recognizing armor headers of the cleartext itself. An implementation MAY dash-escape any line, SHOULD dash-escape lines commencing "From" followed by a space, and MUST dash-escape any line commencing in a dash. The message digest is computed using the cleartext itself, not the dash-escaped form.
As with binary signatures on text documents, a cleartext signature is calculated on the text using canonical <CR><LF> line endings. The line ending (i.e., the <CR><LF>) before the '-----BEGIN PGP SIGNATURE-----' line that terminates the signed text is not considered part of the signed text.
As with binary signatures on text documents, a cleartext signature is calculated on the text using canonical <CR><LF> line endings. The line ending (i.e., the <CR><LF>) before the '-----BEGIN PGP SIGNATURE-----' line that terminates the signed text is not considered part of the signed text.
Callas, et al Standards Track [Page 60] RFC 4880 OpenPGP Message Format November 2007
Callas, et al Standards Track [Page 60] RFC 4880 OpenPGP Message Format November 2007
When reversing dash-escaping, an implementation MUST strip the string "- " if it occurs at the beginning of a line, and SHOULD warn on "-" and any character other than a space at the beginning of a line.
When reversing dash-escaping, an implementation MUST strip the string "- " if it occurs at the beginning of a line, and SHOULD warn on "-" and any character other than a space at the beginning of a line.
Also, any trailing whitespace -- spaces (0x20) and tabs (0x09) -- at the end of any line is removed when the cleartext signature is generated.
Also, any trailing whitespace -- spaces (0x20) and tabs (0x09) -- at the end of any line is removed when the cleartext signature is generated.
8. Regular Expressions
8. Regular Expressions
A regular expression is zero or more branches, separated by '|'. It matches anything that matches one of the branches.
A regular expression is zero or more branches, separated by '|'. It matches anything that matches one of the branches.
A branch is zero or more pieces, concatenated. It matches a match for the first, followed by a match for the second, etc.
A branch is zero or more pieces, concatenated. It matches a match for the first, followed by a match for the second, etc.
A piece is an atom possibly followed by '*', '+', or '?'. An atom followed by '*' matches a sequence of 0 or more matches of the atom. An atom followed by '+' matches a sequence of 1 or more matches of the atom. An atom followed by '?' matches a match of the atom, or the null string.
A piece is an atom possibly followed by '*', '+', or '?'. An atom followed by '*' matches a sequence of 0 or more matches of the atom. An atom followed by '+' matches a sequence of 1 or more matches of the atom. An atom followed by '?' matches a match of the atom, or the null string.
An atom is a regular expression in parentheses (matching a match for the regular expression), a range (see below), '.' (matching any single character), '^' (matching the null string at the beginning of the input string), '$' (matching the null string at the end of the input string), a '\' followed by a single character (matching that character), or a single character with no other significance (matching that character).
An atom is a regular expression in parentheses (matching a match for the regular expression), a range (see below), '.' (matching any single character), '^' (matching the null string at the beginning of the input string), '$' (matching the null string at the end of the input string), a '\' followed by a single character (matching that character), or a single character with no other significance (matching that character).
A range is a sequence of characters enclosed in '[]'. It normally matches any single character from the sequence. If the sequence begins with '^', it matches any single character not from the rest of the sequence. If two characters in the sequence are separated by '-', this is shorthand for the full list of ASCII characters between them (e.g., '[0-9]' matches any decimal digit). To include a literal ']' in the sequence, make it the first character (following a possible '^'). To include a literal '-', make it the first or last character.
A range is a sequence of characters enclosed in '[]'. It normally matches any single character from the sequence. If the sequence begins with '^', it matches any single character not from the rest of the sequence. If two characters in the sequence are separated by '-', this is shorthand for the full list of ASCII characters between them (e.g., '[0-9]' matches any decimal digit). To include a literal ']' in the sequence, make it the first character (following a possible '^'). To include a literal '-', make it the first or last character.
9. Constants
9. Constants
This section describes the constants used in OpenPGP.
This section describes the constants used in OpenPGP.
Note that these tables are not exhaustive lists; an implementation MAY implement an algorithm not on these lists, so long as the algorithm numbers are chosen from the private or experimental algorithm range.
Note that these tables are not exhaustive lists; an implementation MAY implement an algorithm not on these lists, so long as the algorithm numbers are chosen from the private or experimental algorithm range.
Callas, et al Standards Track [Page 61] RFC 4880 OpenPGP Message Format November 2007
Callas, et al Standards Track [Page 61] RFC 4880 OpenPGP Message Format November 2007
See the section "Notes on Algorithms" below for more discussion of the algorithms.
See the section "Notes on Algorithms" below for more discussion of the algorithms.
9.1. Public-Key Algorithms
9.1. Public-Key Algorithms
ID Algorithm
-- ---------
1 - RSA (Encrypt or Sign) [HAC]
2 - RSA Encrypt-Only [HAC]
3 - RSA Sign-Only [HAC]
16 - Elgamal (Encrypt-Only) [ELGAMAL] [HAC]
17 - DSA (Digital Signature Algorithm) [FIPS186] [HAC]
18 - Reserved for Elliptic Curve
19 - Reserved for ECDSA
20 - Reserved (formerly Elgamal Encrypt or Sign)
21 - Reserved for Diffie-Hellman (X9.42,
as defined for IETF-S/MIME)
100 to 110 - Private/Experimental algorithm
ID Algorithm -- --------- 1 - RSA (Encrypt or Sign) [HAC] 2 - RSA Encrypt-Only [HAC] 3 - RSA Sign-Only [HAC] 16 - Elgamal (Encrypt-Only) [ELGAMAL] [HAC] 17 - DSA (Digital Signature Algorithm) [FIPS186] [HAC] 18 - Reserved for Elliptic Curve 19 - Reserved for ECDSA 20 - Reserved (formerly Elgamal Encrypt or Sign) 21 - Reserved for Diffie-Hellman (X9.42, as defined for IETF-S/MIME) 100 to 110 - Private/Experimental algorithm
Implementations MUST implement DSA for signatures, and Elgamal for encryption. Implementations SHOULD implement RSA keys (1). RSA Encrypt-Only (2) and RSA Sign-Only are deprecated and SHOULD NOT be generated, but may be interpreted. See Section 13.5. See Section 13.8 for notes on Elliptic Curve (18), ECDSA (19), Elgamal Encrypt or Sign (20), and X9.42 (21). Implementations MAY implement any other algorithm.
Implementations MUST implement DSA for signatures, and Elgamal for encryption. Implementations SHOULD implement RSA keys (1). RSA Encrypt-Only (2) and RSA Sign-Only are deprecated and SHOULD NOT be generated, but may be interpreted. See Section 13.5. See Section 13.8 for notes on Elliptic Curve (18), ECDSA (19), Elgamal Encrypt or Sign (20), and X9.42 (21). Implementations MAY implement any other algorithm.
9.2. Symmetric-Key Algorithms
9.2. Symmetric-Key Algorithms
ID Algorithm
-- ---------
0 - Plaintext or unencrypted data
1 - IDEA [IDEA]
2 - TripleDES (DES-EDE, [SCHNEIER] [HAC] -
168 bit key derived from 192)
3 - CAST5 (128 bit key, as per [RFC2144])
4 - Blowfish (128 bit key, 16 rounds) [BLOWFISH]
5 - Reserved
6 - Reserved
7 - AES with 128-bit key [AES]
8 - AES with 192-bit key
9 - AES with 256-bit key
10 - Twofish with 256-bit key [TWOFISH]
100 to 110 - Private/Experimental algorithm
ID Algorithm -- --------- 0 - Plaintext or unencrypted data 1 - IDEA [IDEA] 2 - TripleDES (DES-EDE, [SCHNEIER] [HAC] - 168 bit key derived from 192) 3 - CAST5 (128 bit key, as per [RFC2144]) 4 - Blowfish (128 bit key, 16 rounds) [BLOWFISH] 5 - Reserved 6 - Reserved 7 - AES with 128-bit key [AES] 8 - AES with 192-bit key 9 - AES with 256-bit key 10 - Twofish with 256-bit key [TWOFISH] 100 to 110 - Private/Experimental algorithm
Implementations MUST implement TripleDES. Implementations SHOULD implement AES-128 and CAST5. Implementations that interoperate with
Implementations MUST implement TripleDES. Implementations SHOULD implement AES-128 and CAST5. Implementations that interoperate with
Callas, et al Standards Track [Page 62] RFC 4880 OpenPGP Message Format November 2007
Callas, et al Standards Track [Page 62] RFC 4880 OpenPGP Message Format November 2007
PGP 2.6 or earlier need to support IDEA, as that is the only symmetric cipher those versions use. Implementations MAY implement any other algorithm.
PGP 2.6 or earlier need to support IDEA, as that is the only symmetric cipher those versions use. Implementations MAY implement any other algorithm.
9.3. Compression Algorithms
9.3. Compression Algorithms
ID Algorithm
-- ---------
0 - Uncompressed
1 - ZIP [RFC1951]
2 - ZLIB [RFC1950]
3 - BZip2 [BZ2]
100 to 110 - Private/Experimental algorithm
ID Algorithm -- --------- 0 - Uncompressed 1 - ZIP [RFC1951] 2 - ZLIB [RFC1950] 3 - BZip2 [BZ2] 100 to 110 - Private/Experimental algorithm
Implementations MUST implement uncompressed data. Implementations SHOULD implement ZIP. Implementations MAY implement any other algorithm.
Implementations MUST implement uncompressed data. Implementations SHOULD implement ZIP. Implementations MAY implement any other algorithm.
9.4. Hash Algorithms
9.4. Hash Algorithms
ID Algorithm Text Name
-- --------- ---------
1 - MD5 [HAC] "MD5"
2 - SHA-1 [FIPS180] "SHA1"
3 - RIPE-MD/160 [HAC] "RIPEMD160"
4 - Reserved
5 - Reserved
6 - Reserved
7 - Reserved
8 - SHA256 [FIPS180] "SHA256"
9 - SHA384 [FIPS180] "SHA384"
10 - SHA512 [FIPS180] "SHA512"
11 - SHA224 [FIPS180] "SHA224"
100 to 110 - Private/Experimental algorithm
ID Algorithm Text Name -- --------- --------- 1 - MD5 [HAC] "MD5" 2 - SHA-1 [FIPS180] "SHA1" 3 - RIPE-MD/160 [HAC] "RIPEMD160" 4 - Reserved 5 - Reserved 6 - Reserved 7 - Reserved 8 - SHA256 [FIPS180] "SHA256" 9 - SHA384 [FIPS180] "SHA384" 10 - SHA512 [FIPS180] "SHA512" 11 - SHA224 [FIPS180] "SHA224" 100 to 110 - Private/Experimental algorithm
Implementations MUST implement SHA-1. Implementations MAY implement other algorithms. MD5 is deprecated.
Implementations MUST implement SHA-1. Implementations MAY implement other algorithms. MD5 is deprecated.
10. IANA Considerations
10. IANA Considerations
OpenPGP is highly parameterized, and consequently there are a number of considerations for allocating parameters for extensions. This section describes how IANA should look at extensions to the protocol as described in this document.
OpenPGP is highly parameterized, and consequently there are a number of considerations for allocating parameters for extensions. This section describes how IANA should look at extensions to the protocol as described in this document.
Callas, et al Standards Track [Page 63] RFC 4880 OpenPGP Message Format November 2007
Callas, et al Standards Track [Page 63] RFC 4880 OpenPGP Message Format November 2007
10.1. New String-to-Key Specifier Types
10.1. New String-to-Key Specifier Types
OpenPGP S2K specifiers contain a mechanism for new algorithms to turn a string into a key. This specification creates a registry of S2K specifier types. The registry includes the S2K type, the name of the S2K, and a reference to the defining specification. The initial values for this registry can be found in Section 3.7.1. Adding a new S2K specifier MUST be done through the IETF CONSENSUS method, as described in [RFC2434].
OpenPGP S2K specifiers contain a mechanism for new algorithms to turn a string into a key. This specification creates a registry of S2K specifier types. The registry includes the S2K type, the name of the S2K, and a reference to the defining specification. The initial values for this registry can be found in Section 3.7.1. Adding a new S2K specifier MUST be done through the IETF CONSENSUS method, as described in [RFC2434].
10.2. New Packets
10.2. New Packets
Major new features of OpenPGP are defined through new packet types. This specification creates a registry of packet types. The registry includes the packet type, the name of the packet, and a reference to the defining specification. The initial values for this registry can be found in Section 4.3. Adding a new packet type MUST be done through the IETF CONSENSUS method, as described in [RFC2434].
Major new features of OpenPGP are defined through new packet types. This specification creates a registry of packet types. The registry includes the packet type, the name of the packet, and a reference to the defining specification. The initial values for this registry can be found in Section 4.3. Adding a new packet type MUST be done through the IETF CONSENSUS method, as described in [RFC2434].
10.2.1. User Attribute Types
10.2.1. User Attribute Types
The User Attribute packet permits an extensible mechanism for other types of certificate identification. This specification creates a registry of User Attribute types. The registry includes the User Attribute type, the name of the User Attribute, and a reference to the defining specification. The initial values for this registry can be found in Section 5.12. Adding a new User Attribute type MUST be done through the IETF CONSENSUS method, as described in [RFC2434].
The User Attribute packet permits an extensible mechanism for other types of certificate identification. This specification creates a registry of User Attribute types. The registry includes the User Attribute type, the name of the User Attribute, and a reference to the defining specification. The initial values for this registry can be found in Section 5.12. Adding a new User Attribute type MUST be done through the IETF CONSENSUS method, as described in [RFC2434].
10.2.1.1. Image Format Subpacket Types
10.2.1.1. Image Format Subpacket Types
Within User Attribute packets, there is an extensible mechanism for other types of image-based user attributes. This specification creates a registry of Image Attribute subpacket types. The registry includes the Image Attribute subpacket type, the name of the Image Attribute subpacket, and a reference to the defining specification. The initial values for this registry can be found in Section 5.12.1. Adding a new Image Attribute subpacket type MUST be done through the IETF CONSENSUS method, as described in [RFC2434].
Within User Attribute packets, there is an extensible mechanism for other types of image-based user attributes. This specification creates a registry of Image Attribute subpacket types. The registry includes the Image Attribute subpacket type, the name of the Image Attribute subpacket, and a reference to the defining specification. The initial values for this registry can be found in Section 5.12.1. Adding a new Image Attribute subpacket type MUST be done through the IETF CONSENSUS method, as described in [RFC2434].
10.2.2. New Signature Subpackets
10.2.2. New Signature Subpackets
OpenPGP signatures contain a mechanism for signed (or unsigned) data to be added to them for a variety of purposes in the Signature subpackets as discussed in Section 5.2.3.1. This specification creates a registry of Signature subpacket types. The registry includes the Signature subpacket type, the name of the subpacket, and a reference to the defining specification. The initial values for
OpenPGP signatures contain a mechanism for signed (or unsigned) data to be added to them for a variety of purposes in the Signature subpackets as discussed in Section 5.2.3.1. This specification creates a registry of Signature subpacket types. The registry includes the Signature subpacket type, the name of the subpacket, and a reference to the defining specification. The initial values for
Callas, et al Standards Track [Page 64] RFC 4880 OpenPGP Message Format November 2007
Callas, et al Standards Track [Page 64] RFC 4880 OpenPGP Message Format November 2007
this registry can be found in Section 5.2.3.1. Adding a new Signature subpacket MUST be done through the IETF CONSENSUS method, as described in [RFC2434].
this registry can be found in Section 5.2.3.1. Adding a new Signature subpacket MUST be done through the IETF CONSENSUS method, as described in [RFC2434].
10.2.2.1. Signature Notation Data Subpackets
10.2.2.1. Signature Notation Data Subpackets
OpenPGP signatures further contain a mechanism for extensions in signatures. These are the Notation Data subpackets, which contain a key/value pair. Notations contain a user space that is completely unmanaged and an IETF space.
OpenPGP signatures further contain a mechanism for extensions in signatures. These are the Notation Data subpackets, which contain a key/value pair. Notations contain a user space that is completely unmanaged and an IETF space.
This specification creates a registry of Signature Notation Data types. The registry includes the Signature Notation Data type, the name of the Signature Notation Data, its allowed values, and a reference to the defining specification. The initial values for this registry can be found in Section 5.2.3.16. Adding a new Signature Notation Data subpacket MUST be done through the EXPERT REVIEW method, as described in [RFC2434].
This specification creates a registry of Signature Notation Data types. The registry includes the Signature Notation Data type, the name of the Signature Notation Data, its allowed values, and a reference to the defining specification. The initial values for this registry can be found in Section 5.2.3.16. Adding a new Signature Notation Data subpacket MUST be done through the EXPERT REVIEW method, as described in [RFC2434].
10.2.2.2. Key Server Preference Extensions
10.2.2.2. Key Server Preference Extensions
OpenPGP signatures contain a mechanism for preferences to be specified about key servers. This specification creates a registry of key server preferences. The registry includes the key server preference, the name of the preference, and a reference to the defining specification. The initial values for this registry can be found in Section 5.2.3.17. Adding a new key server preference MUST be done through the IETF CONSENSUS method, as described in [RFC2434].
OpenPGP signatures contain a mechanism for preferences to be specified about key servers. This specification creates a registry of key server preferences. The registry includes the key server preference, the name of the preference, and a reference to the defining specification. The initial values for this registry can be found in Section 5.2.3.17. Adding a new key server preference MUST be done through the IETF CONSENSUS method, as described in [RFC2434].
10.2.2.3. Key Flags Extensions
10.2.2.3. Key Flags Extensions
OpenPGP signatures contain a mechanism for flags to be specified about key usage. This specification creates a registry of key usage flags. The registry includes the key flags value, the name of the flag, and a reference to the defining specification. The initial values for this registry can be found in Section 5.2.3.21. Adding a new key usage flag MUST be done through the IETF CONSENSUS method, as described in [RFC2434].
OpenPGP signatures contain a mechanism for flags to be specified about key usage. This specification creates a registry of key usage flags. The registry includes the key flags value, the name of the flag, and a reference to the defining specification. The initial values for this registry can be found in Section 5.2.3.21. Adding a new key usage flag MUST be done through the IETF CONSENSUS method, as described in [RFC2434].
10.2.2.4. Reason for Revocation Extensions
10.2.2.4. Reason for Revocation Extensions
OpenPGP signatures contain a mechanism for flags to be specified about why a key was revoked. This specification creates a registry of "Reason for Revocation" flags. The registry includes the "Reason for Revocation" flags value, the name of the flag, and a reference to the defining specification. The initial values for this registry can be found in Section 5.2.3.23. Adding a new feature flag MUST be done through the IETF CONSENSUS method, as described in [RFC2434].
OpenPGP signatures contain a mechanism for flags to be specified about why a key was revoked. This specification creates a registry of "Reason for Revocation" flags. The registry includes the "Reason for Revocation" flags value, the name of the flag, and a reference to the defining specification. The initial values for this registry can be found in Section 5.2.3.23. Adding a new feature flag MUST be done through the IETF CONSENSUS method, as described in [RFC2434].
Callas, et al Standards Track [Page 65] RFC 4880 OpenPGP Message Format November 2007
Callas, et al Standards Track [Page 65] RFC 4880 OpenPGP Message Format November 2007
10.2.2.5. Implementation Features
10.2.2.5. Implementation Features
OpenPGP signatures contain a mechanism for flags to be specified stating which optional features an implementation supports. This specification creates a registry of feature-implementation flags. The registry includes the feature-implementation flags value, the name of the flag, and a reference to the defining specification. The initial values for this registry can be found in Section 5.2.3.24. Adding a new feature-implementation flag MUST be done through the IETF CONSENSUS method, as described in [RFC2434].
OpenPGP signatures contain a mechanism for flags to be specified stating which optional features an implementation supports. This specification creates a registry of feature-implementation flags. The registry includes the feature-implementation flags value, the name of the flag, and a reference to the defining specification. The initial values for this registry can be found in Section 5.2.3.24. Adding a new feature-implementation flag MUST be done through the IETF CONSENSUS method, as described in [RFC2434].
Also see Section 13.12 for more information about when feature flags are needed.
また、特徴旗が必要である時に関する詳しい情報に関してセクション13.12を見てください。
10.2.3. New Packet Versions
10.2.3. 新しいパケットバージョン
The core OpenPGP packets all have version numbers, and can be revised by introducing a new version of an existing packet. This specification creates a registry of packet types. The registry includes the packet type, the number of the version, and a reference to the defining specification. The initial values for this registry can be found in Section 5. Adding a new packet version MUST be done through the IETF CONSENSUS method, as described in [RFC2434].
コアOpenPGPパケットは、バージョン番号をすべて持って、既存のパケットの新しいバージョンを紹介することによって、改訂できます。 この仕様はパケットタイプの登録を作成します。 登録はパケットタイプ、バージョンの数、および定義仕様の指示するものを含んでいます。 セクション5でこの登録への初期の値を見つけることができます。 [RFC2434]で説明されるようにIETF CONSENSUSメソッドで新しいパケットバージョンをしなければならないと言い足します。
10.3. New Algorithms
10.3. 新しいアルゴリズム
Section 9 lists the core algorithms that OpenPGP uses. Adding in a new algorithm is usually simple. For example, adding in a new symmetric cipher usually would not need anything more than allocating a constant for that cipher. If that cipher had other than a 64-bit or 128-bit block size, there might need to be additional documentation describing how OpenPGP-CFB mode would be adjusted. Similarly, when DSA was expanded from a maximum of 1024-bit public keys to 3072-bit public keys, the revision of FIPS 186 contained enough information itself to allow implementation. Changes to this document were made mainly for emphasis.
セクション9はOpenPGPが使用するコアアルゴリズムを記載します。 通常、新しいアルゴリズムを加えるのは簡単です。 例えば、新しい左右対称の暗号を加える場合、通常、その暗号のために定数を割り当てるより何も多いものは必要としないでしょう。 64ビットの、または、128ビットのブロック・サイズを除いて、その暗号がそうしたなら、OpenPGP-CFBモードがどう調整されるだろうかを説明する追加のドキュメンテーションは必要とするかもしれないでしょう。 DSAが最大1024年のビットの公開鍵から3072年のビットの公開鍵に広げられたとき、同様に、FIPS186の改正は実装を許容できるくらいの情報自体を含みました。 このドキュメントへの変更は主に強調のために行われました。
10.3.1. Public-Key Algorithms
10.3.1. 公開鍵アルゴリズム
OpenPGP specifies a number of public-key algorithms. This specification creates a registry of public-key algorithm identifiers. The registry includes the algorithm name, its key sizes and parameters, and a reference to the defining specification. The initial values for this registry can be found in Section 9. Adding a new public-key algorithm MUST be done through the IETF CONSENSUS method, as described in [RFC2434].
OpenPGPは多くの公開鍵アルゴリズムを指定します。この仕様は公開鍵アルゴリズム識別子の登録を作成します。 登録は定義仕様のアルゴリズム名、主要なサイズ、パラメタ、および指示するものを含んでいます。 セクション9でこの登録への初期の値を見つけることができます。 [RFC2434]で説明されるようにIETF CONSENSUSメソッドで新しい公開鍵アルゴリズムをしなければならないと言い足します。
Callas, et al Standards Track [Page 66] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[66ページ]RFC4880OpenPGP Message Format2007年11月
10.3.2. Symmetric-Key Algorithms
10.3.2. 対称鍵アルゴリズム
OpenPGP specifies a number of symmetric-key algorithms. This specification creates a registry of symmetric-key algorithm identifiers. The registry includes the algorithm name, its key sizes and block size, and a reference to the defining specification. The initial values for this registry can be found in Section 9. Adding a new symmetric-key algorithm MUST be done through the IETF CONSENSUS method, as described in [RFC2434].
OpenPGPは多くの対称鍵アルゴリズムを指定します。この仕様は対称鍵アルゴリズム識別子の登録を作成します。 登録は定義仕様のアルゴリズム名、主要なサイズ、ブロック・サイズ、および指示するものを含んでいます。 セクション9でこの登録への初期の値を見つけることができます。 [RFC2434]で説明されるようにIETF CONSENSUSメソッドで新しい対称鍵アルゴリズムをしなければならないと言い足します。
10.3.3. Hash Algorithms
10.3.3. ハッシュアルゴリズム
OpenPGP specifies a number of hash algorithms. This specification creates a registry of hash algorithm identifiers. The registry includes the algorithm name, a text representation of that name, its block size, an OID hash prefix, and a reference to the defining specification. The initial values for this registry can be found in Section 9 for the algorithm identifiers and text names, and Section 5.2.2 for the OIDs and expanded signature prefixes. Adding a new hash algorithm MUST be done through the IETF CONSENSUS method, as described in [RFC2434].
OpenPGPは多くのハッシュアルゴリズムを指定します。この仕様はハッシュアルゴリズム識別子の登録を作成します。 登録はアルゴリズム名、その名前のテキスト表現、ブロック・サイズ、OIDハッシュ接頭語、および定義仕様の指示するものを含んでいます。 セクション9でアルゴリズム識別子、原文名、およびセクション5.2.2に関してOIDsと拡張署名接頭語に関してこの登録への初期の値を見つけることができます。 [RFC2434]で説明されるようにIETF CONSENSUSメソッドで新しいハッシュアルゴリズムをしなければならないと言い足します。
10.3.4. Compression Algorithms
10.3.4. 圧縮アルゴリズム
OpenPGP specifies a number of compression algorithms. This specification creates a registry of compression algorithm identifiers. The registry includes the algorithm name and a reference to the defining specification. The initial values for this registry can be found in Section 9.3. Adding a new compression key algorithm MUST be done through the IETF CONSENSUS method, as described in [RFC2434].
OpenPGPは多くの圧縮アルゴリズムを指定します。この仕様は圧縮アルゴリズム識別子の登録を作成します。 登録はアルゴリズム名と定義仕様の指示するものを含んでいます。 セクション9.3でこの登録への初期の値を見つけることができます。 [RFC2434]で説明されるようにIETF CONSENSUSメソッドで新しい圧縮主要なアルゴリズムをしなければならないと言い足します。
11. Packet Composition
11. パケット構成
OpenPGP packets are assembled into sequences in order to create messages and to transfer keys. Not all possible packet sequences are meaningful and correct. This section describes the rules for how packets should be placed into sequences.
OpenPGPパケットは、メッセージを作成して、キーを移すために系列に組み立てられます。 すべての可能なパケット系列が、どんな重要であって、正しいというわけではありません。 このセクションは、パケットがどう系列に置かれるべきであるかために規則について説明します。
11.1. Transferable Public Keys
11.1. 移転可能な公開鍵
OpenPGP users may transfer public keys. The essential elements of a transferable public key are as follows:
OpenPGPユーザは公開鍵を移すかもしれません。 移転可能な公開鍵の必須元素は以下の通りです:
- One Public-Key packet
- 1つのPublic主要なパケット
- Zero or more revocation signatures
- ゼロか、より多くの取消し署名
Callas, et al Standards Track [Page 67] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[67ページ]RFC4880OpenPGP Message Format2007年11月
- One or more User ID packets
- 1つ以上のUser IDパケット
- After each User ID packet, zero or more Signature packets
(certifications)
- それぞれのUser IDパケット、ゼロまたは、より多くのSignatureパケットの後に(証明)
- Zero or more User Attribute packets
- ゼロか、より多くのUser Attributeパケット
- After each User Attribute packet, zero or more Signature packets
(certifications)
- それぞれのUser Attributeパケット、ゼロまたは、より多くのSignatureパケットの後に(証明)
- Zero or more Subkey packets
- ゼロか、より多くのSubkeyパケット
- After each Subkey packet, one Signature packet, plus optionally a
revocation
- それぞれのSubkeyパケット、1つのSignatureパケットの後と任意に、取消し
The Public-Key packet occurs first. Each of the following User ID packets provides the identity of the owner of this public key. If there are multiple User ID packets, this corresponds to multiple means of identifying the same unique individual user; for example, a user may have more than one email address, and construct a User ID for each one.
Public主要なパケットは最初に、起こります。 それぞれの以下のUser IDパケットはこの公開鍵の所有者のアイデンティティを提供します。 複数のUser IDパケットがあれば、これは同じユニークな個々のユーザを特定する複数の手段に対応しています。 例えば、ユーザは、1つ以上のEメールアドレスを持って、それぞれのためにUser IDを組み立てるかもしれません。
Immediately following each User ID packet, there are zero or more Signature packets. Each Signature packet is calculated on the immediately preceding User ID packet and the initial Public-Key packet. The signature serves to certify the corresponding public key and User ID. In effect, the signer is testifying to his or her belief that this public key belongs to the user identified by this User ID.
すぐにそれぞれのUser IDパケットに続いて、ゼロか、より多くのSignatureパケットがあります。 それぞれのSignatureパケットはすぐに前のUser IDパケットと初期のPublic主要なパケットの上で計算されます。 署名は、対応する公開鍵とUser IDを公認するのに役立ちます。 事実上、署名者はこの公開鍵がこのUser IDによって特定されたユーザのものであるというその人の信念に証言しています。
Within the same section as the User ID packets, there are zero or more User Attribute packets. Like the User ID packets, a User Attribute packet is followed by zero or more Signature packets calculated on the immediately preceding User Attribute packet and the initial Public-Key packet.
User IDパケットと同じセクションの中に、ゼロか、より多くのUser Attributeパケットがあります。 User IDパケットのように、ゼロがUser Attributeパケットのあとに続いているか、または、より多くのSignatureパケットがすぐに前のUser Attributeパケットと初期のPublic主要なパケットを当てにしました。
User Attribute packets and User ID packets may be freely intermixed in this section, so long as the signatures that follow them are maintained on the proper User Attribute or User ID packet.
このセクションで自由にユーザAttributeパケットとUser IDパケットを混ぜるかもしれません、それらに続く署名が適切なUser AttributeかUser IDパケットの上で維持される限り。
After the User ID packet or Attribute packet, there may be zero or more Subkey packets. In general, subkeys are provided in cases where the top-level public key is a signature-only key. However, any V4 key may have subkeys, and the subkeys may be encryption-only keys, signature-only keys, or general-purpose keys. V3 keys MUST NOT have subkeys.
User IDパケットかAttributeパケットの後に、ゼロか、より多くのSubkeyパケットがあるかもしれません。 一般に、トップレベル公開鍵が署名だけキーであるケースの中にサブキーを提供します。 サブキーは、しかしながら、どんなV4キーにも、サブキーがあるかもしれなくて、暗号化だけキー、署名だけキー、または汎用キーであるかもしれません。 V3キーには、サブキーがあってはいけません。
Callas, et al Standards Track [Page 68] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[68ページ]RFC4880OpenPGP Message Format2007年11月
Each Subkey packet MUST be followed by one Signature packet, which should be a subkey binding signature issued by the top-level key. For subkeys that can issue signatures, the subkey binding signature MUST contain an Embedded Signature subpacket with a primary key binding signature (0x19) issued by the subkey on the top-level key.
1つのSignatureパケットがそれぞれのSubkeyパケットのあとに続かなければなりません(トップレベルキーによって発行されたサブキーの拘束力がある署名であるべきです)。 署名を発行できるサブキーに関しては、サブキーの拘束力がある署名は主キーの拘束力がある署名(0×19)がトップレベルキーの上のサブキーによって発行されているEmbedded Signature subpacketを含まなければなりません。
Subkey and Key packets may each be followed by a revocation Signature packet to indicate that the key is revoked. Revocation signatures are only accepted if they are issued by the key itself, or by a key that is authorized to issue revocations via a Revocation Key subpacket in a self-signature by the top-level key.
取消しSignatureパケットはそれぞれサブキーとKeyパケットのあとに続いて、キーが取り消されるのを示すかもしれません。 キー自体、または自己署名におけるRevocation Key subpacketを通してトップレベルキーで取消しを発行するのが認可されるキーでそれらを発行する場合にだけ、取消し署名を受け入れます。
Transferable public-key packet sequences may be concatenated to allow transferring multiple public keys in one operation.
移転可能な公開鍵パケット系列は、一挙に複数の公開鍵を移すのを許容するために連結されるかもしれません。
11.2. Transferable Secret Keys
11.2. 移転可能な秘密鍵
OpenPGP users may transfer secret keys. The format of a transferable secret key is the same as a transferable public key except that secret-key and secret-subkey packets are used instead of the public key and public-subkey packets. Implementations SHOULD include self- signatures on any user IDs and subkeys, as this allows for a complete public key to be automatically extracted from the transferable secret key. Implementations MAY choose to omit the self-signatures, especially if a transferable public key accompanies the transferable secret key.
OpenPGPユーザは秘密鍵を移すかもしれません。 秘密鍵と秘密のサブキーパケットが公開鍵と公共のサブキーパケットの代わりに使用されるのを除いて、移転可能な秘密鍵の形式は移転可能な公開鍵と同じです。 実装SHOULDはどんなユーザIDとサブキーにおける自己署名を含んでいます、これが、完全な公開鍵が移転可能な秘密鍵から自動的に抽出されるのを許容するように。 特に移転可能な公開鍵が移転可能な秘密鍵に伴うなら、実装は、自己署名を省略するのを選ぶかもしれません。
11.3. OpenPGP Messages
11.3. OpenPGPメッセージ
An OpenPGP message is a packet or sequence of packets that corresponds to the following grammatical rules (comma represents sequential composition, and vertical bar separates alternatives):
OpenPGPメッセージは、以下の文法規則に対応するパケットのパケットか系列(コンマは連続した構成を表します、そして、縦棒は代替手段を切り離す)です:
OpenPGP Message :- Encrypted Message | Signed Message |
Compressed Message | Literal Message.
OpenPGPメッセージ:-暗号化メッセージ| メッセージであると署名されます。| 圧縮されたメッセージ| 文字通りのメッセージ。
Compressed Message :- Compressed Data Packet.
圧縮されたメッセージ:-はデータ・パケットを圧縮しました。
Literal Message :- Literal Data Packet.
文字通りのメッセージ:-文字通りのデータ・パケット。
ESK :- Public-Key Encrypted Session Key Packet |
Symmetric-Key Encrypted Session Key Packet.
ESK:-公開鍵はセッションの主要なパケットを暗号化しました。| 対称鍵はセッションの主要なパケットを暗号化しました。
ESK Sequence :- ESK | ESK Sequence, ESK.
ESK系列:-ESK| ESK系列、ESK。
Encrypted Data :- Symmetrically Encrypted Data Packet |
Symmetrically Encrypted Integrity Protected Data Packet
暗号化されたデータ:-は対称的にデータ・パケットを暗号化しました。| 対称的に暗号化された保全はデータ・パケットを保護しました。
Callas, et al Standards Track [Page 69] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[69ページ]RFC4880OpenPGP Message Format2007年11月
Encrypted Message :- Encrypted Data | ESK Sequence, Encrypted Data.
暗号化メッセージ:-はデータを暗号化しました。| ESK系列、暗号化されたデータ。
One-Pass Signed Message :- One-Pass Signature Packet,
OpenPGP Message, Corresponding Signature Packet.
1パスが、メッセージの:-の1パスの署名パケット、OpenPGPメッセージが対応する署名パケットであると署名しました。
Signed Message :- Signature Packet, OpenPGP Message |
One-Pass Signed Message.
メッセージ:-署名パケット、OpenPGPメッセージであると署名されます。| 1パスがメッセージに署名しました。
In addition, decrypting a Symmetrically Encrypted Data packet or a Symmetrically Encrypted Integrity Protected Data packet as well as decompressing a Compressed Data packet must yield a valid OpenPGP Message.
さらに、Symmetrically Encrypted DataパケットかSymmetrically Encrypted Integrity Protected Dataパケットを解読して、Compressed Dataパケットを減圧すると、有効なOpenPGP Messageはもたらされなければなりません。
11.4. Detached Signatures
11.4. 離れている署名
Some OpenPGP applications use so-called "detached signatures". For example, a program bundle may contain a file, and with it a second file that is a detached signature of the first file. These detached signatures are simply a Signature packet stored separately from the data for which they are a signature.
いくつかのOpenPGPアプリケーションがいわゆる「離れている署名」を使用します。 例えば、プログラムバンドルはファイル、およびそれによる最初のファイルの離れている署名である2番目のファイルを含むかもしれません。 これらの離れている署名は単に別々にそれらが署名であるデータから保存されたSignatureパケットです。
12. Enhanced Key Formats
12. 高められた主要な形式
12.1. Key Structures
12.1. 主要な構造
The format of an OpenPGP V3 key is as follows. Entries in square brackets are optional and ellipses indicate repetition.
OpenPGP V3キーの形式は以下の通りです。 角括弧におけるエントリーは任意です、そして、楕円は反復を示します。
RSA Public Key
[Revocation Self Signature]
User ID [Signature ...]
[User ID [Signature ...] ...]
RSA公開鍵[取消し自己署名]ユーザID[署名…] [ユーザID[署名…]]
Each signature certifies the RSA public key and the preceding User ID. The RSA public key can have many User IDs and each User ID can have many signatures. V3 keys are deprecated. Implementations MUST NOT generate new V3 keys, but MAY continue to use existing ones.
各署名はRSA公開鍵と前のUser IDを公認します。 RSA公開鍵は多くのUser IDを持つことができます、そして、それぞれのUser IDは多くの署名を持つことができます。 V3キーは推奨しないです。 実装は、新しいV3キーを生成してはいけませんが、既存のものを使用し続けるかもしれません。
The format of an OpenPGP V4 key that uses multiple public keys is similar except that the other keys are added to the end as "subkeys" of the primary key.
他のキーが主キーの「サブキー」として終わりに加えられるのを除いて、複数の公開鍵を使用するOpenPGP V4キーの形式は同様です。
Callas, et al Standards Track [Page 70] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[70ページ]RFC4880OpenPGP Message Format2007年11月
Primary-Key
[Revocation Self Signature]
[Direct Key Signature...]
User ID [Signature ...]
[User ID [Signature ...] ...]
[User Attribute [Signature ...] ...]
[[Subkey [Binding-Signature-Revocation]
Primary-Key-Binding-Signature] ...]
主キー[取消し自己署名][ダイレクト調号…] ユーザID[署名…] [ユーザID[署名…]] [ユーザ属性[署名…]] [[サブキー[拘束力がある署名取消し]のプライマリ主要な拘束力がある署名]]
A subkey always has a single signature after it that is issued using the primary key to tie the two keys together. This binding signature may be in either V3 or V4 format, but SHOULD be V4. Subkeys that can issue signatures MUST have a V4 binding signature due to the REQUIRED embedded primary key binding signature.
サブキーには、それの後の2個のキーを結びつけるのに主キーを使用することで発行される単記署名がいつもあります。 この拘束力がある署名はV3かしかし、V4形式、SHOULDのどちらかにあるかもしれません。V4になってください。 署名を発行できるサブキーはREQUIREDの埋め込まれた主キー拘束力がある署名によるV4の拘束力がある署名を持たなければなりません。
In the above diagram, if the binding signature of a subkey has been revoked, the revoked key may be removed, leaving only one key.
上のダイヤグラムで、サブキーの拘束力がある署名が取り消されたなら、取り消されたキーは取り外されるかもしれません、1個のキーだけを残して。
In a V4 key, the primary key MUST be a key capable of certification. The subkeys may be keys of any other type. There may be other constructions of V4 keys, too. For example, there may be a single- key RSA key in V4 format, a DSA primary key with an RSA encryption key, or RSA primary key with an Elgamal subkey, etc.
V4キーでは、主キーは証明ができるキーであるに違いありません。 サブキーはいかなる他のタイプのキーであるかもしれません。 V4キーについても他の構造があるかもしれません。 例えば、V4形式で主要な独身の主要なRSA、RSA暗号化キーがあるDSA主キー、またはElgamalサブキーなどがあるRSA主キーがあるかもしれません。
It is also possible to have a signature-only subkey. This permits a primary key that collects certifications (key signatures), but is used only for certifying subkeys that are used for encryption and signatures.
また、署名だけサブキーを持っているのも可能です。 これは、証明(調号)を集める主キーを可能にしますが、暗号化と署名に使用されるサブキーを公認するのにだけ使用されます。
12.2. Key IDs and Fingerprints
12.2. 主要なIDと指紋
For a V3 key, the eight-octet Key ID consists of the low 64 bits of the public modulus of the RSA key.
V3キーに関しては、8八重奏のKey IDはRSAキーの公共の係数の低64ビットから成ります。
The fingerprint of a V3 key is formed by hashing the body (but not the two-octet length) of the MPIs that form the key material (public modulus n, followed by exponent e) with MD5. Note that both V3 keys and MD5 are deprecated.
V3キーの指紋は、MD5と共に主要な材料(解説者eによって従われた公共の係数n)を形成するMPIsのボディー(しかし、2八重奏の長さでない)を論じ尽くすことによって、形成されます。 V3キーとMD5の両方が推奨しないことに注意してください。
A V4 fingerprint is the 160-bit SHA-1 hash of the octet 0x99, followed by the two-octet packet length, followed by the entire Public-Key packet starting with the version field. The Key ID is the low-order 64 bits of the fingerprint. Here are the fields of the hash material, with the example of a DSA key:
V4指紋は2八重奏のパケット長があとに続いたバージョン野原から始まる全体のPublic主要なパケットがあとに続いた八重奏0x99の160ビットのSHA-1ハッシュです。 Key IDは指紋の下位の64ビットです。 ここに、ハッシュの材料の分野がDSAキーに関する例と共にあります:
a.1) 0x99 (1 octet)
a.1) 0×99(1つの八重奏)
a.2) high-order length octet of (b)-(e) (1 octet)
a.2) (b)--(e)の高位長さの八重奏 (1つの八重奏)
Callas, et al Standards Track [Page 71] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[71ページ]RFC4880OpenPGP Message Format2007年11月
a.3) low-order length octet of (b)-(e) (1 octet)
a.3) (b)--(e)の下位の長さの八重奏 (1つの八重奏)
b) version number = 4 (1 octet);
4(1つの八重奏)のb)バージョン番号=。
c) timestamp of key creation (4 octets);
主要な作成(4つの八重奏)に関するc)タイムスタンプ。
d) algorithm (1 octet): 17 = DSA (example);
d)アルゴリズム(1つの八重奏): 17はDSA(例)と等しいです。
e) Algorithm-specific fields.
e) アルゴリズム特有の分野。
Algorithm-Specific Fields for DSA keys (example):
DSAキー(例)のためのアルゴリズム特有のフィールズ:
e.1) MPI of DSA prime p;
e.1) DSA第1pのMPI。
e.2) MPI of DSA group order q (q is a prime divisor of p-1);
e.2) DSA共同注文q(qはp-1の主要な除数です)のMPI。
e.3) MPI of DSA group generator g;
e.3) DSAグループジェネレータgのMPI。
e.4) MPI of DSA public-key value y (= g**x mod p where x is secret).
e.4) DSA公開鍵価値y(xが秘密であるg**xモッズpと等しいです)のMPI。
Note that it is possible for there to be collisions of Key IDs -- two different keys with the same Key ID. Note that there is a much smaller, but still non-zero, probability that two different keys have the same fingerprint.
そこに、Key IDの衝突であることが可能であることに注意してください--同じKey IDがある2個の異なったキー。 2個の異なったキーには同じ指紋があるというはるかに小さい、しかし、まだ非ゼロの確率があることに注意してください。
Also note that if V3 and V4 format keys share the same RSA key material, they will have different Key IDs as well as different fingerprints.
また、V3とV4形式キーが同じRSAの主要な材料を共有すると、それらには異なった指紋と同様に異なったKey IDがあることに注意してください。
Finally, the Key ID and fingerprint of a subkey are calculated in the same way as for a primary key, including the 0x99 as the first octet (even though this is not a valid packet ID for a public subkey).
最終的に、同様に、サブキーのKey IDと指紋は主キーのように計算されます、最初の八重奏として0×99を含んでいて(これが公共のサブキーのための有効なパケットIDではありませんが)。
13. Notes on Algorithms
13. アルゴリズムに関する注
13.1. PKCS#1 Encoding in OpenPGP
13.1. OpenPGPでのPKCS#1コード化
This standard makes use of the PKCS#1 functions EME-PKCS1-v1_5 and EMSA-PKCS1-v1_5. However, the calling conventions of these functions has changed in the past. To avoid potential confusion and interoperability problems, we are including local copies in this document, adapted from those in PKCS#1 v2.1 [RFC3447]. RFC 3447 should be treated as the ultimate authority on PKCS#1 for OpenPGP. Nonetheless, we believe that there is value in having a self- contained document that avoids problems in the future with needed changes in the conventions.
この規格はPKCS#1機能EME-PKCS1-v1_5とEMSA-PKCS1-v1_5を利用します。 しかしながら、これらの機能の呼び出し規則は過去に変化しました。 潜在的混乱と相互運用性問題を避けるために、私たちは本書では地方のコピーを入れています、PKCS#1v2.1[RFC3447]のそれらから、適合しています。 RFC3447はOpenPGPのためにPKCS#1で最高権威として扱われるべきです。 それにもかかわらず、私たちは、将来コンベンションにおける必要な変化で問題を避ける自己の含まれたドキュメントを持つのにおいて値があると信じています。
Callas, et al Standards Track [Page 72] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[72ページ]RFC4880OpenPGP Message Format2007年11月
13.1.1. EME-PKCS1-v1_5-ENCODE
13.1.1. EME-PKCS1-v1_5エンコード
Input:
以下を入力してください。
k = the length in octets of the key modulus
主要な係数の八重奏におけるk=長さ
M = message to be encoded, an octet string of length mLen, where
mLen <= k - 11
Mはコード化されるべきメッセージと等しく、長さのmLenの八重奏ストリングでありどこmLen<はkと等しいか--、11
Output:
出力:
EM = encoded message, an octet string of length k
EM=はメッセージ、長さkの八重奏ストリングをコード化しました。
Error: "message too long"
誤り: 「あまりに長い間、通信してください」
1. Length checking: If mLen > k - 11, output "message too long" and
stop.
1. 長さの照合: --mLen>kであるなら11、出力は、「あまりに長い間、通信し」て、止まります。
2. Generate an octet string PS of length k - mLen - 3 consisting of
pseudo-randomly generated nonzero octets. The length of PS will
be at least eight octets.
2. 生成する、八重奏が長さkのPS--mLen--3の成ることを結ぶ、疑似である、無作為である、発生している非零八重奏。 PSの長さは少なくとも8つの八重奏になるでしょう。
3. Concatenate PS, the message M, and other padding to form an
encoded message EM of length k octets as
3. 長さのk八重奏のコード化されたメッセージEMを形成するためにそっと歩くPS、メッセージM、およびもう片方を連結します。
EM = 0x00 || 0x02 || PS || 0x00 || M.
EM=0x00|| 0×02|| PS|| 0×00|| M。
4. Output EM.
4. EMを出力してください。
13.1.2. EME-PKCS1-v1_5-DECODE
13.1.2. EME-PKCS1-v1_5、-解読してください。
Input:
以下を入力してください。
EM = encoded message, an octet string
EM=はメッセージ、八重奏ストリングをコード化しました。
Output:
出力:
M = message, an octet string
Mはメッセージ、八重奏ストリングと等しいです。
Error: "decryption error"
誤り: 「復号化誤り」
To decode an EME-PKCS1_v1_5 message, separate the encoded message EM into an octet string PS consisting of nonzero octets and a message M as follows
EME-PKCS1_v1_5メッセージを解読するには、八重奏へのEMが非零八重奏と以下のメッセージMから成るPSを結ぶというコード化されたメッセージを切り離してください。
EM = 0x00 || 0x02 || PS || 0x00 || M.
EM=0x00|| 0×02|| PS|| 0×00|| M。
Callas, et al Standards Track [Page 73] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[73ページ]RFC4880OpenPGP Message Format2007年11月
If the first octet of EM does not have hexadecimal value 0x00, if the second octet of EM does not have hexadecimal value 0x02, if there is no octet with hexadecimal value 0x00 to separate PS from M, or if the length of PS is less than 8 octets, output "decryption error" and stop. See also the security note in Section 14 regarding differences in reporting between a decryption error and a padding error.
EMの2番目の八重奏に16進値0x02がないならEMの最初の八重奏で16進値0x00がないか、MとPSを切り離すために16進値0x00がある八重奏が全くないか、またはPSの長さが8つ未満の八重奏であるなら、「復号化誤り」を出力してください、そして、止まってください。 また、セクション14で復号化誤りと詰め物誤りの間で報告する違いに関してセキュリティ紙幣を見てください。
13.1.3. EMSA-PKCS1-v1_5
13.1.3. EMSA-PKCS1-v1_5
This encoding method is deterministic and only has an encoding operation.
このコード化メソッドは、決定論的であり、コード化作業を持っているだけです。
Option:
オプション:
Hash - a hash function in which hLen denotes the length in octets of
the hash function output
ハッシュ--hLenがハッシュ関数出力の八重奏における長さを指示するハッシュ関数
Input:
以下を入力してください。
M = message to be encoded
Mはコード化されるべきメッセージと等しいです。
mL = intended length in octets of the encoded message, at least tLen
+ 11, where tLen is the octet length of the DER encoding T of a
certain value computed during the encoding operation
mLはコード化されたメッセージの八重奏における意図している長さと等しいです、少なくともtLen+11、tLenがコード化作業の間に計算されたある値のTをコード化するDERの八重奏の長さであるところで
Output:
出力:
EM = encoded message, an octet string of length emLen
EM=はメッセージ、長さのemLenの八重奏ストリングをコード化しました。
Errors: "message too long"; "intended encoded message length too short"
誤り: 「あまりに長い間、通信してください」。 「コード化されていた状態で意図して、長さをあまりに簡潔に通信させてください」
Steps:
以下のステップ:
1. Apply the hash function to the message M to produce a hash value
H:
1. ハッシュ値Hを生産するメッセージMにハッシュ関数を適用してください:
H = Hash(M).
Hはハッシュ(M)と等しいです。
If the hash function outputs "message too long," output "message
too long" and stop.
ハッシュ関数出力が「あまりに長い間、通信する」なら、「あまりに長い間、通信してください」、出力されて、止まってください。
2. Using the list in Section 5.2.2, produce an ASN.1 DER value for
the hash function used. Let T be the full hash prefix from
Section 5.2.2, and let tLen be the length in octets of T.
2. セクション5.2.2にリストを使用して、使用されるハッシュ関数のためにASN.1DER価値を生産してください。 セクション5.2.2からTが完全なハッシュ接頭語であることをさせてください、そして、tLenがTの八重奏で長さであることをさせてください。
3. If emLen < tLen + 11, output "intended encoded message length
too short" and stop.
3. emLen<tLen+11、出力が「あまりに急にコード化されたメッセージ長を意図し」て、止まるなら。
Callas, et al Standards Track [Page 74] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[74ページ]RFC4880OpenPGP Message Format2007年11月
4. Generate an octet string PS consisting of emLen - tLen - 3
octets with hexadecimal value 0xFF. The length of PS will be at
least 8 octets.
4. 八重奏ストリングがemLen--tLen--16進価値の0xFFとの3つの八重奏から成るPSであると生成してください。 PSの長さは少なくとも8つの八重奏になるでしょう。
5. Concatenate PS, the hash prefix T, and other padding to form the
encoded message EM as
5. コード化がEMを通信させるフォームにそっと歩くPS、ハッシュ接頭語T、およびもう片方を連結してください。
EM = 0x00 || 0x01 || PS || 0x00 || T.
EM=0x00|| 0×01|| PS|| 0×00|| T。
6. Output EM.
6. EMを出力してください。
13.2. Symmetric Algorithm Preferences
13.2. 左右対称のアルゴリズム好み
The symmetric algorithm preference is an ordered list of algorithms that the keyholder accepts. Since it is found on a self-signature, it is possible that a keyholder may have multiple, different preferences. For example, Alice may have TripleDES only specified for "alice@work.com" but CAST5, Blowfish, and TripleDES specified for "alice@home.org". Note that it is also possible for preferences to be in a subkey's binding signature.
左右対称のアルゴリズム好みはkeyholderが受け入れるアルゴリズムの規則正しいリストです。 それが自己署名に見つけられるので、keyholderには複数の、そして、異なった好みがあるのは、可能です。 例えば、アリスは" alice@work.com "にTripleDESを指定させるだけであるかもしれませんが、CAST5、フグ、およびTripleDESは" alice@home.org "に指定しました。 また、好みがサブキーの拘束力がある署名中であるのも、可能であることに注意してください。
Since TripleDES is the MUST-implement algorithm, if it is not explicitly in the list, it is tacitly at the end. However, it is good form to place it there explicitly. Note also that if an implementation does not implement the preference, then it is implicitly a TripleDES-only implementation.
リストでは、明らかでなく、それは暗にそうです。以来TripleDESがそうである、-、道具、アルゴリズム、それがそう、終わりにそうしなければなりません。 しかしながら、それは明らかにそれをそこに置くちゃんとした行儀作法です。 また、実装が好みを実装しないならそれがそれとなくそうであることに注意してください。TripleDESだけ実装。
An implementation MUST NOT use a symmetric algorithm that is not in the recipient's preference list. When encrypting to more than one recipient, the implementation finds a suitable algorithm by taking the intersection of the preferences of the recipients. Note that the MUST-implement algorithm, TripleDES, ensures that the intersection is not null. The implementation may use any mechanism to pick an algorithm in the intersection.
実装は受取人の好みのリストにない左右対称のアルゴリズムを使用してはいけません。 1人以上の受取人に暗号化するとき、実装は、受取人の好みの交差点を取ることによって、適当なアルゴリズムを見つけます。 それに注意してください、-、道具、アルゴリズム(TripleDES)は交差点が確実にヌルにならないようにしなければなりません。 実装は、交差点でアルゴリズムを選ぶのにどんなメカニズムも使用するかもしれません。
If an implementation can decrypt a message that a keyholder doesn't have in their preferences, the implementation SHOULD decrypt the message anyway, but MUST warn the keyholder that the protocol has been violated. For example, suppose that Alice, above, has software that implements all algorithms in this specification. Nonetheless, she prefers subsets for work or home. If she is sent a message encrypted with IDEA, which is not in her preferences, the software warns her that someone sent her an IDEA-encrypted message, but it would ideally decrypt it anyway.
実装がメッセージを解読することができるなら、keyholderが彼らの好み、実装でSHOULDを持っていないのが、とにかくメッセージを解読しますが、プロトコルに違反してあるとkeyholderに警告しなければなりません。 例えば、アリスがこの仕様に上にすべてのアルゴリズムを実装するソフトウェアを持っていると仮定してください。 それにもかかわらず、彼女は仕事かホームとして部分集合を好みます。 彼女の好み中でないIDEAと共に暗号化されたメッセージを彼女に送るなら、ソフトウェアは、だれかがIDEA-暗号化メッセージを彼女に送ったと彼女に警告しますが、それは理想的にとにかくそれを解読するでしょう。
Callas, et al Standards Track [Page 75] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[75ページ]RFC4880OpenPGP Message Format2007年11月
13.3. Other Algorithm Preferences
13.3. 他のアルゴリズム好み
Other algorithm preferences work similarly to the symmetric algorithm preference, in that they specify which algorithms the keyholder accepts. There are two interesting cases that other comments need to be made about, though, the compression preferences and the hash preferences.
keyholderがどのアルゴリズムを受け入れるかを指定するので、他のアルゴリズム好みは同様に左右対称のアルゴリズム好みに取り組みます。 他のコメントがもっとも、ほとんど作られているために必要とする2つのおもしろいケース、圧縮好み、およびハッシュ好みがあります。
13.3.1. Compression Preferences
13.3.1. 圧縮好み
Compression has been an integral part of PGP since its first days. OpenPGP and all previous versions of PGP have offered compression. In this specification, the default is for messages to be compressed, although an implementation is not required to do so. Consequently, the compression preference gives a way for a keyholder to request that messages not be compressed, presumably because they are using a minimal implementation that does not include compression. Additionally, this gives a keyholder a way to state that it can support alternate algorithms.
圧縮は初日以来のPGPの不可欠の部分です。 OpenPGPとPGPのすべての旧バージョンが圧縮を提供しました。 この仕様には、実装はそうするのに必要ではありませんが、デフォルトが圧縮されるべきメッセージのためにあります。 その結果、圧縮好みはkeyholderが、メッセージが圧縮されないよう要求する方法を与えます、おそらく圧縮を含んでいない最小限の器具を使用しているので。 さらに、これは代替のアルゴリズムをサポートすることができると述べる方法をkeyholderに与えます。
Like the algorithm preferences, an implementation MUST NOT use an algorithm that is not in the preference vector. If the preferences are not present, then they are assumed to be [ZIP(1), Uncompressed(0)].
アルゴリズム好みのように、実装は好みのベクトルにはないアルゴリズムを使用してはいけません。 好みが存在していないなら、それらは想定されます。[ZIP(1)、Uncompressed(0)]。
Additionally, an implementation MUST implement this preference to the degree of recognizing when to send an uncompressed message. A robust implementation would satisfy this requirement by looking at the recipient's preference and acting accordingly. A minimal implementation can satisfy this requirement by never generating a compressed message, since all implementations can handle messages that have not been compressed.
さらに、実装は解凍されたメッセージを送るためにいつを認識するか度合いにこの好みを実装しなければなりません。 強健な実装は、受取人の好みを見て、善処することによって、この要件を満たすでしょう。 最小限の器具は圧縮されたメッセージを決して生成しないことによって、この要件を満たすことができます、すべての実装が圧縮されていないメッセージを扱うことができるので。
13.3.2. Hash Algorithm Preferences
13.3.2. ハッシュアルゴリズム好み
Typically, the choice of a hash algorithm is something the signer does, rather than the verifier, because a signer rarely knows who is going to be verifying the signature. This preference, though, allows a protocol based upon digital signatures ease in negotiation.
ハッシュアルゴリズムの選択は通常、署名者が検証よりむしろすることです、署名者が、めったにだれが署名について確かめるかを知らないので。 もっとも、この好みは交渉におけるデジタル署名の容易さに基づくプロトコルを許容します。
Thus, if Alice is authenticating herself to Bob with a signature, it makes sense for her to use a hash algorithm that Bob's software uses. This preference allows Bob to state in his key which algorithms Alice may use.
したがって、アリスが署名のボブに自分を認証しているなら、彼女のために、ボブのソフトウェアが使用するハッシュアルゴリズムを使用するのは理解できます。 この好みで、ボブは、彼のキーにアリスがどのアルゴリズムを使用するかもしれないかを述べることができます。
Since SHA1 is the MUST-implement hash algorithm, if it is not explicitly in the list, it is tacitly at the end. However, it is good form to place it there explicitly.
以来SHA1がそうである、-、道具、明らかに、リストには、それがあるということでないなら、終わりに暗にアルゴリズムを論じ尽くさなければならなくなってください。 しかしながら、それは明らかにそれをそこに置くちゃんとした行儀作法です。
Callas, et al Standards Track [Page 76] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[76ページ]RFC4880OpenPGP Message Format2007年11月
13.4. Plaintext
13.4. 平文
Algorithm 0, "plaintext", may only be used to denote secret keys that are stored in the clear. Implementations MUST NOT use plaintext in Symmetrically Encrypted Data packets; they must use Literal Data packets to encode unencrypted or literal data.
「平文」というアルゴリズム0は、明確に保存される秘密鍵を指示するのに使用されるだけであるかもしれません。 実装はSymmetrically Encrypted Dataパケットで平文を使用してはいけません。 彼らは、非暗号化されたか文字通りのデータをコード化するのにLiteral Dataパケットを使用しなければなりません。
13.5. RSA
13.5. RSA
There are algorithm types for RSA Sign-Only, and RSA Encrypt-Only keys. These types are deprecated. The "key flags" subpacket in a signature is a much better way to express the same idea, and generalizes it to all algorithms. An implementation SHOULD NOT create such a key, but MAY interpret it.
アルゴリズムタイプはRSA Signだけ、およびRSA Encryptだけキーを支持しています。 これらのタイプは推奨しないです。 署名における「主要な旗」「副-パケット」は、同じ考えを表すのにおいてはるかにふさわしい方法であり、すべてのアルゴリズムにそれを一般化します。実装SHOULD NOTはそのようなキーを作成しますが、それを解釈するかもしれません。
An implementation SHOULD NOT implement RSA keys of size less than 1024 bits.
SHOULD NOTが1024ビット未満のサイズのRSAキーであると実装する実装。
13.6. DSA
13.6. DSA
An implementation SHOULD NOT implement DSA keys of size less than 1024 bits. It MUST NOT implement a DSA key with a q size of less than 160 bits. DSA keys MUST also be a multiple of 64 bits, and the q size MUST be a multiple of 8 bits. The Digital Signature Standard (DSS) [FIPS186] specifies that DSA be used in one of the following ways:
SHOULD NOTが1024ビット未満のサイズのDSAキーであると実装する実装。 それは160ビット未満のqサイズのために主要なDSAを実装してはいけません。 また、DSAキーは64ビットの倍数であるに違いありません、そして、qサイズは8ビットの倍数であるに違いありません。 デジタル署名基準(DSS)[FIPS186]は、DSAが以下の方法の1つで使用されると指定します:
* 1024-bit key, 160-bit q, SHA-1, SHA-224, SHA-256, SHA-384, or
SHA-512 hash
* 1024年のビットの主要で、160ビットのq、SHA-1、SHA-224、SHA-256、SHA-384、またはSHA-512ハッシュ
* 2048-bit key, 224-bit q, SHA-224, SHA-256, SHA-384, or SHA-512
hash
* 2048年のビットの主要で、224ビットのq、SHA-224、SHA-256、SHA-384、またはSHA-512ハッシュ
* 2048-bit key, 256-bit q, SHA-256, SHA-384, or SHA-512 hash
* 2048年のビットの主要で、256ビットのq、SHA-256、SHA-384、またはSHA-512ハッシュ
* 3072-bit key, 256-bit q, SHA-256, SHA-384, or SHA-512 hash
* 3072年のビットの主要で、256ビットのq、SHA-256、SHA-384、またはSHA-512ハッシュ
The above key and q size pairs were chosen to best balance the strength of the key with the strength of the hash. Implementations SHOULD use one of the above key and q size pairs when generating DSA keys. If DSS compliance is desired, one of the specified SHA hashes must be used as well. [FIPS186] is the ultimate authority on DSS, and should be consulted for all questions of DSS compliance.
サイズ組が選ばれた上のキーとqはハッシュの強さがあるキーの強さの最善とバランスをとっています。 DSAにキーを生成するとき、実装SHOULDは上のキーとqサイズ組のひとりを使用します。 DSSコンプライアンスが望まれているなら、また、指定されたSHAハッシュの1つを使用しなければなりません。 [FIPS186]は、DSSの上の最高権威であり、DSSコンプライアンスのすべての質問のために相談されるべきです。
Note that earlier versions of this standard only allowed a 160-bit q with no truncation allowed, so earlier implementations may not be able to handle signatures with a different q size or a truncated hash.
以前の実装が異なったqサイズか端が欠けているハッシュで署名を扱うことができないかもしれないように、トランケーションが全く許容されていなくこの規格の以前のバージョンが160ビットのqを許容しただけであることに注意してください。
Callas, et al Standards Track [Page 77] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[77ページ]RFC4880OpenPGP Message Format2007年11月
13.7. Elgamal
13.7. Elgamal
An implementation SHOULD NOT implement Elgamal keys of size less than 1024 bits.
SHOULD NOTが1024ビット未満のサイズのElgamalキーであると実装する実装。
13.8. Reserved Algorithm Numbers
13.8. 予約されたアルゴリズム番号
A number of algorithm IDs have been reserved for algorithms that would be useful to use in an OpenPGP implementation, yet there are issues that prevent an implementer from actually implementing the algorithm. These are marked in Section 9.1, "Public-Key Algorithms", as "reserved for".
多くのアルゴリズムIDがOpenPGP実装に使用するために役に立つアルゴリズムのために予約されましたが、implementerが実際にアルゴリズムを実装するのを防ぐ問題があります。 これらは「予約される」としてセクション9.1、「公開鍵アルゴリズム」でマークされます。
The reserved public-key algorithms, Elliptic Curve (18), ECDSA (19), and X9.42 (21), do not have the necessary parameters, parameter order, or semantics defined.
予約された公開鍵アルゴリズム(Elliptic Curve(18)、ECDSA(19)、およびX9.42(21))には、必要なパラメタ、パラメタオーダー、または定義された意味論がありません。
Previous versions of OpenPGP permitted Elgamal [ELGAMAL] signatures with a public-key identifier of 20. These are no longer permitted. An implementation MUST NOT generate such keys. An implementation MUST NOT generate Elgamal signatures. See [BLEICHENBACHER].
OpenPGPの旧バージョンは20に関する公開鍵識別子でElgamal[ELGAMAL]に署名を可能にしました。 これらはもう受入れられません。 実装はそのようなキーを生成してはいけません。 実装はElgamalに署名を生成してはいけません。 [BLEICHENBACHER]を見てください。
13.9. OpenPGP CFB Mode
13.9. OpenPGP CFBモード
OpenPGP does symmetric encryption using a variant of Cipher Feedback mode (CFB mode). This section describes the procedure it uses in detail. This mode is what is used for Symmetrically Encrypted Data Packets; the mechanism used for encrypting secret-key material is similar, and is described in the sections above.
OpenPGPは、Cipher Feedbackモード(CFBモード)の異形を使用することで左右対称の暗号化をします。 このセクションはそれが詳細に用いる手順について説明します。 このモードはSymmetrically Encrypted Data Packetsに使用されることです。 秘密鍵の材料を暗号化するのに使用されるメカニズムは、同様であり、上のセクションで説明されます。
In the description below, the value BS is the block size in octets of the cipher. Most ciphers have a block size of 8 octets. The AES and Twofish have a block size of 16 octets. Also note that the description below assumes that the IV and CFB arrays start with an index of 1 (unlike the C language, which assumes arrays start with a zero index).
以下での記述では、値のBSは暗号の八重奏でブロック・サイズです。 ほとんどの暗号には、8つの八重奏のブロック・サイズがあります。 AESとTwofishには、16の八重奏のブロック・サイズがあります。 また、以下での記述が、IVとCFB配列が1のインデックスから始まると仮定することに注意してください(C言語と異なって、索引をつけてください)。C言語は、配列がゼロから始まると仮定します。
OpenPGP CFB mode uses an initialization vector (IV) of all zeros, and prefixes the plaintext with BS+2 octets of random data, such that octets BS+1 and BS+2 match octets BS-1 and BS. It does a CFB resynchronization after encrypting those BS+2 octets.
OpenPGP CFBモードは、すべてのゼロの初期化ベクトル(IV)を使用して、無作為のデータのBS+2八重奏がある平文を前に置きます、八重奏BS+1とBS+2が八重奏のBS-1とBSに合うように。 それらのBS+2八重奏を暗号化した後に、それはCFB resynchronizationをします。
Thus, for an algorithm that has a block size of 8 octets (64 bits), the IV is 10 octets long and octets 7 and 8 of the IV are the same as octets 9 and 10. For an algorithm with a block size of 16 octets (128 bits), the IV is 18 octets long, and octets 17 and 18 replicate octets 15 and 16. Those extra two octets are an easy check for a correct key.
したがって、長い間、IVは8つの八重奏(64ビット)のブロック・サイズを持っているアルゴリズムのための10の八重奏です、そして、IVの八重奏7と8は八重奏9と10と同じです。 16の八重奏(128ビット)のブロック・サイズがあるアルゴリズムのために、長い間、IVは18の八重奏です、そして、八重奏17と18は八重奏15と16を模写します。 それらの付加的な2つの八重奏は正しいキーのための簡単なチェックです。
Callas, et al Standards Track [Page 78] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[78ページ]RFC4880OpenPGP Message Format2007年11月
Step by step, here is the procedure:
一歩一歩、ここに、手順があります:
1. The feedback register (FR) is set to the IV, which is all zeros.
1. フィードバック・レジスタ(FR)はIVに設定されます。(それは、すべてゼロです)。
2. FR is encrypted to produce FRE (FR Encrypted). This is the
encryption of an all-zero value.
2. FRは、FRE(FR Encrypted)を生産するために暗号化されます。 これはオールゼロ価値の暗号化です。
3. FRE is xored with the first BS octets of random data prefixed to
the plaintext to produce C[1] through C[BS], the first BS octets
of ciphertext.
3. 無作為のデータの最初のBS八重奏が平文へ前に置かれている状態で、FREは、C[BS](暗号文の最初のBS八重奏)を通してC[1]を生産するためにxoredされます。
4. FR is loaded with C[1] through C[BS].
4. C[BS]を通したC[1]にFRを積みます。
5. FR is encrypted to produce FRE, the encryption of the first BS
octets of ciphertext.
5. FRは、FRE、暗号文の最初のBS八重奏の暗号化を起こすために暗号化されます。
6. The left two octets of FRE get xored with the next two octets of
data that were prefixed to the plaintext. This produces C[BS+1]
and C[BS+2], the next two octets of ciphertext.
6. FREの左の2つの八重奏が平文へ前に置かれたデータの次の2つの八重奏でxoredされます。 これはC[BS+1]とC[BS+2]を生産して、次は暗号文の2つの八重奏です。
7. (The resynchronization step) FR is loaded with C[3] through
C[BS+2].
7. (再同期ステップ) C[BS+2]を通したC[3]にFRを積みます。
8. FR is encrypted to produce FRE.
8. FRは、FREを生産するために暗号化されます。
9. FRE is xored with the first BS octets of the given plaintext, now
that we have finished encrypting the BS+2 octets of prefixed
data. This produces C[BS+3] through C[BS+(BS+2)], the next BS
octets of ciphertext.
9. FREは与えられた平文の最初のBS八重奏でxoredされます、私たちが、前に置かれたデータのBS+2八重奏を暗号化し終えたので。 これはC[BS+(BS+2)]、暗号文の次のBS八重奏でC[BS+3]を生産します。
10. FR is loaded with C[BS+3] to C[BS + (BS+2)] (which is C11-C18 for
an 8-octet block).
10. C[BS+3]からC[BS+(BS+2)](8八重奏のブロックC11-C18である)にFRを積みます。
11. FR is encrypted to produce FRE.
11. FRは、FREを生産するために暗号化されます。
12. FRE is xored with the next BS octets of plaintext, to produce
the next BS octets of ciphertext. These are loaded into FR, and
the process is repeated until the plaintext is used up.
12. FREは平文の次のBS八重奏でxoredされて、暗号文の次のBS八重奏を起こします。 これらはFRにロードされます、そして、平文が使いきられるまで、プロセスは繰り返されます。
13.10. Private or Experimental Parameters
13.10. 個人的であるか実験しているパラメタ
S2K specifiers, Signature subpacket types, user attribute types, image format types, and algorithms described in Section 9 all reserve the range 100 to 110 for private and experimental use. Packet types reserve the range 60 to 63 for private and experimental use. These are intentionally managed with the PRIVATE USE method, as described in [RFC2434].
セクション9で説明されたS2K特許説明書の作成書、Signature subpacketタイプ、ユーザ属性タイプ、画像形式タイプ、およびアルゴリズムはすべて、個人的で実験的な使用のために100〜110に範囲を予約します。 パケットタイプは個人的で実験的な使用のために60〜63に範囲を予約します。 これらは故意に[RFC2434]で説明されるようにPRIVATE USEメソッドで管理されます。
Callas, et al Standards Track [Page 79] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[79ページ]RFC4880OpenPGP Message Format2007年11月
However, implementations need to be careful with these and promote them to full IANA-managed parameters when they grow beyond the original, limited system.
しかしながら、オリジナルの、そして、限られたシステムを超えて成長すると、実装は、これらに注意していて、完全なIANAによって管理されたパラメタにそれらを促進する必要があります。
13.11. Extension of the MDC System
13.11. MDCシステムの拡大
As described in the non-normative explanation in Section 5.13, the MDC system is uniquely unparameterized in OpenPGP. This was an intentional decision to avoid cross-grade attacks. If the MDC system is extended to a stronger hash function, care must be taken to avoid downgrade and cross-grade attacks.
セクション5.13で非標準の説明で説明されるように、MDCシステムはOpenPGPで唯一unparameterizedされます。 これは交差しているグレード攻撃を避けるという意図的な決定でした。 MDCシステムが、より強いハッシュ関数に拡張されるなら、ダウングレードと交差しているグレード攻撃を避けるために注意しなければなりません。
One simple way to do this is to create new packets for a new MDC. For example, instead of the MDC system using packets 18 and 19, a new MDC could use 20 and 21. This has obvious drawbacks (it uses two packet numbers for each new hash function in a space that is limited to a maximum of 60).
これをする1つの簡単な方法は新しいMDCのために新しいパケットを作成することです。 例えば、パケット18と19を使用するMDCシステムの代わりに、新しいMDCは20と21を使用できました。 これには、明らかな欠点があります(それは最大60に制限されるスペースのそれぞれの新しいハッシュ関数の2つのパケット番号を使用します)。
Another simple way to extend the MDC system is to create new versions of packet 18, and reflect this in packet 19. For example, suppose that V2 of packet 18 implicitly used SHA-256. This would require packet 19 to have a length of 32 octets. The change in the version in packet 18 and the size of packet 19 prevent a downgrade attack.
MDCシステムを拡張する別の簡単な方法は、パケット18の新しいバージョンを作成して、パケット19にこれを反映することです。 例えば、パケット18のV2がそれとなくSHA-256を使用したと仮定してください。 これは、パケット19には32の八重奏の長さがあるのを必要とするでしょう。 パケット18のバージョンにおける変化とパケット19のサイズはダウングレード攻撃を防ぎます。
There are two drawbacks to this latter approach. The first is that using the version number of a packet to carry algorithm information is not tidy from a protocol-design standpoint. It is possible that there might be several versions of the MDC system in common use, but this untidiness would reflect untidiness in cryptographic consensus about hash function security. The second is that different versions of packet 19 would have to have unique sizes. If there were two versions each with 256-bit hashes, they could not both have 32-octet packet 19s without admitting the chance of a cross-grade attack.
この後者のアプローチへの2つの欠点があります。 1番目はアルゴリズム情報を運ぶのにパケットのバージョン番号を使用するのがプロトコルデザイン見地からきちんとしていないということです。 共用のMDCシステムのいくつかのバージョンがあるのが、可能ですが、この乱雑さはハッシュ関数セキュリティに関する暗号のコンセンサスに乱雑さを反映するでしょう。 2番目はパケット19の異なった見解にはユニークなサイズがなければならないだろうということです。 それぞれ2つのバージョンが256ビットのハッシュと共にあれば、交差しているグレード攻撃の機会を認めないで、それらはともに32八重奏のパケット19年代を持つことができないでしょうに。
Yet another, complex approach to extend the MDC system would be a hybrid of the two above -- create a new pair of MDC packets that are fully parameterized, and yet protected from downgrade and cross- grade.
しかし、別のもの、MDCシステムを拡張する複雑なアプローチは上の2つのもののハイブリッドでしょう--ダウングレードと十字グレードから完全にparameterizedされますが、保護されるMDCパケットの新しいペアを作成してください。
Any change to the MDC system MUST be done through the IETF CONSENSUS method, as described in [RFC2434].
[RFC2434]で説明されるようにIETF CONSENSUSメソッドでMDCシステムへのどんな変化もしなければなりません。
13.12. Meta-Considerations for Expansion
13.12. 拡張のためのメタ問題
If OpenPGP is extended in a way that is not backwards-compatible, meaning that old implementations will not gracefully handle their
OpenPGPが古い実装が優雅でなくハンドルを望んでいることを意味して、後方に互換性がない方法で広げられる、それら
Callas, et al Standards Track [Page 80] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[80ページ]RFC4880OpenPGP Message Format2007年11月
absence of a new feature, the extension proposal can be declared in the key holder's self-signature as part of the Features signature subpacket.
新機能の欠如、Features署名「副-パケット」の一部として主要な所有者の自己署名で拡大提案を宣言できます。
We cannot state definitively what extensions will not be upwards- compatible, but typically new algorithms are upwards-compatible, whereas new packets are not.
新しいパケットは互換性がありませんが、私たちは、どんな拡大が上向きに互換性がないかを決定的に述べることができませんが、通常新しいアルゴリズムは上向きに互換性があります。
If an extension proposal does not update the Features system, it SHOULD include an explanation of why this is unnecessary. If the proposal contains neither an extension to the Features system nor an explanation of why such an extension is unnecessary, the proposal SHOULD be rejected.
拡大提案はFeaturesシステムをアップデートしないで、それはSHOULDです。不要な状態でなぜに関する説明を含めてくださいか。 提案がFeaturesシステムへの拡大もそのような拡大が不要であり、提案がSHOULDである理由に関する説明も含まないなら、拒絶されてください。
14. Security Considerations
14. セキュリティ問題
* As with any technology involving cryptography, you should check the
current literature to determine if any algorithms used here have
been found to be vulnerable to attack.
* どんな技術の意味ありげな暗号ならも、あなたは、何かここで使用されたアルゴリズムが攻撃するために被害を受け易いのがわかったかどうか決定するために現在の文学をチェックするべきです。
* This specification uses Public-Key Cryptography technologies. It
is assumed that the private key portion of a public-private key
pair is controlled and secured by the proper party or parties.
* この仕様はPublic主要なCryptography技術を使用します。 1公共の秘密鍵組の秘密鍵一部が適切なパーティーかパーティーによって制御されて、保証されると思われます。
* Certain operations in this specification involve the use of random
numbers. An appropriate entropy source should be used to generate
these numbers (see [RFC4086]).
* この仕様に基づく、ある操作は乱数の使用にかかわります。 適切なエントロピーソースは、これらの数を生成するのに使用されるべきです([RFC4086]を見てください)。
* The MD5 hash algorithm has been found to have weaknesses, with
collisions found in a number of cases. MD5 is deprecated for use
in OpenPGP. Implementations MUST NOT generate new signatures using
MD5 as a hash function. They MAY continue to consider old
signatures that used MD5 as valid.
* MD5ハッシュアルゴリズムは衝突が件数で見つけられている弱点を持っているのがわかりました。 OpenPGPにおける使用に、MD5は推奨しないです。 ハッシュ関数としてMD5を使用して、実装は新しい署名を生成してはいけません。 彼らは、MD5を使用した古い署名が有効であるとみなし続けるかもしれません。
* SHA-224 and SHA-384 require the same work as SHA-256 and SHA-512,
respectively. In general, there are few reasons to use them
outside of DSS compatibility. You need a situation where one needs
more security than smaller hashes, but does not want to have the
full 256-bit or 512-bit data length.
* SHA-224とSHA-384はそれぞれSHA-256とSHA-512と同じ作業を必要とします。 一般に、DSSの互換性の外でそれらを使用する理由がわずかしかありません。 あなたは1つが、より小さいハッシュより多くのセキュリティを必要としますが、完全な256ビットの、または、512ビット・データの長さを必要としない状況を必要とします。
* Many security protocol designers think that it is a bad idea to use
a single key for both privacy (encryption) and integrity
(signatures). In fact, this was one of the motivating forces
behind the V4 key format with separate signature and encryption
keys. If you as an implementer promote dual-use keys, you should
at least be aware of this controversy.
* 多くのセキュリティプロトコルデザイナーが、プライバシー(暗号化)と保全(署名)の両方に単一のキーを使用するのが、悪い考えであると考えます。 事実上、これは別々の署名と暗号化キーがあるV4の主要な形式の後ろの原動力の1つでした。 implementerとしてのあなたが二元的な使用キーを促進するなら、あなたはこの論争を少なくとも意識しているべきです。
Callas, et al Standards Track [Page 81] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[81ページ]RFC4880OpenPGP Message Format2007年11月
* The DSA algorithm will work with any hash, but is sensitive to the
quality of the hash algorithm. Verifiers should be aware that even
if the signer used a strong hash, an attacker could have modified
the signature to use a weak one. Only signatures using acceptably
strong hash algorithms should be accepted as valid.
* DSAアルゴリズムは、どんなハッシュでも働きますが、ハッシュアルゴリズムの品質に敏感です。 検証は署名者が強いハッシュを使用したとしても、攻撃者が弱いものを使用するように署名を変更したかもしれないのを意識しているべきです。 許容できて強いハッシュアルゴリズムを使用する署名だけが有効であるとして認められるべきです。
* As OpenPGP combines many different asymmetric, symmetric, and hash
algorithms, each with different measures of strength, care should
be taken that the weakest element of an OpenPGP message is still
sufficiently strong for the purpose at hand. While consensus about
the strength of a given algorithm may evolve, NIST Special
Publication 800-57 [SP800-57] recommends the following list of
equivalent strengths:
* 非対称です、左右対称、そして、ハッシュアルゴリズム、それぞれ強さの異なった基準で、注意するべきです。OpenPGPが多くを結合する、相違、OpenPGPメッセージの最も弱い要素は手元の目的のためにまだ十分強いです。 与えられたアルゴリズムの強さに関するコンセンサスは発展するかもしれませんが、NIST Special Publication800-57[SP800-57]は同等な強さの以下のリストを推薦します:
Asymmetric | Hash | Symmetric
key size | size | key size
------------+--------+-----------
1024 160 80
2048 224 112
3072 256 128
7680 384 192
15360 512 256
非対称| ハッシュ| 対称鍵サイズ| サイズ| 主要なサイズ------------+--------+----------- 1024 160 80 2048 224 112 3072 256 128 7680 384 192 15360 512 256
* There is a somewhat-related potential security problem in
signatures. If an attacker can find a message that hashes to the
same hash with a different algorithm, a bogus signature structure
can be constructed that evaluates correctly.
* 署名にはいくらか関連の潜在的警備上の問題があります。 攻撃者がそれが異なったアルゴリズムで同じハッシュに論じ尽くすメッセージを見つけることができるなら、にせの署名構造を構成できます。それは正しく評価します。
For example, suppose Alice DSA signs message M using hash algorithm
H. Suppose that Mallet finds a message M' that has the same hash
value as M with H'. Mallet can then construct a signature block
that verifies as Alice's signature of M' with H'. However, this
would also constitute a weakness in either H or H' or both. Should
this ever occur, a revision will have to be made to this document
to revise the allowed hash algorithms.
'例えば、アリスDSAが'Hと共にMと同じハッシュ値を持っている'メッセージMにハッシュアルゴリズムH.Supposeを使用するMalletが見つけるメッセージMに署名すると仮定してください。 'そして、槌はアリスのMの署名を'H'について確かめる署名欄を構成できます。 'しかしながら、また、これはHかH'か両方のどちらかで弱点を構成するでしょう。 これが起こると、許容ハッシュアルゴリズムを改訂するのを改正をこのドキュメントにしなければならないでしょう。
* If you are building an authentication system, the recipient may
specify a preferred signing algorithm. However, the signer would
be foolish to use a weak algorithm simply because the recipient
requests it.
* あなたが認証システムを構築しているなら、受取人は都合のよい署名アルゴリズムを指定するかもしれません。 しかしながら、署名者は、単に受取人がそれを要求するので弱いアルゴリズムを使用するために愚かでしょう。
* Some of the encryption algorithms mentioned in this document have
been analyzed less than others. For example, although CAST5 is
presently considered strong, it has been analyzed less than
TripleDES. Other algorithms may have other controversies
surrounding them.
* 本書では言及された暗号化アルゴリズムのいくつかが他のものほど分析されていません。 例えば、CAST5が現在強いと考えられますが、それはTripleDESほど分析されていません。 他のアルゴリズムには、それらを囲む他の論争があるかもしれません。
Callas, et al Standards Track [Page 82] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[82ページ]RFC4880OpenPGP Message Format2007年11月
* In late summer 2002, Jallad, Katz, and Schneier published an
interesting attack on the OpenPGP protocol and some of its
implementations [JKS02]. In this attack, the attacker modifies a
message and sends it to a user who then returns the erroneously
decrypted message to the attacker. The attacker is thus using the
user as a random oracle, and can often decrypt the message.
* 夏の終わりに、2002、Jallad、キャッツ、およびシュナイアーはOpenPGPプロトコルに対するおもしろい攻撃と実装[JKS02]のいくつかを発行しました。 この攻撃では、攻撃者は、攻撃者への誤って解読されたメッセージがその時戻るユーザにメッセージを変更して、それを送ります。 攻撃者は、その結果、無作為の神託としてユーザを使用していて、しばしばメッセージを解読することができます。
Compressing data can ameliorate this attack. The incorrectly
decrypted data nearly always decompresses in ways that defeat the
attack. However, this is not a rigorous fix, and leaves open some
small vulnerabilities. For example, if an implementation does not
compress a message before encryption (perhaps because it knows it
was already compressed), then that message is vulnerable. Because
of this happenstance -- that modification attacks can be thwarted
by decompression errors -- an implementation SHOULD treat a
decompression error as a security problem, not merely a data
problem.
データを圧縮すると、この攻撃を改善できます。 不当に解読されたデータは攻撃を破る方法でほとんどいつも減圧されます。 しかしながら、これは、厳しいフィックスでなく、いくつかの小さい脆弱性を戸外に発ちます。 例えば、実装が暗号化の前にメッセージを圧縮しないなら(恐らく既に圧縮されたのを知っているので)、そのメッセージは被害を受け易いです。 減圧誤りによって変更が攻撃されるのを阻まれることができるというこの偶然の出来事のために、実装SHOULDは単にデータ問題ではなく、警備上の問題として減圧誤りを扱います。
This attack can be defeated by the use of Modification Detection,
provided that the implementation does not let the user naively
return the data to the attacker. An implementation MUST treat an
MDC failure as a security problem, not merely a data problem.
Modification Detectionの使用でこの攻撃を破ることができます、ユーザが実装でデータを攻撃者に純真に返すことができなければ。 実装は単にデータ問題ではなく、警備上の問題としてMDCの故障を扱わなければなりません。
In either case, the implementation MAY allow the user access to the
erroneous data, but MUST warn the user as to potential security
problems should that data be returned to the sender.
どちらの場合ではも、実装は、誤ったデータへのアクセスをユーザに許すかもしれませんが、そのデータを送付者に返すなら、潜在的警備上の問題に関してユーザに警告しなければなりません。
While this attack is somewhat obscure, requiring a special set of
circumstances to create it, it is nonetheless quite serious as it
permits someone to trick a user to decrypt a message.
Consequently, it is important that:
この攻撃がいくらか不鮮明である間、それを作成するために特別なセットに事情を要求して、だれかがメッセージを解読するためにユーザをだますことを許可するとき、それはそれにもかかわらず、かなり重大です。 その結果、以下のことは重要です。
1. Implementers treat MDC errors and decompression failures as
security problems.
1. ImplementersはMDC誤りと減圧失敗を警備上の問題として扱います。
2. Implementers implement Modification Detection with all due
speed and encourage its spread.
2. Implementersはすべての当然の速度でModification Detectionを実装して、普及を奨励します。
3. Users migrate to implementations that support Modification
Detection with all due speed.
3. ユーザはすべての当然の速度でModification Detectionをサポートする実装にわたります。
* PKCS#1 has been found to be vulnerable to attacks in which a system
that reports errors in padding differently from errors in
decryption becomes a random oracle that can leak the private key in
mere millions of queries. Implementations must be aware of this
attack and prevent it from happening. The simplest solution is to
report a single error code for all variants of decryption errors so
as not to leak information to an attacker.
* PKCS#1は復号化における誤りと異なってそっと歩く際に誤りを報告するシステムが質問のわずか数百万による秘密鍵を漏らすことができる無作為の神託になる攻撃に被害を受け易いのがわかりました。 実装は、この攻撃を意識していて、それが起こるのを防がなければなりません。 最も簡単なソリューションは攻撃者に情報を漏らさないで、復号化誤りのすべての異形のためにただ一つのエラーコードを報告することです。
Callas, et al Standards Track [Page 83] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[83ページ]RFC4880OpenPGP Message Format2007年11月
* Some technologies mentioned here may be subject to government
control in some countries.
* ここに言及されたいくつかの技術がいくつかの国での公共的支配を受けることがあるかもしれません。
* In winter 2005, Serge Mister and Robert Zuccherato from Entrust
released a paper describing a way that the "quick check" in OpenPGP
CFB mode can be used with a random oracle to decrypt two octets of
every cipher block [MZ05]. They recommend as prevention not using
the quick check at all.
* 2005年冬に、セルジュ氏とロバートZuccheratoはEntrustからあらゆる暗号ブロック[MZ05]の2つの八重奏を解読するのに無作為の神託と共にOpenPGP CFBモードにおける「迅速なチェック」を使用できる方法を述べる論文を排出しました。 彼らは使用ではなく、防止として全く迅速なチェックを推薦します。
Many implementers have taken this advice to heart for any data that
is symmetrically encrypted and for which the session key is
public-key encrypted. In this case, the quick check is not needed
as the public-key encryption of the session key should guarantee
that it is the right session key. In other cases, the
implementation should use the quick check with care.
多くのimplementersが対称的に暗号化されて、セッションキーが暗号化された公開鍵であるどんなデータのためにもこのアドバイスをまじめに受け取りました。 この場合、セッションキーの公開鍵暗号化が、それが右のセッションキーであることを保証するべきであるとき、すばやいチェックが必要ではありません。 他の場合では、実装は慎重に迅速なチェックを使用するべきです。
On the one hand, there is a danger to using it if there is a random
oracle that can leak information to an attacker. In plainer
language, there is a danger to using the quick check if timing
information about the check can be exposed to an attacker,
particularly via an automated service that allows rapidly repeated
queries.
一方では、攻撃者に情報を漏らすことができる無作為の神託があればそれを使用することへの危険があります。 より明瞭な言語には、チェックのタイミング情報を攻撃者に暴露することができるなら迅速なチェックを使用することへの危険があります、特に急速に繰り返された質問を許す自動化されたサービスで。
On the other hand, it is inconvenient to the user to be informed
that they typed in the wrong passphrase only after a petabyte of
data is decrypted. There are many cases in cryptographic
engineering where the implementer must use care and wisdom, and
this is one.
他方では、ユーザにとって、データのペタバイトが解読された後にだけ彼らが間違ったパスフレーズをタイプしたと知らされるのは不便です。 暗号の工学における多くのケースがimplementerが注意と知恵を働かせなければならなくて、これが1であるところにあります。
15. Implementation Nits
15. 実装夜
This section is a collection of comments to help an implementer, particularly with an eye to backward compatibility. Previous implementations of PGP are not OpenPGP compliant. Often the differences are small, but small differences are frequently more vexing than large differences. Thus, this is a non-comprehensive list of potential problems and gotchas for a developer who is trying to be backward-compatible.
このセクションは特に目のimplementerを後方の互換性に助けるコメントの収集です。 PGPの前の実装はOpenPGP対応しません。 しばしば、違いは小さいのですが、小さい違いは頻繁に大きな違いより多くの困らせることです。 したがって、これは互換性があるのを後方の試みている開発者のための潜在的な問題とgotchasに関する非総覧です。
* The IDEA algorithm is patented, and yet it is required for PGP
2.x interoperability. It is also the de-facto preferred
algorithm for a V3 key with a V3 self-signature (or no self-
signature).
* IDEAアルゴリズムは特許をとられますが、それがPGP 2.x相互運用性に必要です。 また、それはV3自己署名(または、自己署名がない)によって主要なV3に、デファクト都合のよいアルゴリズムです。
* When exporting a private key, PGP 2.x generates the header "BEGIN
PGP SECRET KEY BLOCK" instead of "BEGIN PGP PRIVATE KEY BLOCK".
All previous versions ignore the implied data type, and look
directly at the packet data type.
* 秘密鍵をエクスポートするとき、PGP 2.xは「PGP秘密鍵ブロックを始めてください」の代わりに「PGP秘密のキー・ブロックを始めてください」をヘッダーに生成します。 すべての旧バージョンが、暗示しているデータ型を無視して、直接パケットデータ型を見ます。
Callas, et al Standards Track [Page 84] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[84ページ]RFC4880OpenPGP Message Format2007年11月
* PGP 2.0 through 2.5 generated V2 Public-Key packets. These are
identical to the deprecated V3 keys except for the version
number. An implementation MUST NOT generate them and may accept
or reject them as it sees fit. Some older PGP versions generated
V2 PKESK packets (Tag 1) as well. An implementation may accept
or reject V2 PKESK packets as it sees fit, and MUST NOT generate
them.
* PGP2.0〜2.5はV2 Public主要なパケットを生成しました。 これらはバージョン番号以外の推奨しないV3キーと同じです。 実装は、適していると決めるようにそれらをそれらを生成してはいけなくて、受け入れるか、または拒絶するかもしれません。 いくつかの、より古いPGPバージョンが、V2 PKESKパケットがまた、(タグ1)であると生成しました。 実装は、適していると決めるようにV2 PKESKパケットを受け入れるか、または拒絶するかもしれなくて、それらを生成してはいけません。
* PGP 2.6.x will not accept key-material packets with versions
greater than 3.
* バージョンが3よりすばらしい状態でPGP 2.6.xは主要な材料パケットを受け入れないでしょう。
* There are many ways possible for two keys to have the same key
material, but different fingerprints (and thus Key IDs). Perhaps
the most interesting is an RSA key that has been "upgraded" to V4
format, but since a V4 fingerprint is constructed by hashing the
key creation time along with other things, two V4 keys created at
different times, yet with the same key material will have
different fingerprints.
* 2個のキーには同じ主要な物質的な、しかし、異なった指紋(そして、その結果、Key ID)があるのにおいて可能な多くの道があります。 恐らく最もおもしろいのが、V4形式に「アップグレードした」RSAキーですが、V4指紋が他のものに伴う主要な作成時間を論じ尽くすことによって組み立てられるので、V4キーがいろいろな時間にまだ同じ主要な材料で作成した2は異なった指紋を持つでしょう。
* If an implementation is using zlib to interoperate with PGP 2.x,
then the "windowBits" parameter should be set to -13.
* 実装がPGP 2.xと共に共同利用するのにzlibを使用しているなら、「windowBits」パラメタは-13に設定されるべきです。
* The 0x19 back signatures were not required for signing subkeys
until relatively recently. Consequently, there may be keys in
the wild that do not have these back signatures. Implementing
software may handle these keys as it sees fit.
* 0×19の逆署名は署名サブキーに比較的最近まで必要ではありませんでした。 その結果、荒野のこれらの逆署名を持っていないキーがあるかもしれません。 ソフトウェアを実装すると、これらのキーは適していると決めるように扱われるかもしれません。
* OpenPGP does not put limits on the size of public keys. However,
larger keys are not necessarily better keys. Larger keys take
more computation time to use, and this can quickly become
impractical. Different OpenPGP implementations may also use
different upper bounds for public key sizes, and so care should
be taken when choosing sizes to maintain interoperability. As of
2007 most implementations have an upper bound of 4096 bits.
* OpenPGPは公開鍵のサイズに限界を置きません。 しかしながら、より大きいキーは必ずより良いキーであるというわけではありません。 より大きいキーは、より多くの計算時間を使用にかけます、そして、これは急速に非実用的になることができます。 また、異なったOpenPGP実装が公開鍵サイズに異なった上限を使用するかもしれないので、相互運用性を維持するためにサイズを選ぶとき、注意するべきです。 2007年現在、ほとんどの実装には、4096ビットの上限があります。
* ASCII armor is an optional feature of OpenPGP. The OpenPGP
working group strives for a minimal set of mandatory-to-implement
features, and since there could be useful implementations that
only use binary object formats, this is not a "MUST" feature for
an implementation. For example, an implementation that is using
OpenPGP as a mechanism for file signatures may find ASCII armor
unnecessary. OpenPGP permits an implementation to declare what
features it does and does not support, but ASCII armor is not one
of these. Since most implementations allow binary and armored
objects to be used indiscriminately, an implementation that does
not implement ASCII armor may find itself with compatibility
issues with general-purpose implementations. Moreover,
implementations of OpenPGP-MIME [RFC3156] already have a
* ASCIIよろいかぶとはOpenPGPに関するオプション機能です。 OpenPGPワーキンググループは1人の極小集合の実装するために義務的な特徴を求めて努力します、そして、2進のオブジェクト形式を使用するだけである役に立つ実装があるかもしれないので、これは実装のための“MUST"の特徴ではありません。 例えば、ファイル署名にメカニズムとしてOpenPGPを使用している実装によって、ASCIIよろいかぶとが不要であることがわかるかもしれません。 OpenPGPは、実装がそれがして、サポートしないすべての特徴を宣言するのを可能にしますが、ASCIIよろいかぶとはこれらの1つではありません。 ほとんどの実装が、2進の、そして、武具のオブジェクトが無差別に使用されるのを許容するので、ASCIIがよろいかぶとであると実装しない実装は汎用実装の互換性の問題でそれ自体を見つけるかもしれません。 そのうえ、OpenPGP-MIME[RFC3156]の実装には、aが既にあります。
Callas, et al Standards Track [Page 85] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[85ページ]RFC4880OpenPGP Message Format2007年11月
requirement for ASCII armor so those implementations will
necessarily have support.
ASCIIよろいかぶとのためのしたがって、それらの実装にはサポートが必ずあるという要件。
16. References
16. 参照
16.1. Normative References
16.1. 引用規格
[AES] NIST, FIPS PUB 197, "Advanced Encryption Standard
(AES)," November 2001.
http://csrc.nist.gov/publications/fips/fips197/fips-
197.{ps,pdf}
[AES]NIST、FIPSパブ197、「エー・イー・エス(AES)」11月2001日の http://csrc.nist.gov/publications/fips/fips197/fips- 197。ps、pdf
[BLOWFISH] Schneier, B. "Description of a New Variable-Length
Key, 64-Bit Block Cipher (Blowfish)" Fast Software
Encryption, Cambridge Security Workshop Proceedings
(December 1993), Springer-Verlag, 1994, pp191-204
<http://www.counterpane.com/bfsverlag.html>
[BLOWFISH]シュナイアー、Fast Software Encryption、B.「新しい可変長のキー、64ビットのブロック暗号(フグ)の記述」ケンブリッジSecurity Workshop Proceedings Springer-Verlag、1994、pp191-204<http://www.counterpane.com/bfsverlag.html>(1993年12月)
[BZ2] J. Seward, jseward@acm.org, "The Bzip2 and libbzip2
home page" <http://www.bzip.org/>
[BZ2] J.シューアードと、 jseward@acm.org と、「Bzip2とlibbzip2ホームページ」<http://www.bzip.org/>。
[ELGAMAL] T. Elgamal, "A Public-Key Cryptosystem and a
Signature Scheme Based on Discrete Logarithms," IEEE
Transactions on Information Theory, v. IT-31, n. 4,
1985, pp. 469-472.
[ELGAMAL]T.Elgamal、「公開鍵暗号系と署名は離散対数に基づいて計画する」情報Theory、vのIEEE Transactions。 IT-31、n。 4 1985、ページ 469-472.
[FIPS180] Secure Hash Signature Standard (SHS) (FIPS PUB 180-
2).
<http://csrc.nist.gov/publications/fips/fips180-
2/fips180-2withchangenotice.pdf>
[FIPS180]はハッシュ署名規格(SHS)(FIPSパブ180- 2)を保証します。 <http://csrc.nist.gov/刊行物/fips/fips180 2/fips180-2withchangenotice.pdf>。
[FIPS186] Digital Signature Standard (DSS) (FIPS PUB 186-2).
<http://csrc.nist.gov/publications/fips/fips186-2/
fips186-2-change1.pdf> FIPS 186-3 describes keys
greater than 1024 bits. The latest draft is at:
<http://csrc.nist.gov/publications/drafts/
fips_186-3/Draft-FIPS-186-3%20_March2006.pdf>
[FIPS186]デジタル署名基準(DSS)(FIPSパブ186-2)。 <http://csrc.nist.gov/刊行物/fips/fips186-2/fips186-2-change1.pdf>FIPS186-3は1024ビット以上のキーについて説明します。 最新の草稿が以下にあります。 <fips_186-3/草稿http://csrc.nist.gov/刊行物/草稿/FIPS-186-3%20_March2006.pdf>。
[HAC] Alfred Menezes, Paul van Oorschot, and Scott
Vanstone, "Handbook of Applied Cryptography," CRC
Press, 1996.
<http://www.cacr.math.uwaterloo.ca/hac/>
[HAC]アルフレッド・メネゼス、ポールバンOorschotとスコットVanstone、「適用された暗号のハンドブック」CRC Press、1996。 <http://www.cacr.math.uwaterloo.ca/hac/>。
[IDEA] Lai, X, "On the design and security of block
ciphers", ETH Series in Information Processing, J.L.
Massey (editor), Vol. 1, Hartung-Gorre Verlag
Knostanz, Technische Hochschule (Zurich), 1992
[IDEA]レイ、情報Processingの「ブロック暗号のデザインとセキュリティ」のX ETH Series、J.L.マッシー(エディタ)、Vol.1、ハルトゥング-Gorre Verlag Knostanz、Technische Hochschule(チューリッヒ)1992
Callas, et al Standards Track [Page 86] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[86ページ]RFC4880OpenPGP Message Format2007年11月
[ISO10646] ISO/IEC 10646-1:1993. International Standard --
Information technology -- Universal Multiple-Octet
Coded Character Set (UCS) -- Part 1: Architecture
and Basic Multilingual Plane.
[ISO10646]ISO/IEC10646-1:1993。 国際規格--情報技術--普遍的なMultiple-八重奏Coded文字コード(UCS)--第1部: アーキテクチャと基本多言語水準。
[JFIF] JPEG File Interchange Format (Version 1.02). Eric
Hamilton, C-Cube Microsystems, Milpitas, CA,
September 1, 1992.
[JFIF]JPEGは置き換え形式(バージョン1.02)をファイルします。 エリック・ハミルトン、シーキューブマイクロシステムズ、ミルピタス、1992年9月1日のカリフォルニア。
[RFC1950] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data
Format Specification version 3.3", RFC 1950, May
1996.
[RFC1950] ドイツ語、P.、およびJ-L。 ゲイル、「ZLIB Compressed Data Format Specification、バージョン3.3インチ、RFC1950、1996インチ年5月。
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format
Specification version 1.3", RFC 1951, May 1996.
ドイツ語、[RFC1951]P.、「DEFLATE Compressed Data Format Specification、バージョン1.3インチ、RFC1951、1996インチ年5月。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet
Message Bodies", RFC 2045, November 1996
解放された[RFC2045]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC
2144, May 1997.
[RFC2144]アダムス(C.、「キャスト-128暗号化アルゴリズム」、RFC2144)は1997がそうするかもしれません。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP
26, RFC 2434, October 1998.
[RFC2434]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
[RFC2822] レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。
[RFC3156] Elkins, M., Del Torto, D., Levien, R., and T.
Roessler, "MIME Security with OpenPGP", RFC 3156,
August 2001.
2001年8月の[RFC3156]エルキンズとM.とデルTortoとD.とレヴィエン、R.とT.Roessler、「OpenPGPがあるMIMEセキュリティ」RFC3156。
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003.
[RFC3447] イェンソン、J.、およびB.Kaliski、「公開鍵暗号化標準(PKCS)#1:」 RSA暗号仕様バージョン2.1インチ、RFC3447、2月2003日
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau、F.、「UTF-8、ISO10646の変換形式」STD63、RFC3629、11月2003日
[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC
4086, June 2005.
[RFC4086]イーストレークとD.と3番目、シラー、J.とS.クロッカー、「セキュリティのための偶発性要件」BCP106、2005年6月のRFC4086。
Callas, et al Standards Track [Page 87] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[87ページ]RFC4880OpenPGP Message Format2007年11月
[SCHNEIER] Schneier, B., "Applied Cryptography Second Edition:
protocols, algorithms, and source code in C", 1996.
[シュナイアー]シュナイアー、B.、「適用された暗号第2版:」 1996の「Cのプロトコル、アルゴリズム、およびソースコード」
[TWOFISH] B. Schneier, J. Kelsey, D. Whiting, D. Wagner, C.
Hall, and N. Ferguson, "The Twofish Encryption
Algorithm", John Wiley & Sons, 1999.
[TWOFISH]B.シュナイアーとJ.ケルシーとD.ホワイティングとD.ワグナー、C.ホールとN.ファーガソン、「Twofish暗号化アルゴリズム」ジョンワイリーと息子、1999。
16.2. Informative References
16.2. 有益な参照
[BLEICHENBACHER] Bleichenbacher, Daniel, "Generating Elgamal
signatures without knowing the secret key,"
Eurocrypt 96. Note that the version in the
proceedings has an error. A revised version is
available at the time of writing from
<ftp://ftp.inf.ethz.ch/pub/publications/papers/ti
/isc/ElGamal.ps>
[BLEICHENBACHER] Bleichenbacher、ダニエル、「秘密鍵を知らないで、Elgamal署名を発生させます」、Eurocrypt96。 議事におけるバージョンには誤りがあることに注意してください。 改訂版は<ftp://ftp.inf.ethz.ch/パブ/刊行物/書類/ti/isc/ElGamal.ps>から書く時点で、利用可能です。
[JKS02] Kahil Jallad, Jonathan Katz, Bruce Schneier
"Implementation of Chosen-Ciphertext Attacks against
PGP and GnuPG" http://www.counterpane.com/pgp-
attack.html
[JKS02]Kahil Jallad、ジョナサン・キャッツ、ブルースシュナイアー「PGPとGnuPGに対する選ばれた暗号文攻撃の実現」 http://www.counterpane.com/pgp- attack.html
[MAURER] Ueli Maurer, "Modelling a Public-Key
Infrastructure", Proc. 1996 European Symposium on
Research in Computer Security (ESORICS' 96), Lecture
Notes in Computer Science, Springer-Verlag, vol.
1146, pp. 325-350, Sep 1996.
[モウラー]Ueliモウラー、「公開鍵暗号基盤をモデル化します」、Proc。 コンピュータSecurity(ESORICSの96)のResearchの上の1996のヨーロッパのSymposium、コンピュータScience、Springer-Verlag、vol.1146、ページのLecture Notes 325-350と、1996年9月。
[MZ05] Serge Mister, Robert Zuccherato, "An Attack on CFB
Mode Encryption As Used By OpenPGP," IACR ePrint
Archive: Report 2005/033, 8 Feb 2005
http://eprint.iacr.org/2005/033
[MZ05] Serge氏、ロバートZuccherato、「OpenPGPによって使用されるCFBモード暗号化に対する攻撃」とIACR ePrintは、格納します: レポート2005/033、2005年2月8日 http://eprint.iacr.org/2005/033
[REGEX] Jeffrey Friedl, "Mastering Regular Expressions,"
O'Reilly, ISBN 0-596-00289-0.
[REGEX]ジェフリー・フリードル、「正規表現を習得します」、オライリー、ISBN0-596-00289-0。
[RFC1423] Balenson, D., "Privacy Enhancement for Internet
Electronic Mail: Part III: Algorithms, Modes, and
Identifiers", RFC 1423, February 1993.
[RFC1423]Balenson、D.、「インターネット電子メールのためのプライバシー増進:」 パートIII: 「アルゴリズム、モード、および識別子」、RFC1423、2月1993日
[RFC1991] Atkins, D., Stallings, W., and P. Zimmermann, "PGP
Message Exchange Formats", RFC 1991, August 1996.
[RFC1991] アトキンスとD.とストーリングズ、W.とP.Zimmermann、「PGP交換処理形式」、RFC1991、1996年8月。
[RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R.
Thayer, "OpenPGP Message Format", RFC 2440, November
1998.
[RFC2440] カラスとJ.とDonnerhackeとL.とフィニー、H.とR.セイヤー、「OpenPGPメッセージ・フォーマット」、RFC2440、1998年11月。
Callas, et al Standards Track [Page 88] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[88ページ]RFC4880OpenPGP Message Format2007年11月
[SP800-57] NIST Special Publication 800-57, Recommendation on
Key Management
<http://csrc.nist.gov/publications/nistpubs/ 800-
57/SP800-57-Part1.pdf>
<http://csrc.nist.gov/publications/nistpubs/ 800-
57/SP800-57-Part2.pdf>
[SP800-57]NISTの特別な公表800-57、Key Management<http://csrc.nist.gov/刊行物/nistpubs/800- 57/SP800-57-Part1.pdf><http://csrc.nist.gov/刊行物/nistpubs/800- 57/SP800-57-Part2.pdf>における推薦
Acknowledgements
承認
This memo also draws on much previous work from a number of other authors, including: Derek Atkins, Charles Breed, Dave Del Torto, Marc Dyksterhouse, Gail Haspert, Gene Hoffman, Paul Hoffman, Ben Laurie, Raph Levien, Colin Plumb, Will Price, David Shaw, William Stallings, Mark Weaver, and Philip R. Zimmermann.
また、このメモは多くの他の作者、包含から前の多くの仕事を利用します: デリック・アトキンス、チャールズBreed、デーヴデルTorto、マークDyksterhouse、ゲイルHaspert、Geneホフマン、ポール・ホフマン、ベン・ローリー、Raphレヴィエン、垂直なコリンウィルPrice、デヴィッド・ショー、ウィリアム・ストーリングズはウィーバー、およびフィリップR.Zimmermannをマークします。
Authors' Addresses
作者のアドレス
The working group can be contacted via the current chair:
現在のいすを通してワーキンググループに連絡できます:
Derek Atkins
IHTFP Consulting, Inc.
4 Farragut Ave
Somerville, MA 02144 USA
Inc.4ファラガット・Ave MA02144サマービル(米国)に相談するデリックアトキンスIHTFP
EMail: derek@ihtfp.com
Tel: +1 617 623 3745
メール: derek@ihtfp.com Tel: +1 617 623 3745
The principal authors of this document are as follows:
このドキュメントの共著の中心となる著者は以下の通りです:
Jon Callas
EMail: jon@callas.org
ジョンCallasはメールされます: jon@callas.org
Lutz Donnerhacke
IKS GmbH
Wildenbruchstr. 15
07745 Jena, Germany
EMail: lutz@iks-jena.de
ルッツDonnerhacke IKS GmbH Wildenbruchstr。 15 07745イエナ(ドイツ)メール: lutz@iks-jena.de
Hal Finney
EMail: hal@finney.org
ハルフィニーEMail: hal@finney.org
David Shaw
EMail: dshaw@jabberwocky.com
デヴィッドショーEMail: dshaw@jabberwocky.com
Rodney Thayer
EMail: rodney@canola-jones.com
ロドニーセイヤーEMail: rodney@canola-jones.com
Callas, et al Standards Track [Page 89] RFC 4880 OpenPGP Message Format November 2007
カラス、他Standards Track[89ページ]RFC4880OpenPGP Message Format2007年11月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Callas, et al Standards Track [Page 90]
カラス、他のStandards Track[90ページ]
一覧
スポンサーリンク
