ネットワーク WG
Request for Comments: 2440
分類: Standards Track

J. Callas
Network Associates
L. Donnerhacke
IN-Root-CA Individual Network e.V.
H. Finney
Network Associates
R. Thayer
EIS Corporation
1998年11月

English

OpenPGP のメッセージフォーマット
(OpenPGP Message Format)


このメモの位置づけ

本書は、インターネットコミュニティに対してインターネットスタンダードトラックのプロトコルを定義するとともに、それを改良するための議論や提言を求めるものである。 このプロトコルの標準化状態およびステータスについては、「Internet Official Protocol Standards」(STD 1) の最新版を参照すること。 このメモの配布に制限はない。

著作権標記

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

IESG 注意

本書において、多くのタグが定義されているが、(新機能のための)新しいタグを追加するメカニズムについては解説していない。伝統的に、IANA(Internet Assigned Numbers Authority)が、将来 、拡張される新しい値の割りあてをコントロールしており、IANA に使われるために、RFC は、通常、プロセスを定義している。しかし、このプロトコル内で起きる可能性がある新機能間の微妙な(それほど微妙でない)相互作用と、全体のセキュリティを著しく低くするような既存の機能が存在する。それゆえ、本書は、拡張プロセスについては規定していない。新しいタグの定義(例として新しい暗号アルゴリズム等)を要求する代わりに、IESG セキュリティエリアディレクターや適切な IETF ワークグループに検討してもらうよう転送する必要がある。

要旨

本書は、OpenPGP 形式に基づく相互運用可能なアプリケーションの開発のために必要な、すべての情報を公開するために維持管理されている。これは、アプリケーションを実装するための細かな手順書ではない。ここでは、OpenPGP 形式についての説明と、ネットワーク上に流れる形式に準ずるパケットの読み・書き・生成・チェックの方法等についてのみ解説されている。しかし、実装にあたって、セキュリティ脆弱性等を避けるために必要な注意点等を解説する。

OpenPGP を実装するソフトウェアは、強度の高い公開鍵と共通鍵暗号の両方を使って、電子通信とデータの格納のセキュリティサービスを提供する。これらのサービスには、守秘性(confidentiality)、鍵管理(key management)、認証(authentication)、デジタル署名(digital signatures)が含まれる。本書では、OpenPGP において使用するメッセージフォーマットの仕様を示す。

目次

このメモの位置づけ

IESG 注意

要旨

目次

1.  はじめに
    1.1.  用語

2.  一般的な機能
    2.1.  暗号化による守秘性
    2.2.  デジタル署名による認証
    2.3.  圧縮
    2.4.  Radix-64 への変換
    2.5.  署名専用アプリケーション

3.  データ要素のフォーマット
    3.1.  スカラー数
    3.2.  MPI
    3.3.  鍵 ID
    3.4.  テキスト
    3.5.  時刻フィールド
    3.6.  S2K 識別子
        3.6.1.  S2K 識別子の種類
            3.6.1.1.  シンプル S2K
            3.6.1.2.  ソルト S2K
            3.6.1.3.  累積的ソルト S2K
        3.6.2.  S2K の 用法
            3.6.2.1.  秘密鍵の暗号化
            3.6.2.2. 共通鍵アルゴリズムによるメッセージの暗号化

4.  パケットの構文
    4.1.  概要
    4.2.  パケットヘッダ
        4.2.1.  古いフォーマットのパケット長
        4.2.2.  新しいフォーマットのパケット長
            4.2.2.1.  1 オクテット長
            4.2.2.2.  2 オクテット長
            4.2.2.3.  5 オクテット長
            4.2.2.4.  部分 ボディ長
        4.2.3.  パケット長の 例
    4.3.  パケットタグ

5.  パケットの種類
    5.1. 公開鍵暗号セッション鍵パケット(Tag 1)
    5.2. 署名パケット(Tag 2)
        5.2.1. 署名の種類
        5.2.2. v3 署名パケットフォーマット
        5.2.3. v4 署名パケットフォーマット
            5.2.3.1. 署名サブパケットの仕様
            5.2.3.2. 署名サブパケットの種類
            5.2.3.3. 署名作成日時
            5.2.3.4. 発行者
            5.2.3.5. 鍵の有効期間
            5.2.3.6. 選択された共通鍵暗号アルゴリズム
            5.2.3.7. 選択されたハッシュアルゴリズム
            5.2.3.8. 選択された圧縮アルゴリズム
            5.2.3.9. 署名の有効期間
            5.2.3.10. エクスポート可能な証明書
            5.2.3.11. 失効可能
            5.2.3.12. トラスト署名
            5.2.3.13. 正規表現
            5.2.3.14. 失効鍵
            5.2.3.15. メモデータ
            5.2.3.16. 鍵サーバの選択
            5.2.3.17. 選択された鍵サーバ
            5.2.3.18. プライマリユーザ ID
            5.2.3.19. ポリシー URL
            5.2.3.20. 鍵フラグ
            5.2.3.21. 署名者のユーザ ID
            5.2.3.22. 失効の理由
        5.2.4. 署名の計算
        5.2.4.1. サブパケットのヒント
    5.3. 共通鍵暗号化されたセッション鍵パケット(Tag 3)
    5.4. One-Pass 署名パケット(Tag 4)
    5.5. 鍵素材パケット
        5.5.1. [鍵パケットの変型
            5.5.1.1. 公開鍵パケット(Tag 6)
            5.5.1.2. 公開サブキーパケット(Tag 14)
            5.5.1.3. 秘密鍵パケット(Tag 5)
            5.5.1.4. 秘密サブキーパケット(Tag 7)
        5.5.2. 公開鍵パケットの フォーマット
        5.5.3. 秘密鍵パケットの フォーマット
    5.6. 圧縮データパケット(Tag 8)
    5.7. 共通鍵暗号化データパケット(Tag 9)
    5.8. マーカーパケット(廃止されたリテラルパケット)(Tag 10)
    5.9. リテラルデータパケット(Tag 11)
    5.10. トラストパケット(Tag 12)
    5.11. ユーザ ID パケット(Tag 13)

6. Radix-64 変換
    6.1. C 言語による RC-24 の実装
    6.2. ASCII Armor の形成
    6.3. バイナリを Radix-64 にエンコード
    6.4. Radix-64 のデコード
    6.5. Radix-64 変換の例
    6.6. ASCII Armor メッセージの例

7. クリアテキスト署名のフレームワーク
    7.1. Dash-Escaped テキスト

8. 正規表現

9. 定数
    9.1. 公開鍵暗号アルゴリズム
    9.2. 共通鍵暗号アルゴリズム
    9.3. 圧縮アルゴリズム
    9.4. ハッシュアルゴリズム

10. パケットの構成
    10.1. 転送可能な公開鍵
    10.2. OpenPGP メッセージ
    10.3. 分離署名

11. 拡充された鍵のフォーマット
    11.1. 鍵の構成
    11.2. 鍵 ID とフィンガープリント

12. アルゴリズムについての注意事項
    12.1. 共通鍵暗号アルゴリズムの選択
    12.2. 他のアルゴリズムの選択
        12.2.1. 圧縮アルゴリズムの選択
        12.2.2. ハッシュアルゴリズムの選択
    12.3. プレーンテキスト
    12.4. RSA
    12.5. Elgamal
    12.6. DSA
    12.7. 予約済みアルゴリズム番号
    12.8. OpenPGP CFB モード

13. セキュリティに関する考慮事項

14. 実装に関するその他の事項

15. 著者とワーキンググループ

16. 参考文献

17. 著作権 表記全文

 

1. はじめに English

本書は、暗号化、復号、署名、鍵管理機能を提供するため、OpenPGP で使用するメッセージ交換パケット形式の情報を提供する。これは、RFC 1991 "PGP Message Exchange Formats" を参考に作成されている。

1.1. 用語 English

"PGP"、"Pretty Good" および "Pretty Good Privacy" は、Network Associates, Inc. の登録商標であり、Network Associates, Inc. より使用許可を得ている。

本書は、"MUST", "SHOULD", "MAY" の用語を RFC 2119 に規定されているように使っている。

 

2. 一般的な機能 English

OpenPGP は、下記の機能を用いてメッセージおよびデータのインテグリティ(data integrity)を提供する。

また、OpenPGP は、鍵管理と証明(certificate)サービスも提供するが、それらの多くは、本書の範囲ではない。

2.1. 暗号化による守秘 English

OpenPGP は、守秘性を提供するため、ふたつの暗号アルゴリズムを使用する。共通鍵暗号と公開鍵暗号である。公開鍵暗号アルゴリズムの場合、守秘性の対象となるものを共通鍵暗号で暗号化する。各共通鍵は、1 度だけ使用される。新しい「セッション鍵」は、乱数として各メッセージごとに生成される。セッション鍵は、一度しか使用されないので、メッセージと共に送信される。そのセッション鍵を守るため、それは受信者の公開鍵で暗号化されている。順序は、下記のとおり。

  1. 送信者は、メッセージを作成する。

  2. 送信側の OpenPGP は、乱数を生成し、(1)で作成したメッセージにのみ使えるセッション鍵として使用。

  3. セッション鍵は、各受信者の公開鍵で暗号化され、これらの"暗号化されたセッション鍵(encrypted session keys)"がメッセージの頭に含まれる。

  4. 送信側の OpenPGP は、セッション鍵を使用してメッセージを暗号化し、その結果がメッセージの残りの部分を形成する。このとき、通常、メッセージは、圧縮されていることに注意。

  5. 受信側の OpenPGP は、受信者の秘密鍵を使用してセッション鍵を復号する。

  6. 受信側の OpenPGP は、メッセージをセッション鍵によって復号する。メッセージが圧縮されていれば、解凍される。

共通鍵暗号の場合、(2 通りあり、ひとつは)暗号化の対象は、パスフレーズ(または、他の共有シークレット)から生成される共通鍵で暗号化され、(もう一方は)上記で説明した(公開鍵暗号アルゴリズムの場合)ような 2 段階方式を用いて、セッション鍵の暗号化には共有シークレットを使用する。

デジタル署名、守秘性機能(暗号化)の両方とも同じメッセージに適用される場合がある。まず、はじめに、メッセージへの署名が生成され、付け加えられる。そして、「メッセージ+署名」は、共通鍵であるセッション鍵で暗号化される。最後に、セッション鍵は、公開鍵で暗号化されて、暗号ブロックの前に置かれる。

2.2. デジタル署名による認証 English

デジタル署名は、ハッシュコードかメッセージダイジェスト方式を使用し、公開鍵署名方式を使用する。順序を以下に示す。

  1. 送信者がメッセージを作成する。

  2. 送信ソフトがメッセージのハッシュコードを生成する。

  3. 送信ソフトは送信者の秘密鍵を用いてハッシュコードから署名を生成。

  4. バイナリー署名(*訳注:(3)で生成した署名)は、メッセージに付け加えられる。

  5. 受信ソフトは、メッセージの署名を保持する。

  6. 受信ソフトは、受けとったメッセージのハッシュコードを改めて生成し、メッセージの署名(*訳注:(5)で生成したもの)と照合する。照合が成立した場合、メッセージは、信頼できるものとして受領される。

2.3. 圧縮 English

OpenPGP の実装は、暗号化の前、署名の後にメッセージを圧縮してもよい(MAY)

2.4. Radix-64 への変換 English

OpenPGP の暗号化メッセージ・署名証明書・キーの内在形式は、任意のオクテットストリームである。システムによっては、プリンタブル(Printable)な 7 bit を含むブロックのみを許可する。バイナリーデータを送信するとき、セキュアでないチャネル上で OpenPGP の生のバイナリーオクテットを送信するためには、それらバイナリーオクテットをプリンタブル形式にエンコードする必要がある。OpenPGP は、8 bit バイナリーオクテットストリームからプリンタブル ASCII キャラクターへの変換を提供する。それを Radix-64 エンコード、もしくは ASCII Armor と呼ぶ。

実装は、Radix-64 変換を提供する必要がある(SHOULD)

多くのアプリケーション、特にメッセージアプリケーションは、OpenPGP-MIME 文書(RFC 2015)で解説されている機能をもつことが望ましい。OpenPGP を実装しようとするメッセージアプリケーションは、OpenPGP-MIME を実装する必要がある(SHOULD)

2.5. 署名専用アプリケーション English

OpenPGP は、暗号化と署名の両方を使用するアプリケーションを前提に設計されているが、署名のみの実装によって解決される問題も、いくつか存在する。この仕様においては暗号化と署名の両方が必須とされているが、暗号の部分を省略した実装が存在することは意味のあることである。

 

3. データ要素のフォーマット English

この章では、OpenPGP で使用されるデータ要素について解説する。

3.1. スカラー数 English

スカラー数は、Unsigned(符号なし)で、常に big-endian 形式で保存される。n[k] を k 番目のオクテットとすると、2 オクテットのスカラーの値は、((n[0]<<8)+n[1]) となる。また、4 オクテットのスカラーの値は、((n[0]<<24)+(n[1]<<16)+(n[2]<<8)+n[3]) となる。

3.2. MPI English

MPI(Multi-Precision Integer)は、符号無し整数(unsigned integer)であり、暗号の計算等に使用する大きな整数に適用される。

MPIは、ふたつの部分から成る。整数(*訳注:原文では MPI と表しているが、厳密には整数を指す)の長さをビットで表した 2 オクテットのスカラーと、その後に整数を表すオクテットの文字列が並ぶ。

これらのオクテットは、big-endian 数を形成する。big-endian 数は、適切な長さを big-endian 数で表したものを前に置くことによって MPI になることができる。

例:
(全ての数字は16進数表記)

オクテットの文字列 [00 01 01] は、1 という値で MPI を形成する。文字列 [00 09 01 FF] は、511 という値で MPI を形成する。

追加規則:

MPI のサイズは、((MPI.length + 7) /8) + 2 オクテットとなる。

MPI の長さは、最上位のゼロでないビットから数える。MPI フォームとして [00 02 01] は、(MPI として)正しくなく、[00 01 01] とする必要がある。

3.3. 鍵 ID English

鍵 ID は、鍵の識別をする 8 オクテットのスカラーで形成される。実装は、鍵 ID が固有であることを仮定してはいけない(SHOULD NOT)。後述する「拡充された鍵のフォーマット」の章では、鍵 ID がどのように形成されるかについて解説する。

3.4. テキスト English

テキストに使用するデフォルトのキャラクターセットは、Unicode [ISO10646] をエンコードした UTF-8 [RFC2279] である。

3.5. 時刻フィールド English

時刻フィールドは、<1 January 1970 UTC>の深夜 00:00 から経過した時間を秒単位で表しており、unsigned の 4 オクテット数で表される。

3.6. S2K識別子 English

String-to-key(S2K)識別子は、パスフレーズの文字列を暗号化/復号用共通鍵へ変換するのに使用される。それらは、2 箇所に使われている。現在のところ、秘密鍵リング内にある秘密鍵の秘密な部分を暗号化するときと、パスフレーズを共通鍵暗号メッセージ用の共通鍵(*訳注:セッション鍵)へ変換するときに使用される。

3.6.1. S2K識別子の種類 English

現在のところ、S2K識別子には、下記の 3 種類がある。

3.6.1.1. シンプルS2K English

Simple S2K では、文字列をハッシュして直接鍵データをつくり出す。ハッシュの手順について以下に示す。

Octet 0: 0x00
Octet 1: hash algorithm (ハッシュアルゴリズム)

Simple S2K は、パスフレーズをハッシュしてセッション鍵を生成する。この方法は、セッション鍵のサイズ(使用する暗号アルゴリズムに依存)とハッシュアルゴリズムの出力サイズに依存する。ハッシュサイズがセッション鍵のサイズより大きい場合、ハッシュの上位(左側からの)オクテットをセッション鍵として使用する。

ハッシュサイズがセッション鍵のサイズよりも小さい場合、鍵データ作成に必要な量の複数のハッシュコンテクストが作成される。これらは、0、 1、2、... 個のゼロのオクテットでプレロードされる(つまり、1回目のインスタンスは、プレロードをもたず、2 回目のインスタンスは、1 オクテットのゼロがプレロードされ、3 回目のインスタンスは、2 オクテットのゼロがプレロードされ...となる)。

データがハッシュされるとき、データは、各ハッシュコンテクストへ個々に与えられる。コンテクストは、別々に初期化されるので、それぞれが異なるハッシュ値を出力する。いったん、パスフレーズがハッシュされた後、複数のハッシュ出力値は、左から連結され、最も左のハッシュ値を先頭に必要量を鍵データとし、右側の残った余分なオクテットは、破棄される。

3.6.1.2. ソルト S2K English

Salted S2K は、辞書攻撃(Dictionary Attack)を防ぐために S2K 識別子の中に "Salt(塩)" 値(ある任意のデータ)を加えたもので、パスフレーズと共にハッシュされる。

       Octet 0:        0x01
       Octet 1:        hash algorithm (ハッシュアルゴリズム)
       Octets 2-9:     8-octet salt value (8オクテットのSalt値)

Salted S2K は、Simple S2K とよく似ているが、ハッシュ関数への入力値は S2K 識別子からの 8 オクテット分の Salt が含まれる点が異なり、パスフレーズが後ろに続く。

3.6.1.3. 累積的ソルト S2K English

Iterated and Salted S2K は、Salt とオクテットカウントの両方を含む。Salt は、パスフレーズと組み合わせられ、その結果値は繰り返しハッシュされる。これによって、攻撃者が辞書攻撃をするためにしなければならない作業が増える。

       Octet  0:        0x03
       Octet  1:        hash algorithm (ハッシュアルゴリズム)
       Octets 2-9:      8-octet salt value (8 オクテットの Salt値)
       Octet  10:       count, a one-octet, coded value 
            (1オクテットにエンコードされたカウント値)

カウントは下記の公式を使用して 1 オクテットにエンコードされる。

       #define EXPBIAS 6
           count = ((Int32)16 + (c & 15)) << ((c >> 4) + EXPBIAS);

上記の公式は、C言語の表記である、"Int32" とは、32 bit 整数を示し、変数である。"c"は、エンコードのカウント(オクテット10)を示している。

Iterated-Salted S2K は、パスフレーズと Salt データを複数回ハッシュする。ハッシュされるオクテットの合計数は、S2K 識別子の中のエンコードされたカウントが示している。カウント値は、いくつのオクテットがハッシュされるかの数であり、繰り返しのカウントではない。

はじめに、ひとつ以上のハッシュコンテクストは、鍵データに必要な量のオクテット数に応じて、他の S2K 方式と同様に初期化される。そして、Salt とパスフレーズ(Salt の後ろに続く)は、オクテットカウントに指定された数のオクテットがすべてハッシュされるまで繰り返しハッシュされる。例外として、オクテットカウントが Salt とパスフレーズをあわせたサイズより小さい場合、(あわせたサイズがオクテットカウントより大きくても)そのあわせたもの全体がハッシュされる。ハッシュ後、データはその他の S2K 方式と同様に、ハッシュコンテクストからアンロードされる。

3.6.2. S2K の用法 English

実装は、Simple-S2K 識別子が辞書攻撃に弱いことから、Salted-S2K 識別子もしくは Iterated-and-Salted S2K 識別子を使用する必要がある。

3.6.2.1. 秘密鍵の暗号化 English

パスフレーズを秘密データ復号鍵へ変換する方式を示すために S2K 識別子を秘密鍵の中に置くことができる。PGP の古いバージョンでは、暗号アルゴリズムを示すオクテットは 、秘密データの前におかれ、それがゼロの場合、秘密データは暗号化していないことを表していた。パスフレーズを鍵へ変換するときは常に MD5ハッシュ関数が利用されていた。

互換性のため、S2K 識別子が使用されるとき、古いデータ構造の中でハッシュアルゴリズムを示すオクテットであった位置に、255 という特別な値が入る。その後に 1 オクテットの(暗号)方式識別子が続き、上記で示したように S2K 識別子が続く。

それゆえ、秘密データの前につくものは、下記の内のひとつつである。

       0:           秘密鍵は暗号化されていない(パスフレーズなし)
    255:         (暗号)方式オクテットと S2K 識別子がつづく
    Cipher alg:  MD5ハッシュを使用したシンプル S2K 方式を使用

上記の 3 つめの選択肢、暗号アルゴリズム ID(MD5 と IDEA を暗黙に使用)は、下位互換性確保のために用意されている。OpenPGP の実装は、それを解釈してもよい(MAY)が、生成され てはいけない(SHOULD NOT)ので推奨されていない。

秘密データが暗号化されている場合、秘密データの復号のために上記の後ろに 8 オクテットの Initial Vector(初期ベクタ)が続き、その後ろに秘密鍵の値が続く。
(*訳注: 原文では秘密鍵データが暗号化されていない場合のことを特に説明していない。暗号化していない場合、S2K Usage (0, 255, CipAlg)は、0 となり、そのすぐ後ろに秘密鍵データが暗号化されていない状態で続く。秘密鍵データ形式の詳細については 5.5.3 節 を参照)

3.6.2.2. 共通鍵アルゴリズムによるメッセージの暗号化 English

OpenPGP は、Symmetric-key Encrypted Session Key(ESK)(共通鍵暗号セッション鍵)パケットを作成し、それをメッセージの前に置くことができる。これによって、S2K 識別子は、パスフレーズの変換に使用され、Symmetric-Key ESK か Public-Key ESK を混合したメッセージを作成することも可能となる。したがって、メッセージがパスフレーズで暗号化されていても、公開鍵で暗号化されていても、復号できる。

PGP 2.X は、共通鍵方式でメッセージを暗号化するとき、必ず Simple String-to-Key 変換 と IDEA を使用する。これは、推奨されていないが、下位互換性のために使用してもよい(MAY)

 

4. パケットの構文 English

この章では、OpenPGP のパケットについて解説する。

4.1. 概要 English

OpenPGP メッセージは、複数のレコードから構成され、それらはパケットと呼ばれる。パケットは、データの固まりであり、パケットタグ(Packet Tag)がパケットの意味を指す。OpenPGP のメッセージ、鍵リング、証明書(Certificate)等は、複数のパケットで構成される。それらのパケットは、さらに OpenPGP パケットを含んでいる場合がある(例えば、圧縮データパケットを解凍したとき、さらにその中に OpenPGP パケットが含まれている)。

各パケットは、パケットヘッダとそれに続くパケットボディから成り立つ。パケットヘッダは、可変長である。

4.2. パケットヘッダ English

パケットヘッダの最初のオクテットは、「パケットタグ(Packet Tag)」と呼ばれる。パケットタグは、ヘッダの形式を定め、パケットの内容を示す。残りの部分は、パケットの長さを表している。

最有位ビットは、左端のビット(ビット 7 と呼ぶ)である。このビットのマスク値は、16 進表記で 0x80 である。

              +---------------+
         PTag |7 6 5 4 3 2 1 0|
              +---------------+
         Bit 7 -- Always one(常に1)
         Bit 6 -- New packet format if set
         (ここが1の場合は新しいフォーマットを意味する)

PGP 2.6.x は、古いパケットフォーマットのみを扱う。それゆえ、PGP の古いバージョンとの相互運用が必要なソフトウェアは、古いパケット形式のみを使用する必要がある。相互運用がそれほど重要でない場合は、どちらの形式を使用してもかまわない。古いパケット形式のコンテントタグ(* 4.3 節にて後述)は4 bit、新しいパケット形式のコンテントタグは、6 bit であることに注意すること。下位互換性を保つ場合、新しい機能によっては使えない。

古いパケット形式は、下記の構成となる。

         Bits 5-2 -- コンテントタグ (content tag)
         Bits 1-0 -- パケット長の種類 (length-type)

新しいパケット形式は、下記の構成となる。

         Bits 5-0 -- コンテントタグ (content tag)
4.2.1. 古いフォーマットのパケット長 English

古いパケットフォーマット中にあるパケット長の種類(length-type)の意味を以下に示す。

   0 - パケット長は 1 オクテット。ヘッダーは 2 オクテットの長さとなる。

   1 - パケット長は 2 オクテット。ヘッダーは 3 オクテットの長さとなる。

   2 - パケット長は 4 オクテット。ヘッダーは 5 オクテットの長さとなる。

   3-  パケット長は不定。ヘッダーは1オクテットの長さで、実装がパケット
       の長さを判断する必要がある。仮にパケットがファイルの中にあるとす
       ると、パケットはファイルの終わりまで続いていることを意味する。一
       般的にデータの終わりが文脈上明確である場合を除き、パケットの長さ
       が不定なものを使用するべきではなく(SHOULD NOT)、一定の長さを使用
       するか、新しいフォーマットのパケットヘッダを使用する方がよりよいとされる。
       後述する新しいフォーマットのパケットヘッダでは、不定長なデータを正確にエンコードするメカニズムを解説する。
4.2.2. 新しいフォーマットのパケット長 English

新しいパケットフォーマットには、パケットの長さのエンコード方法が 4 つある。

  1. One-Octet Body Lengthヘッダ(1 オクテット)は、191 オクテットまでの長さのパケットをエンコードする。
     
  2. Two-Octet Body Lengthヘッダ(2 オクテット)は、192 から 8383 オクテットまでの長さのパケットをエンコードする。
     
  3. Five-Octet Body Lengthヘッダー(5 オクテット)は、4,294,967,295(0xFFFFFFFF)オクテットまでの長さのパケットをエンコードする。(実際には、4 オクテットスカラー数のオクテットをエンコードすることとなる)
     
  4. パケットボディの長さが不明なときは、Partial Body Length ヘッダ(部分的ボディ長)が、不定長のパケットをエンコードし、事実上ストリームとなる。
4.2.2.1. 1 オクテット長 English

One-Octet Body Length ヘッダは、0 から 191 オクテットまでの長さをエンコー ドする。このタイプのレングスヘッダは、1 オクテットの値が 192 未満であることによって識別できる。ボディ長は、下記のようになる。

bodyLen = 1st_octet;

4.2.2.2. 2 オクテット長 English

Two-Octet Body Length ヘッダは、192 から 8383 オクテットまでの長さをエンコードする。このタイプのレングスヘッダは、ひとつめのオクテットが 192 から 223 の範囲であることから識別できる。ボディ長は、下記のようになる。

bodyLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192

4.2.2.3. 5 オクテット長 English

Five-Octet Body Length ヘッダは、255 の値をもつ 1オクテットと、それに続く 4 オクテットのスカラー数で構成される。ボディ長は、下記のようになる。

       bodyLen = (2nd_octet << 24) | (3rd_octet << 16) |
                 (4th_octet << 8)  | 5th_octet
4.2.2.4. 部分ボディ長 English

Partial Body Length ヘッダは、1 オクテットの長さであり、パケットボディの一部の長さのみをエンコードする。この長さは、2 の累乗で表され、1 から 1,073,741,824(2 の 30 乗)までとなる。このタイプのレングスヘッダは、その中の 1 オクテットの値が 224 以上 255 未満であることから識別できる。Partial Body Length は、下記のようになる。

partialBodyLen = 1 << (1st_octet & 0x1f);

各 Partial Body Length ヘッダの後ろにパケットボディの一部がつづく。Partial Body Length ヘッダは、後ろに続くその部分のデータの長さを示している。そして、その他のレングスヘッダ(One-Octet、Two-Octet、Partial の 3 種類のいずれか)は、そのデータ部分の後ろに続く。パケット中の最後のレングスヘッダは、Partial Body Length ヘッダにしてはならない(MUST NOT)。Partial Body Length ヘッダは、それ以外の部分でのみ(パケットの最後の部分以外)使用可能である。(*訳注: 要するに、中間の部分は、Partial を使用してもよいが、最後に来る部分は、One-Octet か Two-Octet にしないといけないということらしい。)

4.2.3. パケット長の例 English

下記の例は、新しいパケット形式でのパケットの長さのエンコード方を示す。

長さが 100 のパケットで、その長さを 1 オクテットで表した場合、0x64 になる。その後に 100 オクテットのデータが続く。

長さが 1723 のパケットで、その長さを 2 オクテットで表した場合、0xC5、0xFB になる。その後ろに、1723 オクテットのデータが続く。

長さが 100,000 のパケットで、その長さを 5 オクテットで表した場合、0xFF、0x00、0x01、0x86、0xA0 になる。

この場合、次のようなオクテットストリームとしても表すことができる。:0xEF、 最初の32768オクテット、 0xE1、 次の2オクテット、 0xE0、 次の1オクテット、 0xF0、 次の65536オクテット、 < 0xC5、 0xDD、 最後の1693オクテットデータ。 これは、可能な表記例のひとつにすぎず、データの最後の部分が通常のボディ レングスヘッダである限り、Partial Body Length ヘッダのサイズは、多くのバリエーションが可能となる。なお、最後のボディレングスヘッダは、ゼロの長さを表すヘッダとなる場合がある。

実装は、Partial Body Length ヘッダをデータパケットに利用してもよい(MAY)。literal データや圧縮データ、暗号データの部分で可能である。ひとつ目の Partial Length は、最低 512 オクテットの長さでなければならない(MUST)。Partial Body Length は、他のパケットタイプに使用してはならない(MUST NOT)

上記の説明のすべてにおいて、パケットの長さの合計は、ヘッダの長さ+ボディの長さであることに注意。

4.3. パケットタグ English

       0        --    予約(パケットタグは、この値を使用してはならない。)
       1        --    公開鍵暗号セッション鍵パケット
       2        --    署名パケット
       3        --    共通鍵暗号セッション鍵パケット
       4        --    One-Pass 署名パケット
       5        --    秘密鍵パケット
       6        --    公開鍵パケット
       7        --    秘密サブキーパケット
       8        --    圧縮データパケット
       9        --    共通鍵で暗号化されたデータパケット
       10       --    マーカーパケット
       11       --    リテラルデータパケット
       12       --    トラストパケット
       13       --    ユーザ ID パケット
       14       --    公開サブキーパケット
       60 to 63 --  秘密 or 試験用の値

 

5. パケットの種類 English

5.1. 公開鍵暗号セッション鍵パケット(Tag 1) English

Public-Key Encrypted Session Key パケット(公開鍵暗号セッション鍵)には、メッセージの暗号化に使用したセッション鍵が入る。ゼロ、もしくは複数の Encrypted Session Key パケット(共通鍵 /公開鍵のどちらか)は、暗号メッセージが含まれる Symmetrically Encrypted Data パケットの前に位置する。メッセージは、セッション鍵で暗号化され、セッション鍵自体は、暗号化されて ESK(Encrypted Session Key)パケットに保存される。メッセージを暗号化した各 OpenPGP キーの Public-Key Encrypted Session Key パケットは、Symmetrically Encrypted Data パケットの前に置かれる。メッセージの受信者は、受信者の公開鍵で暗号化されたセッション鍵を見つけて、セッション鍵を復号し、そのセッション鍵でメッセージを復号する。

このパケットのボディは、下記の構成となる。

RSA 暗号化の特定フィールド:

Elgamal暗号化の特定フィールド:

上記の公式にある「m」という値は、次のようにセッション鍵から引き出される。まず、セッション鍵の後ろに続く Symmetric Encryption Data パケットの暗号化方式を示す 1 オクテットの暗号識別子がセッション鍵の前に Prefix される。次に、セッション鍵の前にあるオクテットの合計(暗号識別子を除く、65536 を法とする)を 2 オクテットのチェックサムとして付加する。 このチェックサムは、PKCS-1 ブロックタイプ 02 [RFC2313] 形式で埋め込まれ(pad)、上記公式の「m」の値を形成する。

注意) 実装がひとつのセッション鍵について複数の PKESK を形成している場合、複数の鍵で復号可能なメッセージを形成しており、実装は、各鍵毎の新しいPKCS-1 Padding(埋め込み)を作成しなければならない(MUST)

実装は、鍵 ID がすべてゼロのものを「ワイルドカード」、「推測的」鍵 ID として受領もしくは使用することができる。この場合、受領側の実装は、すべての秘密鍵を試してセッション鍵を復号できる鍵を探す。この形式によって、メッセージのトラフィック分析量を軽減している。

5.2. 署名パケット(Tag 2) English

Signature パケット(署名パケット)は、公開鍵とデータの関係を表す。最も一般的な署名は、ファイルやテキストブロックの署名と、ユーザ ID を証明する署名である。

Signature パケットにはふたつのバージョンがある。v3 では基本的な署名情報を提供し、v4 ではサブパケットという拡張形式によって、より多くの署名に関する情報を提供する。PGP 2.6.x  は、v3 の署名のみ受け付けることができる。

実装は、v3 署名を受け付けなければならない(MUST)。実装は、v4 署名を生成する必要がある(SHOULD)。実装は、PGP 2.6.x が認識可能な v3 署名を生成してもよい(MAY)

注意) 実装が v3 鍵で署名つき暗号メッセージを作成する場合、v3 署名を作成することが合理的である。

5.2.1. 署名の種類 English

署名には多くの意味があり、それらは署名の中の Signature-Type オクテットで示される。それら署名の意味を以下に示す。

0x00: バイナリドキュメントの署名

一般的に署名者が所有・作成したことを表し、改変されていないことを証明している。

0x01: 標準的テキストドキュメントの署名

 一般的に、この署名の種類は、署名者が所有・作成したことを表し、改変されていないことを証明している。テキストデータの行末を <CR><LF> に変換し、後続ブランクを削除したデータを元に署名が計算される。

0x02: スタンドアロン署名

この署名は、署名自身がもつサブパケット内容の署名である。これは、長さゼロのバイナリドキュメント(zero-length binary document)の署名と同様に計算される。スタンドアロン署名はv3では成立しないことに注意。

0x10: ユーザ ID と Public-Key パケットの一般的な証明

この証明は、実際のユーザ ID が鍵の所有者であることをよく確認したか否かについて特に主張しない。すべてのPGPの「鍵の署名(key signatures)」は、このタイプの証明である。

0x11: (ユーザ ID と Public-Key パケットの個人的証明)

この証明は、ユーザ ID が鍵の所有者であるか否かについて確認していない。

0x12: ユーザ ID と Public-Key パケットのカジュアル証明

この証明の発行人は、身分証明(identity)について、何らかの略式(カジュアル)確認をしている。

0x13: ユーザ ID と Public-Key パケットのポジティブ証明

この証明は、身分証明(identity:鍵所有者とユーザ ID の一致)について、信用のおける確認をしている。          

注意: これらの証明(0x10-0x13)の漠然さは、欠陥ではなく、システムの機能である。なぜならば、PGP は、最終的な正当性確認への権限を証明の受領側においているからであり、あるカジュアル証明の権限は、その他のポジティブ証明よりも厳しい場合がある。これらの分類によって、証明権限は、きめ細かい要求が可能となった。

0x18: サブキーバインディング署名

この署名は、トップレベルの署名鍵がサブキーを所有している状態を示す。この署名は、ユーザ ID やその他のパケットではなく、サブキー自身上で直接計算される。

0x1F: 鍵に直接署名

この署名は、鍵上で直接計算されている。これは、署名サブパケット中の情報を鍵と関係づけるものであり、Revocation Key サブパケット(無効化鍵サブパケット)等鍵についての情報を提供するサブパケットへの使用に適している。また、その他の証明者が、鍵と名前の関係性よりも、鍵についてのステートメントを作成したいときにも適している。

0x20: 鍵の無効化署名

この署名は、無効化される鍵上で直接計算される。無効化された鍵(revoked key)は、使えなくなる。無効化される鍵自身、もしくは無効化権限をもつ鍵が発行した Revocation Signature のみが正当な Revocation Signature であると認識される必要がある。

0x28: サブキー無効化署名

この署名は、無効化されるサブキー上で直接計算される。無効化されたサブキー(revoked subkey)は、使えなくなる。このサブキー自身とバインドしているトップレベルの署名鍵が発行、もしくは無効化権限をもつ鍵によって発行された Revocation Signature のみが正当な Revocation Signature であると認識される必要がある。

0x30: 証明書無効化署名

先に作成されているユーザ ID 証明書(署名分類 0x10 から 0x13)を無効化する署名。これは、無効化権限をもつ鍵、もしくは無効化された署名を発行した鍵と同じ鍵から発行される必要がある。この署名は、無効化される署名よりも後の作成日付をもっている必要がある(無効化されるか署名より新しい署名)。

0x40: タイムスタンプ署名

この署名は、その中にあるタイムスタンプのためのみに意味がある。
          

5.2.2. v3 署名パケットフォーマット English

v3 の Signature パケットには、下記の項目が含まれる。

この部分は、以下に示すとおり、アルゴリズム特定のものである。

署名されるデータは、ハッシュされ、次に Signature パケットの中の Signature Type と Creation Time がハッシュされる(追加の 5 オクテットの部分)。ハッシュ値の結果は署名アルゴリズムで使用される。ハッシュ値の上位 16 bit(最初の 2 オクテット)は、Signature パケットの中に含まれ、不正な署名を拒否する簡易テストに利用される。

RSA 署名方式の特定フィールド:

DSA 署名方式の特定フィールド:

署名の計算は、上記で解説した署名データのハッシュに基づいて計算される。 計算の詳細は、DSA 署名と RSA 署名では異なる。

RSA 署名では、ハッシュ値は、PKCS-1 の 10.1.2 節 "Data encoding" の仕様に従ってエンコードされており、それは、DigestInfo というタイプの ASN.1 値を作成し、PKCS-1 ブロックタイプ 01 を利用して pad される。[ RFC 2313 参照 ]。これには、ASN.1 ストラクチャに文字列としてハッシュ値を挿入する必要がある。ストラクチャ内にあるオブジェクト識別子(object identifier)は使用するハッシュの種類を識別する。現在、定義されているハッシュアルゴリズムを 16 進表記で以下に表す。

     - MD2:        0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x02

     - MD5:        0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05

     - RIPEMD-160: 0x2B, 0x24, 0x03, 0x02, 0x01

     - SHA-1:      0x2B, 0x0E, 0x03, 0x02, 0x1A
         

ANS.1 OID は、下記のようになる。

     - MD2:        1.2.840.113549.2.2

     - MD5:        1.2.840.113549.2.5

     - RIPEMD-160: 1.3.36.3.2.1

     - SHA-1:      1.3.14.3.2.26
         

上記の完全なハッシュ Prefix は、下記のようになる。

       MD2:        0x30, 0x20, 0x30, 0x0C, 0x06, 0x08, 0x2A, 0x86,
                   0x48, 0x86, 0xF7, 0x0D, 0x02, 0x02, 0x05, 0x00,
                   0x04, 0x10

       MD5:        0x30, 0x20, 0x30, 0x0C, 0x06, 0x08, 0x2A, 0x86,
                   0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05, 0x05, 0x00,
                   0x04, 0x10

       RIPEMD-160: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2B, 0x24,
                   0x03, 0x02, 0x01, 0x05, 0x00, 0x04, 0x14

       SHA-1:      0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2b, 0x0E,
                   0x03, 0x02, 0x1A, 0x05, 0x00, 0x04, 0x14
         

DSA 署名は、DSA の元の値(generator value)から求められる群の位数(size of the group)「q」の大きさに合わせて、160 bit サイズのハッシュを使わなければならない(MUST)。ハッシュ関数の結果は、160 bit 数として扱われ、DSA 署名アルゴリズム中で直接、使用される。

5.2.3. v4 署名パケットフォーマット English

v4 の署名パケットには、下記の項目が含まれる。

署名されるデータは、ハッシュされ、次に Signature パケットのバージョン番号からハッシュサブパケットデータ(含まれる)までがハッシュされる。そのハッシュ値の結果が署名されたものである。ハッシュ値の左の 16 bit は、不正な署名を拒絶する簡易テストをするため、Signature パケットの中に含まれる。

Signature サブパケットが構成するふたつのフィールドがある。ひとつは、Signature パケットデータ(残りの部分)をハッシュした値であり、もうひとつは、ハッシュしていない値である。サブパケットのふたつめのフィールドは、署名による暗号で守られていないため、アドバイス的情報のみが含まれる必要がある。

ハッシュ関数から署名に変換する方式は、以降の節で解説する。

5.2.3.1. 署名サブパケットの仕様 English

サブパケットフィールドは、0 個以上の Signature サブパケットから構成される。サブパケットの集合ごとに、その集合の長さを表す 2 オクテットのスカラーカウントが前につく。

各サブパケットは、ヘッダとボディで構成される。ヘッダ部の構成は、下記のようになる。

そして、サブパケット特定のデータがつづく。
  

長さには Subpacket Type オクテットも含まれるが、この長さではない。長さの形式は、「新しい」パケット形式のレングスヘッダに似ているが、Partial Body Lengthは使用できない。Subpacket Length は、下記のようになる。

       1 番目のオクテットが 192 未満の場合、
           lengthOfLength = 1
           subpacketLen = 1st_octet

       1 番目のオクテットが 192 以上 255 未満の場合、
           lengthOfLength = 2
           subpacketLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192

       1 番目のオクテットが255の場合、
           lengthOfLength = 5
           subpacket length = [2番目のオクテットからの4オクテットスカラー]
   

Subpacket Type のオクテット値は、下記のいずれかになるであろう。

       2 = signature creation time (署名作成日時)
       3 = signature expiration time (署名有効期間)
       4 = exportable certification (エクスポート可能証明)
       5 = trust signature (信用度の署名)
       6 = regular expression (正規表現)
       7 = revocable (無効化可能)
       9 = key expiration time (鍵有効期間)
       10 = placeholder for backward compatibility (下位互換性のための記入子)
       11 = preferred symmetric algorithms (共通鍵暗号アルゴリズム設定)
       12 = revocation key (無効化権限のある鍵)
       16 = issuer key ID (発行者の鍵ID)
       20 = notation data (メモ日付)
       21 = preferred hash algorithms (ハッシュアルゴリズムの設定)
       22 = preferred compression algorithms (圧縮アルゴリズムの設定)
       23 = key server preferences (鍵サーバの設定)
       24 = preferred key server (優先鍵サーバ)
       25 = primary user id (プライマリユーザID)
       26 = policy URL (ポリシーURL)
       27 = key flags (鍵フラグ)
       28 = signer's user id (署名者のユーザID)
       29 = reason for revocation (無効化の理由)
       100 to 110 = internal or user-defined (内部もしくはユーザ定義に利用)
   

実装は、認識できない Subpacket Type を無視する必要がある(SHOULD)

Subpacket Type のビット 7 は、「Critical(重要)ビット」である。ビット 7 が 1 である場合、それは、署名評価側(evaluator)にとって重要なサブパケットであることを示す。Criticalビットが1のサブパケットを受け取った評価側ソフトウェアがその Subpacket Type を知らない場合、評価側(evaluator)は、その署名をエラーと認識する必要がある(SHOULD)

評価側は、Subpacket Type を「認識」してもよいが、実装しなくてもよい。Critical ビットの目的は、評価側の未知な機能を無視するのではなくエラーとして警告を出し、評価側に署名者が新しい機能を使用していることを伝えることにある。

実装には「選択設定(preferences)」を実装する必要がある(SHOULD)

5.2.3.2. 署名サブパケットの種類 English

現在、多くのサブパケットが定義されており、いくつかのサブパケットは署名に、いくつかは、鍵の属性に適用されている。Self-Signature 上に見られるサブパケットは、鍵自身が発行するユーザ ID 証明書の中に置かれる。注意として、鍵は、ひとつ以上のユーザ ID をもつことが可能であるので、鍵にはひとつ以上の Self-Signature や多種サブパケットを有することが可能となる。

Self-Signature とは、署名が参照する鍵によって作成された Binding Signature である。Self-Signature には、次の 3 種類がある。:Certification Signature(0x10-0x13タイプ) 、Direct-key Signature(0x1fタイプ)、Subkey Binding Signature(0x18タイプ)。Certification Self-Signature では、各ユーザ ID は、Self-Signature をもつ場合があり、したがって、それぞれの Self-Signatures 内に異なるサブパケットを有する場合もある。Subkey Binging Signature では、各Subkey は Self-Signature をもっている。Certification Self-Signature にあるサブパケットは、ユーザ名に適用され、Subkey Self-Signature にあるサブパケットは、Subkey に適用される。Direct-Key Signature 上のサブパケットは、鍵全体に適用される。

OpenPGP 実装のソフトウェアは、Self-Signature の設定サブパケット(Preference subpackets)をなるべく狭義に解釈する必要がある。例えば、鍵がふたつのユーザ名、Alice と Bob をもっていると仮定する。Alice は、共通鍵暗号に CAST5 を設定し、Bob は、IDEA もしくは Triple-DES を設定する。ソフトウェアがこの鍵をAlice の名前で位置づけた場合、設定された暗号アルゴリズム(preferred algorithm)は、CAST5 である。同様に、ソフトウェアがこの鍵を Bob の名前で位置づけた場合、設定される暗号アルゴリズムは、IDEA となる。鍵が鍵 ID で位置づけられた場合は、鍵のデフォルトユーザ ID が設定した暗号アルゴリズムがデフォルトの共通鍵暗号アルゴリズムとなる。

サブパケットは、署名データのハッシュサブパケット部分、ハッシュしないサブパケット部分のどちらかに有する場合がある。サブパケットがハッシュしていない場合、(それは正式な署名の一部ではないことから)その中の情報は信頼がおけるものではない。

5.2.3.3. 署名作成日時 English

(4 オクテットのタイムフィールド)

署名が作成された時間

ハッシュされたサブパケットになければならない(MUST)

5.2.3.4. 発行者 English

(8 オクテットの鍵 ID)

署名を発行している鍵の OpenPGP キー ID

5.2.3.5. 鍵の有効期間 English

(4 オクテットのタイムフィールド)

鍵の有効期間。これは、鍵作成時間から鍵の期限が切れるまでを秒数で表している。このフィールドが存在しないか、あるいは、ゼロの値の場合、鍵が無期限であることを意味する。これは Self-Signature にのみ存在する。

5.2.3.6. 選択された共通鍵暗号アルゴリズム English

(1 オクテット値のシークエンス)

鍵保持者が使用したい共通鍵暗号アルゴリズム ID を示す。このサブパケット内容は、優先する暗号アルゴリズム ID を先頭にオクテットで表したリストとなる。リストされる暗号アルゴリズムのみが受信者のソフトウェアにサポートされていると仮定される。暗号アルゴリズム ID については 9 章を参照すること。これは、Self-Signature にのみ存在するサブパケットである。

5.2.3.7. 選択されたハッシュアルゴリズム English

(1 オクテット値の配列)

鍵保持者が受領したいメッセージダイジェスト方式 ID を示す。共通鍵暗号アルゴリズムの設定のように優先するものを先頭にリストされる。メッセージダイジェスト方式 ID については、6 章を参照。これは、Self-Signature にのみ存在するサブパケットである。

5.2.3.8. 選択された圧縮アルゴリズム English

(1 オクテット値の配列)

鍵保持者が使用したい圧縮アルゴリズムの ID を示す。共通鍵暗号アルゴリズムの設定のように優先するものを先頭にリストされる。圧縮アルゴリズム ID については、6 章を参照する こと。このサブパケットが含まれていない場合、ZIP が自動的に設定される。ゼロのとき、圧縮しない設定である。(なぜならば)鍵保持者のソフトウェアには圧縮ツールが実装されていない場合があるからである。これは、Self-Signature にのみ存在するサブパケットである。

5.2.3.9. 署名の有効期間 English

(4 オクテットのタイムフィールド)

署名の有効期間。これは、署名作成時間から期限切れになるまでの時間を秒単位で表す。これがない場合、もしくはゼロ値の場合、鍵は無期限である。

5.2.3.10. エクスポート可能な証明書  English

(1 オクテットのエクスポート属性:0 は無し、1 はエクスポート可能)

このサブパケットは、「Certification Signature がエクスポート可能か(署名発行者よりも、その他のユーザが使用する署名)どうか?」を示す。パケットボディには「署名がエクスポート可能であるか否か?」を示すブールフラグ(boolean flag)が含まれる。このパケットが存在しない場合、Certification は、Exportable(エクスポート可能)である。すなわち、フラグが 1 であることと同じ意味を指す。

エクスポートしないもの、すなわち「Local」Certification の場合、Certification は、ユーザが使っているプログラム内のみで鍵が有効であることを示すときに作成される。それゆえ、もうひとりのユーザに鍵を転送するために鍵のコピーを実装が準備するとき(鍵の"Export" プロセス)、すべての Local Certification Signature は、鍵から削除される。

転送した鍵の受領側は、その鍵を「インポート(import)」し、同様にすべての Local Certification を削除する。通常の処理では、そこには Local Certification 等はなく、インポートはエクスポートされた鍵(exported key)であると仮定して処理している。しかし、これが意味をなす場合がある。例えば、エクスポートされた鍵に追加してキーデータベースから同じ鍵のインポートをさせる実装の場合、そのような状況が考えられる。

いくつかの実装(訳注:プログラム)は、各ユーザについて関心を表さない。(例: 鍵サーバ等)このような実装は、それらが取り扱うすべての鍵から常に Local Certification を削る。

5.2.3.11. 失効可能 English

(1 オクテットの無効化可能属性:0 は無効化が不可能、1 は可能)

署名の失効可能性(Revocability)についての状態。パケットボディは、「署名が失効可能か否かか?」を示すブールフラグを含む。Revocable が不可能な署名は、どのような Revocable Signature も無視する。それは、署名者自身が自分の署名を彼の鍵が有効な限り失効できないことを宣言していることを表す。このパケットが存在しない場合、署名は 失効可能である。

5.2.3.12. トラスト署名 English

(1 オクテットの"レベル"(深さ)、1 オクテットの信用度(trust amount))

署名者は、鍵が有効(valid)であるだけでなく、指定レベルにおいて信用する価値(trust worthy)があることを主張している。

レベル 0 は、通常の有効(valid)な署名と同じ意味をもつ。レベル 1 は、署名された鍵が有効な Trusted Introducer(信用する紹介者)であることを意味し、信用の度数は、パケットボディの 2 番目のオクテットが示す。

レベル 2 は、レベル 1 のトラスト署名(Trust Signature)を発行することにおいて信用されている、すなわち、「メタ紹介者(Meta Introducer)」を指す。

一般的に、レベル n のトラスト署名は、鍵がレベル n-1 のトラスト署名を発行することにおいて信用する署名である。

信用度(Trust Amuount)の幅は、0〜255 であり、

120以上の場合、Complete Trust(完全な信用)を意味する。

実装は、60 の値を Partial Trust とし、120 の値を Complete Trust として発行する必要がある(SHOULD)

5.2.3.13. 正規表現 English

(ヌルで終わる正規表現)

拡張していく信用の有効範囲を制限するため、(レベル 1 以上の)Trust Signature パケットの論理積で使用される。このパケットの正規表現と 一致するユーザ IDをもつ鍵による署名のみが Trust Signature サブパケットにより拡張された信用をもつ。正規表現は、Henry Spencer の "almost public domain" 正規表現パッケージと同じ構文を使用する。構文の説明については、以降の節において解説する。

5.2.3.14. 失効鍵 English

(1 オクテットのクラス分け、1 オクテットのアルゴリズム ID(algid)、20 オクテットのフィンガープリント)

指定された鍵にある鍵の失効署名(Revocation Signature)発行権限を与える。分類オクテットは、必ず 0x80 でなければならない。ビットが 0x40 であるとき、「失効情報は、 取扱に注意を要すること」を意味する。他のビットセットは、将来の他の権限への拡張に与えられている。これは、Self-Signature 中に見られる。

'sensitive' フラグが設定されている場合、鍵保持者は、このサブパケットには現実社会の取扱に注意を要する関係を示すプライベートな信用情報が含まれていると考える。このフラグが設定されているとき、データが特に必要な場合を除いて(署名を指定の 失効者(Revoker)に送信するか、あるいは、失効者からの Revocation Signature が伴っているとき等)、実装は、他のユーザ宛に、この署名をエクスポートしてはいけない(SHOULD NOT)。他のエクスポートが必要なサブパケットとの混合を防ぐために、このサブパケットを別の署名に隔離することが適切な場合もあることに注意。

5.2.3.15. メモデータ English

       (4オクテットのフラグ、2 オクテットの名前の長さ(M)、
                              2 オクテットの値の長さ(N)、
                              M オクテットの名前データ、
                              N オクテットの値のデータ)
        

このサブパケットは、署名発行者が希望する署名上の「メモ(notation)」である。メモには名前と値がありそれぞれは文字列のオクテットである。署名の中には、ひとつ以上のメモを有することがある。メモは、署名の発行者が注意するすべての拡張に使用可能である。「フラグ」フィールドは、4 オクテットのフラグを有する。

すべての定義していないフラグは、必ずゼロにしなければならない(MUST)。定義されたフラグを以下に示す。

      1 番目のオクテット:0x80 = 人間が解読可能。このメモは、ひとりひとりへのテキストのメモであり、ソフトウェアには関係ない。

       その他のオクテット:なし
        

5.2.3.16. 鍵サーバの選択 English

(N オクテットのフラグ)

これは、フラグのリストであり、鍵サーバ上での鍵の取り扱いについての鍵保持者の設定を示す。すべての定義しないフラグは、ゼロでなければならない(MUST)

   最初のオクテット:0x80 = 修正しない(no-modify)
       鍵保持者(key holder)は、この鍵が鍵保持者もしくは鍵サーバの管理
       者のみ修正・アップデート可能であることを要求している。

これは、自己署名(Self-Signature)にのみ、在る。

5.2.3.17. 選択された鍵サーバ English

(文字列)

これは、鍵保持者がアップデート用に設定する鍵サーバの URL である。複数のユーザ ID をもつ鍵は、各ユーザ ID ごとに鍵サーバの設定ができることに注意すること。また、これが URL である ので、鍵サーバは、ftp、http、 finger 等から検索される鍵のコピーでありえることに注意すること。

5.2.3.18. プライマリユーザ ID English

(1 オクテット、ブーリアン)

これは、ユーザ ID の Self-Signature の中のフラグで、このユーザ ID は、鍵に対 してメインのユーザ ID であるか否かを示す。Primary UserID と関連づけることによって、設定の曖昧性を解決するような実装には合理的である。このフラグをもたない場合、その値は、ゼロを意味する。複数のユーザ ID が Primary であるとマークされている場合、実装は、何らかの方法によって、その曖昧性を解決してもよい。

5.2.3.19. ポリシー URL English

(文字列)

このサブパケットは、署名が発行されたポリシーを解説する文書の URL を含む。

5.2.3.20. 鍵フラグ English

(文字列のオクテット)

このサブパケットは、鍵の情報をもつバイナリーフラグのリストを含む。これは、文字列のオクテットで実装は固定的なサイズを仮定してはならない(MUST NOT)。これによって、将来的にサイズが大きくなっても適用できるようにしている。実装の予測よりリストが短い場合、状態を示さないフラグ(unstated flags)は、ゼロと認識される。定義済みのフラグは、下記のようになる。

1 番目のオクテット:

0x01 - この鍵は、その他の鍵の証明に使用している場合がある。

0x02 - この鍵は、データへの署名に使用している場合がある。

0x04 - この鍵は、通信の暗号化に使用している場合がある。

0x08 - この鍵は、ストレージの暗号化に使用している場合がある。

0x10 - この鍵の秘密要素は、secret-sharing(秘密共有)メカニズムによって、分離されている可能性がある。

0x80 - この鍵の秘密要素は、ひとり以上が所有している場合がある。

用法についての注意:

このパケットのフラグは、Self-Signature もしくは Certifiction Signature の中に現れる場合がある。それらは、「誰がそのステートメントを作成したか?」によって意味が異なる。(例えば、「データへの署名」フラグを含む Certification Signature は、証明がデータ署名のためにあると述べている。)また、一方、Self-Signature の中の「通信の暗号化」フラグは、与えられた鍵を通信に使用する設定を表している。しかし、何が「通信(Communication)」を指し、何が「記憶(Storage)」を指すかの定義は難しい問題である。そこで、この定義をすべて実装に委ねることとする。本書の著者は、この争点について特別な意見を特に要求せず、また、認められた意見は、今後、変化する可能性がある点を認識する。

「Split Key」(0x10)フラグと「Group Key」(0x80)フラグは、Self-Signature のみに存在する。これらのフラグは、Certification Signature には意味がない。これらは、Direct-Key Signature(0x1f タイプ)や Subkey Signature(0x18 タイプ)、フラグが適用する鍵に関連のあるものにのみ使用する必要がある(SHOULD)

5.2.3.21. 署名者のユーザ ID English

このサブパケットによって、鍵保持者は、「署名(行為)の責任をもつのは、どのユー ザ ID か?」を表すことができる。多くの鍵保持者は、ひとつの鍵を複数の用途、例えば、個人での通信時と同様に仕事上でも使用したりする。このサブパケッ トは、そのような鍵保持者に、どの用途で署名を作成したのかを表すことを可能にする。

5.2.3.22. 失効の理由 English

   (1 オクテットの失効(Revocation)コード、N オクテットの理由の文字列)

このサブパケットは、Key Revocation Signature(鍵の失効署名)と Certification Revocation Signature(証明を失効する署名)の中でのみ使用される。これは、鍵や証明書が 失効された理由を説明する。

1 番目のオクテットは、失効の理由を表した機械可読コードを含む。

0x00 - 理由なし(Key RevocationかCertification Revocations)
0x01 - 鍵は更新された(Key Revocations)
0x02 - 鍵素材の障害(Key Revocations)
0x03 - もう使用されない鍵(Key Revocations)
0x20 - ユーザID情報はもう有効ではない(Certification Revocations)

Revocation Code(失効コード)の後に文字列のオクテットが続き、文字列は、可読形式(UTF-8)で失効の理由を表す。その文字列は、ヌルの場合もあり、すなわち長さがゼロである。サブパケットの長さは 、理由の文字列の長さプラス 1 となる。

5.3. 共通鍵で暗号化されたセッション鍵パケット(Tag 3) English

共通鍵で暗号化された ESK(Symmetric-Key Encrypted Session Key:暗号化セッション鍵)パケットは、メッセージの暗号化に使用したセッション鍵を共通鍵暗号で暗号化したものを格納する。0 個以上の ESK パケット、かつ/または、Symmetric-Key Encrypted Session Key パケットは、暗号メッセージを含む Symmetrically Encrypted Data(共通鍵暗号データ)パケットの前に位置する可能性がある。メッセージは、セッション鍵で暗号化され、セッション鍵は、暗号化されて Encrypted Session Key パケットもしくは Symmetric-Key Encrypted Session Key パケットに格納される。

Symmetrically Encrypted Data パケットにひとつ以上の Symmetric-Key Encrypted Session Key パケットが前に位置した場合、各パケットは、メッセージ復号に使用する可能性があるパスフレーズを指定する。これによって、メッセージは、複数の公開鍵で暗号化でき、また複数のパスフレーズで暗号化することも可能となる。このパケットタイプは、新しく、PGP 2.x や PGP 5.0 では生成しない。

このパケットボディは、下記のように構成される。

Encrypted Session Key が存在しない場合(これはパケットレングスと S2K 識別子のサイズに基づいて判断可能)、パスフレーズに適用した S2K 方式は Symmetric-Key Encrypted Session Key パケットの共通鍵暗号アルゴリズムを使用して、ファイル復号のためにセッション鍵を作成する。

ESKが存在する場合、パスフレーズに適用した S2K 方式の結果は、IV(Initial Vector)がすべてゼロの CFB モードを利用して、encrypted session key フィールドの復号に使用される。復号結果には、1 オクテットの暗号識別子(後ろに続く Symmetrically Encrypted Data パケットに使用した共通鍵暗号アルゴリズムを示す)が含まれ、セッション鍵オクテット自身が後ろに続く。

(注意) すべてゼロの IV がこの復号に使用されるため、S2K 識別子は、Salt 値(Salted S2K か Iterated-Salted S2K のいずれか)を必ず使わなければならない(MUST)。Salt 値は、パスフレーズが再利用されても復号鍵は繰り返されないことを保証する。

5.4. One-Pass 署名パケット(Tag 4) English

One-Pass Signature パケットは、署名データの前に位置し、受信者が署名を確認するためのハッシュ計算を早めに開始するために十分な情報が含まれる。これによって、署名パケットはメッセージの後に置かれていてもメッセージ全体への署名を一度(OnePass)で計算できる。(*訳注:通常、署名は、メッセージの後のみにある)

このパケットボディの構成は、下記のようになっている。

メッセージがひとつ以上の One-Pass Signature で構成される場合、Signature パケットは、メッセージを括弧に入れる点に注意。つまり、メッセージの後に来る最初の Signature パケットは最後の One-Pass パケットと対応づけられ、最後の Signature パケットは、最初の One-Pass パケットと対応づけられている。(*訳注:要するに入れ子構造(ネスト)である)

5.5. 鍵素材パケット English

Key Material パケットは、公開鍵と秘密鍵のすべての情報を含む。このパケット種別には 4 つの変型(variants)とふたつの主要版(major version)がある。したがって、この節は、複雑である。

5.5.1. 鍵パケットの変型 English

5.5.1.1. 公開鍵パケット(Tag 6) English

Public Key パケットは、OpenPGP の鍵(しばしば OpenPGP Certification と呼ばれる)を形成する連続したパケットの最初に位置する。

5.5.1.2. 公開サブキーパケット(Tag 14) English

Public Subkey パケット(公開サブキーパケット)(タグ14)は、Public Key パケッ トとまったく同じ形式でサブキーを表している。ひとつ以上のサブキーは、トップレベルキーと関連がある場合もある。規則として、トップレベルキーは、署名サービスを提供し、サブキーは、暗号化サービスを提供する。

(注意) PGP 2.6.x では、タグ 14 は、コメントパケットにする予定であった。以前の PGP は、コメントパケットを発行せず無視したため、このタグは、再利用されることとなった。Public Subkey パケットは、PGP 2.6.x では認識しないがエラーも出さず、限られた下位互換性を保つ。

5.5.1.3. 秘密鍵パケット(Tag 5) English

Secret Keyパケットは、Public Key パケットにあるすべての情報を含む。その公開鍵素材のみならず、Public Key フィールドの後ろに秘密鍵素材等の情報も含まれる。

5.5.1.4. 秘密サブキーパケット(Tag 7) English

Secret Subkey パケット(タグ7)は、Secret Key パケットと類似するサブキーであり、まったく同じ形式をもつ。

5.5.2. 公開鍵パケットの形式 English

鍵素材パケットにはふたつのバージョンがある。v3 は、最初に PGP 2.6 にて生成されたものである。v2 は、v3 のパケットと似た形式であるが、PGP 2.5 以前のバージョンにて生成される。V2パケットは推奨されず、生成されてはならない(MUST NOT)。PGP 5.0 では、新しいフィールドとセマンティックと共に v4 を提供した。PGP 2.6.x は、v3 より新しい鍵素材パケット(*訳注:v4 以上を指す)を認識できない。

OpenPGP の実装は、v4 の鍵を作成する必要がある(SHOULD)。実装は、古いソフトウェアとの相互運用を確実にする目的で v3 の鍵を生成してもよい(MAY)。しかし、注意として、v4 鍵は、v3 鍵の中のいくつかのセキュリティ欠陥を訂正している点がある。これらの点については後述する。実装は、RSA 以外の公開鍵方式で v3 鍵を生成してはならない(MUST NOT)

v3 の Public Key パケットと Public Subkey パケットは、下記のように構成される。

     - 1オクテットのバージョン番号(3)

     - 4オクテットの数字で鍵の作成時間を示す。

     - 2オクテットの数字でこの鍵の有効期間を日数で表現。この数字がゼロの場合、鍵は無期限に有効である。

     - 1オクテットの番号で、この鍵の公開鍵方式を示す。

     - 鍵素材を含む、連続するMulti-Precision Integerである。

	 - RSA公開モジュールnの、multiprecision integer(MPI)

	 - RSA公開暗号指数eの、MPI  

v3 鍵には、下記の 3 つの弱点があるため下位互換性にのみ使われる必要がある (SHOULD)

第 1 に、鍵IDが単に公開モジュールの下位 64 bit であるため、ほかの鍵 ID と同じ鍵 ID をもつ v3 の鍵を作ることは比較的簡単である。

第 2 に、v3 の鍵のフィンガープリントは鍵材料をハッシュするが、その長さをハッシュしていないためにフィンガープリント衝突の機会を増やしている。

第 3 に、MD5 ハッシュ方式にマイナーな欠点があるため、開発者が他の方式を好んでいる点がある。

鍵 ID とフィンガープリントのより完全な議論については、後述する。

v4 の形式は、有効期間がない点以外は v3 と似ている。有効期間のサブパケットは、Signature パケットに移動された。また、v4 の鍵は、"Enhanced Key Format" の節において後述されるように、v3 の鍵と異なる計算をする。

v4 のパケットには下記の項目が含まれる。

     - 1 オクテットのバージョン番号(4)

     - 4オクテットの数字、鍵の作成時間を示す。

     - 1オクテットの数字、この鍵の公開鍵方式を示す

     - 鍵素材を含んでいる連続したMulti-Precision integers。
       この方式に特定の部分は下記のとおりである。

       RSA公開鍵の特定フィールド:
	 - RSA公開モジュールnのMulti Precision Integer(MPI)
	 - RSA公開暗号指数eのMPI

       DSA 公開鍵の特定フィールド:
	 - DSA 素数pのMPI;
	 - DSA 群の位数(group order)q のMPI(q はp-1 を割り切れる素数);
	 - DSA 群の元(group generator)gのMPI;
	 - DSA公開鍵の値y(= g**x xは秘密である)のMPI

       Elgamal公開鍵の特定フィールド:
	- Elgamal 素数pのMPI;
	- Elgamal 群の元(group generator)gのMPI;
	- Elgamal公開鍵の値y(=g**x xは秘密である)のMPI    

5.5.3. 秘密鍵パケットのフォーマット English

Secret Key と Secret Subkey パケットには、Public Key と Public Subkey パケットのすべてのデータが含まれ、(その後ろに)アルゴリズム特定の秘密鍵データが暗号化された形で追加される。

このパケットには下記の項目が含まれる。

     - 前節で説明した Public Key もしくは Public Subkey パケット

     - String-To-Key 使用法を示した1オクテット。
         0は秘密鍵データが暗号化されていないことを示し、
         255はString-To-Key識別子が与えられていることを示す。
         それ以外の値は、共通鍵暗号アルゴリズム識別子を示す。

     - [オプション] String-To-Key 使用法オクテットが 255 ならば、1 オクテットの共通鍵暗号アルゴリズム

     - [オプション] String-To-Key 使用法オクテットが 255 ならば、S2K識別子
       である。先で述べたように S2K 識別子の長さはそのタイプが示す

     - [オプション] 秘密データが暗号化されている場合、8オクテットの初期ベクタ(IV)

     - 秘密鍵データを含む暗号化されたMulti-Precision Integers。これら暗号特定フィールドについては後述する。

     - アルゴリズム特定部分のプレーンテキストの 2オクテットのチェックサム(すべてのオクテットの合計で、65536を法とする)

       RSA秘密鍵の特定フィールド:
       - RSA秘密指数dのmultiprecision integer(MPI)
       - RSA秘密素数値pのMPI
       - RSA秘密素数値q(p < q)のMPI
       - uのMPI、pの乗法的逆元を法qで還元(mod)したもの

       DSA秘密鍵の特定フィールド
       - DSA秘密指数xのMPI
 
       Elgamal秘密鍵の特定フィールド
       - Elgamal秘密指数xのMPI
        

秘密の MPI 値は、パスフレーズによって暗号化することができる。S2K 識別子が与えられたとき、パスフレーズの鍵への変換方式を示し、無い場合、パスフレーズはシンプル MD5 ハッシュを採用している。実装は、S2K 識別子を使用する必要がある(SHOULD)。(なぜならば)シンプルハッシュは、下位互換性のために存在するからである。MPI の暗号化方式は、Secret Key パケット中に指定される。

秘密データの暗号化/復号は、パスフレーズから作成された鍵とパケットからの初期ベクタ(Initial Vector)を使ってCFB モードで行われる。v3 鍵(RSA のみ)では異なるモードが使用される。v3 の鍵では、MPI のビットカウント Prefix(つまり最初の 2 オクテット)は、暗号化されない。MPI の Non-Prefix データのみが暗号化される。さらに、CFB ブロックの境界(CFB block boundary)は、MPI データの開始にあわせられるため、CFB 状態は新しい MPI 値ごとに再同期される。

v4 の鍵では、より単純な方法が利用される。すべての秘密の MPI 値は、MPI ビットカウント Prefix を含む CFB モードで暗号化される。

アルゴリズム特定部分の後にある 16 bit のチェックサムは、MPI の Prefix とデータを含めたアルゴリズム特定オクテットのプレーンテキストの代数合計である(法 65536 で還元(mod)したもの)。v3 鍵ではチェックサムは暗号化されずに格納される。v4 鍵では、チェックサムはアルゴリズム特定データのように暗号化されて格納される。このチェックサムの値は、パスフレーズの正当性確認に使用される。

5.6. 圧縮データパケット(Tag 8) English

Compressed Data パケット(圧縮データパケット)には、圧縮データが格納される。一般的に、このパケットは、暗号化パケットや後ろに続く Signature や One-Pass Signature パケットの中で見受けられ、Literal Data パケットを含む。

このパケットには、下記の項目が含まれる。:

Compressed Data パケットのボディは、いくつかのパケットセットを圧縮したブロックを含む。メッセージ形成の詳細については、「パケットの構成」の章を参照。

ZIP-compressed パケット(ZIP 圧縮パケット)は、RFC 1951 DEFLATE 形式のブロックで圧縮される。PGP V2.6 は、13 bit の圧縮を使用する点に注意すること。実装でより多くのビットの圧縮を使用する場合、PGP v2.6 は、それを解凍できない。

ZLIB-Compressed パケット(ZLIB 圧縮パケット)は、RFC 1950 ZLIB 形式のブロックで圧縮される。

5.7. 共通鍵暗号化データパケット(Tag 9) English

Symmetrically Encrypted Data パケット(共通鍵暗号データパケット)には、共通鍵暗号アルゴリズムで暗号化されたデータが格納される。復号したとき、通常、中にはパケット(しばしば Literal Data パケットか Compressed Data パケット)が含まれる。

このパケットボディには下記の項目が含まれる。:

使用される共通鍵暗号アルゴリズムは、Symmetric-Key Encrypted Data パケットの前に位置する Public-Key か Symmetric-Key Encrypted Session Key パケットの中で指定される場合がある。その場合、暗号アルゴリズムオクテットは、セッション鍵が暗号化される前にセッション鍵に Prefix される。このようなパケットが Encrypted Data パケットの前にない場合は、パスフレーズの MD5 ハッシュをセッション鍵を IDEA 共通鍵暗号アルゴリズムを使用する。

データは、暗号ブロックサイズを CFB シフトサイズとした CFB モードで暗号化される。初期ベクタ(IV)は、すべて 0 とする。初期ベクタの代わりに、OpenPGP は 、データを暗号化する前に 10 オクテットの文字列を Prefix する。最初の 8 オクテットは、ランダムで、9 番目と 10 番目のオクテットは、7 番目と 8 番目のオクテットのコピーとなる。最初の 10 オクテットを暗号化した後、暗号ブロックサイズが 8 オクテット以下ならば CFB ステートは再同期(resynchronaiz)される。暗号テキストの最後の 8 オクテットの暗号が終わった後、ブロックの境界は、リセットされる。

ランダムデータ 80 bit 中の16 bit の繰り返しビットはメッセージの前に位置し、それによって、受信者は、セッション鍵の正当性をすぐに確認できる。

5.8. マーカーパケット(廃止されたリテラルパケット)(Tag 10) English

PGP の実験バージョンは、このパケットを Literal パケットとして使用していたが、PGP のリリースバージョンは、このタグで Literal パケットを生成しなかった。PGP 5.x では、このパケットは再設定され、Marker パケットとして確保されている。

このパケットボディには、下記の項目が含まれる。:

このようなパケットは、受信時には無視されなければならない(MUST)。Marker パケットは、メッセージの前に置かれる場合もあり、そのメッセージは、PGP 2.6.x にない機能を使用しており、そのバージョンでメッセージを処理するためには新しいソフトウェアが必要であることを報告する。

5.9. リテラルデータパケット(Tag 11) English

Literal Data パケットには、メッセージボディが入る。データは、それ以上解釈されない。

パケットボディには、下記の項目が含まれる。:

フィールド値が「b」(0x62)である場合、Literal パケットは、バイナリーデータを含む。フィールド値が「t」(0x74)である場合、Literal パケットは、テキストデータであり、したがってラインの終わりをローカルの形式か、その他のテキストモードへ変換することが必要になることもある。また、RFC 1991 では、マシンローカル変換(machine-local conversions)のために「l」を「local」モードと定義している。この使用法は 、今では推奨されていない。

特別な名前である「CONSOLE」がここで使われている場合、メッセージは、「親展(for your eyes only)」として考えられる。このアドバイスによって、メッセージは、非常に機密であると考えられ、受領側の実装は、例えば、データをディスクに保存することを避ける等、そのメッセージをより注意深く扱うようにする必要がある。

テキストデータは、<CR><LF> のテキストエンディング(例: 通常のネットワーク 用行終端子)を使って保存される。これらは受信側のソフトウェアによって本来の行終端子に変換される必要がある。

5.10. トラストパケット(Tag 12) English

トラストパケットは、鍵リングの中でのみ使用され、通常はエクスポートされない。トラストパケットは、実装ソフトが扱うその他の信用情報と共に、どの鍵保持者が信用できる紹介者であるかのユーザ指定データを含む。

トラストパケットは、他のユーザに送信される出力ストリームに発行されてはいけない(SHOULD NOT)。ローカル鍵ファイル以外からの入力は、無視される必要がある(SHOULD)

5.11. ユーザ ID パケット(Tag 13) English

UserID パケットは、鍵保持者の名前や e メールアドレスから成る。規則によって、RFC 822 形式のメールアドレスを含んでいるが内容に関する制約はない。ヘッダ中のレングスパケットは、ユーザ ID の長さを示す。それがテキストの場合、UTF-8 でエンコードされている。

 

6. Radix-64 変換 English

「はじめに」で定義されたとおり、OpenPGP のオブジェクトの基本表現は、任意のオクテットストリームであり、いくつかのシステムではキャラクターセット変換、データ変換その他に起因する障害に対して免疫性が要求される。

原則として、安全でないチャネルでの要求事項を満足させるプリンタブル(Printable)エンコードスキームであれば、OpenPGP の基本データ構造であるバイナリビットストリームを変更しないことから、十分であると考えられる。OpenPGP の規格は、確実な相互運用のために、あるプリンタブルエンコードスキームを指定している。

OpenPGP の Radix-64 エンコーディングは、ふたつの部分、バイナリデータの base64 エンコードとチェックサムから成る。base64 エンコーディングは、MIME base64 content-transfer-encoding「RFC 2045 の 6.8 節(*訳 注:原文[RFC 2231 Section 6.8] を訂正)」と同一である。OpenPGP の実装には、バイナリデータを守るためにASCII Armor を使用してもよい(MAY)

チェックサムは、24 bit の CRC を MIME base64 変換と同じ方法で 4 つの radix-64 キャラクタに変換したもので、等号(=)が前につく。CRC は、0x864CFB 生成と 0xB704CE という初期値を使って計算される。データの累積は、radix-64 に変換されたデータ上ではなく、変換される前のデータ上で行われる。このアルゴリズムの実装サンプルについては、次節を参照。

チェックサムとその前の等号(=)は、Base64 エンコードデータの後の最初の行に表れる可能性がある(MAY)

(CRC-24 の根本的理由)24 bit というサイズは、すべてのプリンタブル base64 に適合する。ゼロ以外の値で初期化をすると、ゼロ値の初期化より多くのエラーを検出する。

6.1. C 言語による CRC-24 の実装 English

       #define CRC24_INIT 0xb704ceL
       #define 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;
       }
            

6.2. ASCII Armor の形成 English

OpenPGP がデータを ASCII Armor に変換するとき、後でデータを再構築できるようにデータの前後に特別なヘッダを付加する。OpenPGP は、ヘッダを使用することによって、どのような種類のデータが ASCII Armor に変換されたのかをユーザに表している。

下記のデータを連結することによって ASCII Armor を作成する。

Armor ヘッダ行は、ヘッダラインテキストの両側に 5 つのダッシュ('-',0x2D)がつくヘッダラインテキストによって構成される。ヘッダラインテキストは、Armor にエンコードされたデータタイプとエンコード方法によって選ばれる。ヘッダラインテキストには下記の文字列が含まれる。

   BEGIN PGP MESSAGE
       署名、暗号化、圧縮ファイルに使用

   BEGIN PGP PUBLIC KEY BLOCK
       ASCII Armor 変換された公開鍵に使用

   BEGIN PGP PRIVATE KEY BLOCK
       ASCII armor 変換された秘密鍵に使用

   BEGIN PGP MESSAGE, PART X/Y
       Multi-Part メッセージで使用され、Armor は Y 個のパーツに分けられた中の X 番目のパーツである。

   BEGIN PGP MESSAGE, PART X
       マルチパートメッセージに使用され、これは指定していない数にわけら
       れたパーツの x 番目のパーツである。MESSAGE-ID Armorヘッダの使用が必須。

   BEGIN PGP SIGNATURE
      Detached Signature、OpenPGM/MIME Signature、後に続くclearsigned メッセージに使用。PGP 2.x の「BEGIN PGP MESSAGE」は、Detached
      Signatureに使用される。
            

Armor ヘッダは、ペアの文字列で、ユーザや OpenPGP 受信用の実装にメッセージのデコード方法や使用法についての情報を与える。Armor ヘッダは、Armor の一 部であり、メッセージの一部ではない。したがって、メッセージに適用される署名から守られてはいない。

Armor ヘッダの形式は、キーとバリューが対になった形式で表される。コロン(':' 0x38)とスペース(0x20)が鍵と値を分けている。OpenPGP は、適切に形成されてない Armor ヘッダを ASCII Armor の破損として認識する必要がある。未知の鍵については、ユーザへ報告するべきであるが、OpenPGP は、メッセージを処理し続ける必要がある。

現在定義されている Armor ヘッダのキーは、下記のとおりである。:

MessageID は、Multi-Part メッセージでない限り、在ってはいけない(SHOULD NOT)。すべてのメッセージで表された場合、純粋なランダム値を含むのではなく、処理済み(暗号、署名等)メッセージから断定的(deterministic fashion)に計算しなければならない(MUST)。これによって、MessageID が変換されて暗号に関する鍵情報の漏洩の手段とならないことを適切な受信者は確定できる。

Armor テイル行(Armor Tail Line)は、文字列「BEGIN」が「END」に変わることを除いて Armor ヘッダ行(Armor Heder Line)と同じ方式で構成される。

6.3. バイナリを Radix-64 にエンコード English

エンコーディングプロセスは、24 bit の入力ビットグループを 4 つのエンコードキャラクタ文字列出力として表している。(この処理は、まず)左から右へ進み、3 つの 8 bit 入力グループを連結することによって、24 bit入力グループを形成する。これらの 24 bit は、4 つの連結した 6 bit グループとして取り扱われ、各 6 bit グループは、Radix-64 アルファベットの 1 桁に変換される。Radix-64 でビットストリームをエンコードするとき、ビットストリームは最有力ビット(most-significant-bit)が最初にくる配列であることが必ず仮定されている。すなわち、ストリームの最初のビットは、最初の 8 bit の上位ビットであり、8 番目のビットは、最初の 8 bit の下位ビットであり...となる。

         +--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--+
              

各 6 bit グループは、下表にある 64 個のプリンタブルキャラクタ配列のインデックスとして使用される。インデックスに関連づけられるキャラクターは、文字列として出力される。

     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
              

エンコードされた出力ストリームは、各行 76 文字以下で表さなければならない。

エンコードするデータの終わりが 24 bit 以下であった場合、特別な処理を実行する。その処理には 3 種類ある。

最後のデータグループが 24 bit(3 オクテット)のとき、特別な処理 は必要ない。

最後のデータグループが 16 bit(2 オクテット)のとき、最初の 6 bit グループは、上記のように処理される。3 つめの(不完全な)データグループは、ゼロが 2個追加されたあと、上記のように処理される。出力時には 、ひとつの pad charactor(=)が追加される。

最後のデータグループが 8 ビット(1 オクテット)のとき、最初の 6 bit グループは、上記のように処理される。ふたつめの(不完全な)データグループはゼロが 4 つ追加され、上記のように処理される。出力時には 2 個の pad charactor(=) が追加される。

6.4. Radix-64 のデコード English

base64 アルファベット以外のすべてのキャラクタは、Radix-64 データの中では無視される。デコードするソフトウェアは、すべての改行その他上記の表に無いキャラクタを無視しなければならない。

Radix-64 データの中では、おそらく、上記の表に無いキャラクタ、改行、その他スペース等は、トランスミッションエラーとして表され、それには警告メッセージやある環境下ではメッセージの拒絶等が適切な場合もある。

データの最後にパディングするときにのみ使われるので、どのような「=」キャラクタもデータの終端であると認識してもよい。(伝送中の切り捨てが無いと仮定。)そのような保証はできないが、伝送されるオクテット数が 3 の倍数であるとき、「=」キャラクターは、存在しない。

6.5. Radix-64 変換の例 English

     
       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. ASCII Armorメッセージの例 English

  -----BEGIN PGP MESSAGE-----
  Version: OpenPrivacy 0.99

  yDgBO22WxBHv7O8X7O/jygAEzol56iUKiXmV+XmpCtmpqQUKiQrFqclFqUDBovzS
  vBSFjNSiVHsuAA==
  =njUN
  -----END PGP MESSAGE-----
            

この例は、ふたつのスペースでインデントされていることに注意。

 

 

 

7. クリアテキスト署名のフレームワーク Englis

特別なソフトウェアを使用せず署名テキストが読みとれるので、ストリームを ASCII Armor せずに、原文のオクテットストリームへ署名することが望ましい。そのようなクリアテキストへ署名をバインドするために、このフレームワークが使用される。(注意: RFC 2015 において、MIME をサポートする環境では異なる方法を規定している。)

Cleartext 署名メッセージには、下記の項目含まれる。

「Hash」Armor ヘッダが与えられている場合、署名には指定されたメッセージダイジェスト方式が使われる。そのようなヘッダが無い場合、MD5 が使われ、実装は 、V2.x への互換性のためにそれらを省略してもよい(MAY)。複数のメッセージダイジェストが署名の中で使用された場合、「Hash」Armor ヘッ ダには使用したメッセージダイジェスト方式がコンマで区切ってリストされる。

現在あるメッセージダイジェストの名称は、アルゴリズム ID と共に後述する。

7.1. Dash-Escaped テキスト English

メッセージのクリアテキスト内容は、Dash-Escaped でなければななない。Dash-Escaped クリアテキストとは、通常のクリアテキストであり、すべての行は、ダッシュ ('-':0x2D)から始まり、ダッシュ('-':0x2D)の連続とスペース(' ':0x20)が前につく。これによって、パーサ(Parser:構文解析ツール)が、クリアテキストの Armor ヘッダをクリアテキストの一部であると認識することを防ぐ。メッセージダイジェストは、クリアテキスト上で計算しており、Dash-Escaped 形状上での計算ではない。

テキストドキュメントのバイナリ署名と同様に、Cleartext Signature は、標準 の <CR><LF> 行終端子を使用してテキストを計算する。署名データの終わりに来る「-----BEGIN PGP SIGNATURE-----」の前にある行終端子(例 : <CR><LF>)は、署名テキストの一部とは考えない。

また、Cleartext Signature が計算されるとき、行末のスペースは、すべて無視される。

 

8. 正規表現 English

正規表現は、「|」でわけられた 0 個以上の枝である。一致の対象は、枝で分かれた内のひとつと必ず一致する。

枝は、0 個以上の部分で構成され、連結している。各部分は、記述順(左から右)に沿って一致していく。

正規表現の各部分はアトムであり、「*」「+」「?」が後ろに続きアトムを修飾して正規表現を表すこともある。 「*」がつづくときは直前のアトムの 0 回以上の繰り返しを表す。(例:ab*d=ad,abd,abbd..)。 「+」が続くときはアトムの 1 回以上の繰り返しを表す。(例:ab+d=abd,abbd...)。「?」が続くときはそのアトムが 1 回あるか否かを表す。(例: ab?d=ad,abd)。

正規表現は、アトムの組み合わせから成り立つ。アトムは、以下のいずれかとなる。「()」丸括弧内の正規表現(正規表現に一致する)、正規表現の範囲(以下で解説)、「.」(改行以外の任意の一文字) 、「^」(入力文字列の最初がヌルで始まる)(訳注:文字の先頭)、「$」(入力文字列の最後がヌルで終わる)(訳注:文字の終端)、「\」(backslash)と任意の一文字(すぐ後ろに続く一文字と一致)、任意の一文字(その文字と一致) 。

正規表現の範囲は、「[]」で区切られた文字リストで表し、一致の対象は、通常その文字リストのいずれかと一致する。文字リストが「^」で始まるものは、後ろに続く文字リスト以外の任意の 1 文字と一致する(*訳注:文字集合内での否定)。文字リストの中の2文字が「-」で分けられている場合、これはその 2 文字の間のすべての ASCII 文字を示す短縮形であり、例えば、「[0-9]」という 正規表現はすべての一桁の数字(0 から 9)と一致する。文字リストに「]」等を含むときは(*訳注:メタキャラクタとして使われる文字を文字として表したい場合)、それを文字リストの最初の文字とする こと(「^」に続くこともある)。同様に、「-」を含むときは文字リストの最初か最後の文字にすること。

 

9. 定数 English

この章では OpenPGP で使用する定数について説明する。

注意: これらのテーブルは、完全なリストではない。実装は、これらのリストにないアルゴリズムの定数を作成してもよい(MAY)

アルゴリズムの詳細に関しては、後述する"Notes on Algorithm"の章を参照すること。

9.1. 公開鍵暗号アルゴリズム English

       ID           Algorithm
       --           ---------
       1	  - RSA(暗号と署名)
       2	  - RSA 暗号用
       3	  - RSA 署名用
       16	  - Elgamal(暗号用)、後述する[ELGAMAL]を参照
       17	  - DSA (Digital Signature Standard)
       18	  - (予約) 楕円形暗号
       19	  - (予約) ECDSA
       20	  - Elgamal(暗号と署名)
       21	  - (予約) Diffie-Hellman (X9.42:IETF-S/MIMEに定義)
       100 to 110 - 秘密/試験的アルゴリズム
                      

実装は、署名には DSA、暗号化には Elgamal を必ず実装しなければならない(MUST)。実装は、RSA の鍵を実装する必要がある(SHOULD)。実装は、他の暗号 アルゴリズムを実装してもよい(MAY)

9.2. 共通鍵暗号アルゴリズム English

       ID           Algorithm
       --           ---------
       0	  - Plaintextもしくは暗号化していないデータ
       1	  - IDEA [IDEA]
       2	  - Triple-DES(DES-EDE:192 bit ブロックに基づく 168 bit 鍵)
       3	  - CAST5 (128 bit 鍵、RFC 2144 に基づく)
       4	  - Blowfish (128 bit 鍵、16 ラウンド)[BLOWFISH]
       5	  - SAFER-SK128 (13ラウンド)[SAFER]
       6	  - (予約) DES/SK
       7	  - (予約) 128 bit 鍵の AES
       8	  - (予約) 192 bit 鍵の AES
       9	  - (予約) 256 bit 鍵の AES
       100 to 110 - 秘密/試験的アルゴリズム
                      

実装は、Triple-DES を必ず実装しなければならない(MUST)。実装は、IDEA と CAST5 を実装する必要がある(SHOULD)。実装は、その他の暗号アルゴリズムを実装してもよい(MAY)

9.3. 圧縮アルゴリズム English

       ID           Algorithm
       --           ---------
       0	  - 圧縮していない
       1	  - ZIP (RFC 1951)
       2          - ZLIB (RFC 1950)
       100 TO 110 - 秘密/試験的アルゴリズム
                      

実装は、データを圧縮しない実装を必ずしなければならない(MUST)。実装は、ZIP を実装する必要がある(SHOULD)。実装は、ZLIB を実装してもよい(MAY)

9.4. ハッシュアルゴリズム English

       ID           Algorithm                              Text Name
       --           ---------                              ---- ----
       1          - MD5                                    "MD5"
       2          - SHA-1                                  "SHA1"
       3          - RIPE-MD/160                            "RIPEMD160"
       4          - (予約) 2倍幅(double-width)のSHA (試験的)
       5          - MD2                                    "MD2"
       6          - (予約) TIGER/192のため予約            "TIGER192"
       7          - (予約) HAVAL(5 pass, 160-bit)          "HAVAL-5-160"
       100 to 110 - 秘密/試験的アルゴリズム
                      

実装は、SHA-1 を必ず実装しなければならない(MUST)。実装は、MD5 を実装する必要がある(SHOULD)

 

10. パケットの構成 English

OpenPGP のパケットは、メッセージ生成とキー転送のために一定の順序で組み立てられる。すべてのパケットの順序が、正しく意味があるとは限らない。ここでは、パケットシーケンスの規則を解説する。

10.1. 転送可能な公開鍵 English

OpenPGP ユーザは、公開鍵を転送することがある。転送可能な公開鍵の基本要素を以下に示す。

Public Key パケットは、最初に位置する。それに続く各 UserID パケットは、この Public Key 所有者の身元情報を提供する。複数の UserID パケットが続く場合は、同一人物の異なる身元情報を意味する。例えば、ユーザは、複数のメー ルアドレスをもつ場合があり、メールアドレスごとにユーザ ID を構成する。

各UserID パケットの後ろに、0 個以上の Signature パケットが続く。各 Signature パケットは、すぐ前にある UserID パケットと最初の Public Key パケット上で計算される。その署名は公開鍵とユーザ ID の関連性を証明する。要するに、署名者は示されたユーザID によってその公開鍵が本人のものである証明をするということである。

UserID パケットの後ろには、ひとつ以上の Subkey パケットが続く。一般的にサブキーは、トップレベルの公開鍵が署名のみに使用する鍵の場合に提供さ れる。しかし、すべての v4 鍵は、サブキーをもつことが可能であり、サブキーは、暗号のみの鍵であったり、署名のみの鍵であったり、もしくは両方の場合でも存在する。

各Subkey パケットには Signature パケットが必ず後に続く。その署名は、トッ プレベルの公開鍵が発行したサブキーにバインドする署名にする必要がある。

サブキーや鍵パケットが無効であることを示すとき、各鍵には Revocation Signature が続く場合がある。Revocation Signature は、その鍵自身が発行した場合か、もしくはその鍵のトップレベル鍵が無効化権限を与えた鍵 (Self-Signaure の中の Revocation-Key サブパケットを通じて無効化を発行の権限を与えている)によって、発行されたものは受け付ける。

転送可能な Public Key パケットのシーケンスは、1 回の処理で複数の公開鍵が転送できるように連結されていることがある。

10.2. OpenPGP メッセージ English

OpenPGP メッセージは、パケット、もしくは下記の文法 English 的なルールにしたがったパケットシーケンスで構成。 (下の表記では、コンマ「,」はシーケンスに含まれる組合せを示し、垂直のバー「|」は選択肢をわけている。)

   OpenPGPメッセージ :- 暗号メッセージ | 署名付メッセージ |
			圧縮メッセージ | リテラルメッセージ

   圧縮メッセージ :- Compressed Data パケット.

   リテラルメッセージ :- Literal Data Packet

   ESK :- Public Key Encrypted Session Key パケット |
          Symmetric-Key Encrypted Session Key パケット.

   ESKシーケンス :- ESK | ESKシーケンス、ESK

   暗号メッセージ :- Symmetrically Encrypted Data パケット |
               ESKシーケンス, Symmetrically Encrypted Data パケット.

   One-Pass署名付メッセージ :- One-Pass Signature パケット,
               OpenPGPメッセージ, 関連する Signature パケット.
 
   署名付メッセージ :- Signature パケット, OpenPGPメッセージ |
               One-Pass署名付メッセージ.
          

また、Symmetrically Encrypted Data パケットを復号したり、Compressed Data パケットを展開しても、有効な OpenPGP Message を生まなければならな い。

10.3. 分離署名 English

OpenPGP アプリケーションには、「分離署名(Detached Signature)」と呼ばれるものを使用するものがある。例えば、プログラムのバンドルにファイルが含まれる場合、それと共にあるふたつめのファイルが、ひとつめのファイルの Detached Signature である。これら Detached Signature は、単純にファイルの署名データを別の Signature パケットに格納したものである。

 

11. 拡充された鍵のフォーマット English

11.1. 鍵の構成 English

OpenPGP v3鍵の構成は、下記のとおりである。スクエア括弧 '[]' の中は、オプションを意味し、省略記号 '.' は、反復を示す。

           RSA Public Key
              [Revocation Self Signature]
               User ID [Signature ...]
              [User ID [Signature ...] ...]
              

各署名は、RSA Public Key と直前のユーザ ID を証明する。RSA Public Key は、複数のユーザ ID をもつことが可能であり、各ユーザ ID は、複数の署名をもつことが可能となる。

ふたつの公開鍵を使用する OpenPGP v4 鍵の形式は、v3 鍵の形式と似ているが、他の鍵を Primary Key の「Subkey」として後ろに足されていく点は異なる。

           Primary-Key
              [Revocation Self Signature]
              [Direct Key Self Signature...]
               User ID [Signature ...]
              [User ID [Signature ...] ...]
              [[Subkey [Binding-Signature-Revocation]
                      Primary-Key-Binding-Signature] ...]
              

Subkey には Primary Key 発行の Signature が必ず後ろにつき、そのふたつの鍵を結びつけている。この Binding-Signature は 、v3 形式でも v4 形式でもよいが、v4 形式のほうがより好ましい。

上図で、Subkey の Binding-Signature が失効(Revoke)された場合、失効された Binding-Signature は削除され、Signature(*訳注: Binding-Signature-Revocation)のみを残してもよい。

メインキーとサブキーの両方をもつ鍵の中では、Primary Key は、必ず署名可能な鍵としなければならない(MUST)。Subkey は、どのタイプの鍵でもよい。v4 鍵ではその他の構造も可能である。例えば、v4 形式の RSA  鍵の Single-Key、RSA 暗号用鍵の DSA Primary Key、Elgamal Subkeys をもつ RSA Primary Key 等があり得る。

署名専用の Subkey を有することも可能である。これによって、Primary Key は、Certifications(key signatures)を集め、暗号と署名の両方に使える Subkeys の証明(Ceritfy)にのみ使える。

11.2. 鍵 ID とフィンガープリント English

v3 鍵では、8 オクテットの鍵 ID は、RSA 鍵の公開モジュールの下位 64 bit で構成される。(5.5.2参照)

v3 鍵のフィンガープリントは、鍵素材(公開モジュール n、指数 e が続く)を構成する MPI のボディ(2 オクテットレングスパケットは含まない)を MD5 でハッシュすることで作成される。

v4 鍵のフィンガープリントは、1 オクテット Packet Tag の 160-bit SHA-1ハッシュであり、後ろに 2 オクテットのレングスパケット、バージョンフィールドから始まるPublic Key パケット全体が続く。鍵 ID は、フィンガープリントの下位 64 bit である。下記に DSA 鍵を例としたハッシュ材料のフィールドを示す。

  a.1) 0x99(1オクテット)
  a.2) (b)-(f)の上位レングスパケット(1オクテット)
  a.3) (b)-(f)の下位レングスパケット(1オクテット)
   b) バージョン番号=4(1オクテット)
   c) 鍵作成時間のタイムスタンプ(4オクテット)
   d) アルゴリズム(1オクテット): 17 = DSA (例)
    e) アルゴリズム特定フィールド
  DSAキーのアルゴリズム特定フィールド(例):
  e.1) DSA 素数pの MPI 
  e.2) DSA 群位数q(qは、p-1を割り切れるprime diviser)のMPI
  e.3) DSA 元gのMPI
  e.4) DSA 公開鍵値y( = g**x xは秘密である)のMPI
        

(注意) 鍵 ID の衝突(ふたつの異なる鍵が同じ鍵 ID をもつ)が発生する可能性がある。フィンガープリントの衝突の可能性は、鍵 ID よりずっと低いが、まったく 無いとはいえない。

また、v3 形式と v4 形式の鍵が同じ RSA 鍵素材を共有した場合、それらは異なるフィンガープリントと鍵 ID をもつ。

 

12. アルゴリズムについての注意事項 English

12.1. 共通鍵暗号アルゴリズムの選択 English

共通鍵暗号アルゴリズムの設定(Symmetric algorithm preference)は、鍵保持者が受け入れる暗号アルゴリズムをリストしたものである。これは、Self-Signature にあることから、鍵保持者はそれぞれ異なる設定を有してもかまわない。例えば、Alice は、"alice@work.com"に TripleDES のみを指定し、"alice@home.org"には CAST5、Blowfish、TripleDES を指定してもよい。(注意:サブキーに付属する署名も同様である。)

TripleDES は、必ず実装されるアルゴリズムなので、明示的にリストされていなくても、リストの最後にあると認識する。しかし、そこで明示的にリストする方が望ましい。実装が選択を実装していない場合、TripleDES のみの実装であると見なすこと。

実装は、受信者の設定リストにない共通鍵暗号アルゴリズムを使用してはならない(MUST)。複数の受信者へ暗号化をするときは、実装は複数の受信者の設定の共通部分を適したアルゴリズムとして使用する。(注意: TrippleDES が必ず実装される ので、共通部分は、ヌル(空)にならない。)実装は、共通部分からアルゴリズムを選択するとき、どのようなメカニズムを使用してもよい。

鍵保持者の選択に無い暗号アルゴリズムでメッセージが暗号化されている場合、実装は、何らかの方法でメッセージを復号する必要がある(SHOULD)が、プロトコル違反を鍵保持者に必ず警告しなければならない(MUST)。(例えば、先ほど説明した Alice は、この仕様書にあるすべてのアルゴリズムを実装したソフトウェアをもつと仮定する。それでもなお、仕事と家での設定を区別したいとする。彼女の選択にない IDEA で暗号化されたメッセージを受信した場合、ソフトウェアは、メッセージが IDEA 暗号メッセージであることを彼女に警告し、何らかの方法で適した形に復号する。)

下位互換性を重要視させた実装では、「v3 Self-Signature と共にある v3 鍵は、IDEA の選択であり、TripleDES は、使えない」と暗黙に解釈してもよい(MAY)。これは、厳密にいえば準拠していないが、実装は、この場合に限って、上記のルールを冒してメッセージ作成者に警告を与え、メッセージの暗号に IDEA を使用してもよい(MAY)。OpenPGP ユーザの実装に IDEA が無くメッセージを読めないことが起こりうるので、理想的には、実装は、ふたつのメッセージを生成すること によってルールに従う。したがって、実装は、v3 鍵と矛盾する IDEA を使用してもよい(MAY)が推奨されていない(SHOULD NOT)。

12.2. 他のアルゴリズムの選択 English

その他のアルゴリズムも共通鍵アルゴリズムの選択と似たような働きをしており、「鍵保持者は、どのアルゴリズムを受け入れるか?」を指定する。そこにはコメントが作られる必要がある興味深いふたつのケースがあり、 圧縮アルゴリズム設定とハッシュアルゴリズム設定である。

12.2.1. 圧縮アルゴリズムの選択 English

圧縮は、PGP が始まったときから欠くことのできない部分となっている。OpenPGP と以前のすべての PGP バージョンは、圧縮を提案してきた。そして、この仕様の中では、実装が必要としなくても、メッセージは圧縮されるのがデフォルトである。したがって、圧縮設定は、相手が圧縮をもたない最小の実装を使用していることを仮定して、メッセージを圧縮しないことを鍵保持者が選択できる必要がある。また、これによって、どのアルゴリズムをサポートしているかを鍵保持者が表せる。

アルゴリズムの設定のように、実装は、設定(preference vector)に無いアルゴリズムを使用してはならない(MUST NOT)。設定が存在しない場合、それらは、[ZIP(1) か UNCOMPRESSED(0)] と仮定される。

12.2.2. ハッシュアルゴリズムの選択 English

一般的に、ハッシュアルゴリズムは、証明者ではなく署名者が選択するものである。なぜならば、署名者は、誰が署名を証明するかについて、予測できないからである。この設定によって、デジタル署名に基づくプロトコルは、ネゴシエーションが簡単になる。

それゆえ、Alice が Bob に署名で彼女自身を証明する場合、Bob のソフトウェアが使用しているハッシュアルゴリズムを利用するのは理解できることである。この設定で、Bob は、Alice が使用しても良いアルゴリズムを自分の鍵の中で表すことを可能にしている。

12.3. プレーンテキスト English

アルゴリズム ID0(Plaintext を意味する)は、秘密鍵が暗号化されずに格納されていることを表すときにのみ使用してもよい。実装は、Symmetrically Encrypted Data パケットの中でプレーンテキストを使用してはならない。実装は、暗号化されてないデータやリテラルデータをエンコードするために Literal Data パケットを必ず使用する必要がある。

12.4. RSA English

RSA 方式タイプには、RSA 署名専用鍵と RSA 暗号専用鍵がある。これらは推奨されていない。同じことを表すために、署名の中の「鍵フラグ」サブパケットは、よりよい方法であり、すべてのアルゴリズムへ一般化されている。実装は、そのような鍵を作ってはいけない(SHOULD NOT)が、解釈してもよい(MAY)

実装は、サイズが 768 bit 未満の RSA 鍵を実装してはいけない(SHOULD NOT)

単に下位互換性のために、実装を RSA 対応にすることは許可されている。例えば、そのような実装は、IDEA 共通鍵暗号での v3 鍵に対応する可能性がある。これは、その他の必須な実装規則の例外であることに注意すること。v4 の鍵で RSA 対応する実装は、必須な実装の機能を必ず実装しなければならない(MUST)

12.5. Elgamal English

Elgamal 鍵が署名と暗号の両方に使用される場合、鍵の生成時には特に気をつけなければならない。

Elgamal の鍵は、

から成る。

元(generator)と素数(prime)は、離散対数問題(discrete log problem)が困難であるものを選択しなければならない。群(group)g は、乗法群の位数が p-1、または、その大きな部分群(subgroup)を生成するもので、もう一方の g は、少なくとも、ひとつの大きな素因数をもたなければならない。良い選択肢は、p と (p-1)/2 の両方が素数となるような p を選ぶために、「強力な」 Sophie-German 数を使用することである。実際に「小さな部分群攻撃」を避けるためにも、この選択は有効であり、実装者は、これを使う必要がある(SHOULD)

また、Bleichenbacher [BLEICHENBACHER] の研究結果が示すように、元 g が小さな素因数しかもっておらず、g が生成する群の位数を割り切る場合、署名は、偽造可能だといえる。特に、群の位数が偶数の場合、g = 2 は、悪い選択である。一方で、元の値が 2 というのは、暗号化処理が速いという点で、暗号専用鍵に対しては有効な選択であろう。

Elgamal 署名を証明するとき、r と s が p より小さいことをテストするのは重要な点に注意していただきたい。これをテストしない場合、p の約 2 倍の長さの値の大きな r を使用すれば、簡単に署名は偽造される可能性がある。この攻撃についても、Bleichenbacher の研究論文の中で議論されている。

Elgamal 署名の安全な使用法の詳細は、[MENEZES] に紹介されており、上記のすべての脆弱性について議論されている。

Elgamal 署名を可能にする実装は、署名ができる Elgamal 公開鍵に暗号アルゴリズム識別子「20」を使わなければならない(MUST)

実装は、サイズが 768 bit 未満の Elgamal 鍵を実装してはいけない(SHOULD NOT)。長期のセキュリティ観点からも、Elgamal 鍵のサイズは、最低 1024 bit 以上にする必要がある。

12.6. DSA English

実装は、サイズが 768 bit 未満の DSA 鍵を実装してはいけない(SHOULD NOT)。現在ある DSA 鍵は、長期使用への推奨値である最大 1024 bit に制限されている。

12.7. 予約済みアルゴリズム番号 English

多くのアルゴリズム番号が OpenPGP の実装に役立つと考えられるアルゴリズムのために予約されているが、実際のアルゴリズムの実装を困難にする問題点がある。それらは公開鍵暗号アルゴリズムセクションで「予約(reserved for)」と記されている。

予約公開鍵暗号アルゴリズムである楕円暗号(Elliptic Curve)(18)、ECDSA(19)、X9.42(21) は、必要なパラメーターやパラメーター命令、セマンティックが定義されていない。

予約共通鍵暗号アルゴリズムである DES/SK(6) は、セマンティックが定義されていない。

予約ハッシュアルゴリズムである TIGER192(6) と HVAL-5-160(7) は、OID が定義されていない。予約済みアルゴリズム ID4 は、double-width(2倍幅)の SHA1 の変型に予約されているが、(そのアルゴリズム自体は)現在まだ定義されていない。

NIST の AES(Advanced Encryption Standard)のために、3 つのアルゴリズム ID が予約されている。このアルゴリズムは、(少なくとも)128、192 と 256 bit の鍵長が利用できる予定である。このアルゴリズムは、2000年に候補の中から選択される予定である。

12.8. OpenPGP CFB モード English

OpenPGP は、CBC(Cipher FeedBack)モードの変型を利用して共通鍵暗号化をする。この節は、そのプロセスの詳細について解説する。この CFB モードは、Symmetrically Encrypted Data パケットにおいて使用されている。秘密鍵の鍵素材を暗号化するメカニズムに似ているが、それについては、前の節で前述している。

OpenPGP の CFB モードは、すべてゼロの初期ベクタ(IV:Initialization Vector)を使用し、10 オクテットのランダムデータをプレーンテキストの前に prefix する(オクテット9と10はオクテット 7 と 8 のコピー)。それら 10 オクテットを暗号化した後、CFB の「再同期(resync)」を行う。

(注意) ブロックサイズが 64 bit 以上のアルゴリズムの場合、その全体のブロックに相当する関数がかけられる。例えば、16 オクテットのブロックアルゴリズムは、16 オクテットで処理する。それゆえ、2 オクテットのチェックサムを作成した後、16 オクテットに取りかかる。

プロセスの順序を以下に示す。

  1. FR(Feedback Register)は、IV(すべてゼロ)でセットされる。
     
  2. FR は、暗号化され、FRE(FR Encrypted)が作成される。これは、すべてゼロの値を暗号化したものである。
     
  3. FRE は、プレーンテキストに prefix されたランダムデータの最初の 8 オクテットと XOR され、C1-C8(暗号テキストの最初の 8 オクテット)が作成される。
     
  4. FR は、C1-C8 でロードされる。
     
  5. FR は、暗号化されてFREが作成される(暗号テキストの最初の 8 オクテットの暗号化)。
     
  6. FRE の左側 2 オクテットは、プレーンテキストに prefix された次の 2 オクテットと XOR される。これによって、暗号テキストの次の 2 オクテットである C9-C10 が作成される。
     
  7. (くりかえし)FR は、C3-10 でロードされる。
     
  8. FR は、暗号化され、FRE が作成される。
     
  9. FRE は、プレーンテキストの最初の 8 オクテットと XOR され、ようやく prefix されたデータの 10 オクテットの暗号化が終わる。これによって、暗号テキストの次の 8 オクテットである C11-C18 が作成される。
     
  10. FR は、C11-C18 でロードされる。
     
  11. FR は、暗号化され、FRE を作成する。
     
  12. FRE は、プレーンテキストの次の 8 オクテットと XOR され、暗号文の次の 8 オクテットが作成される。これらは、FR にロードされ、プレーンテキストがなくなるまでこのプロセスは繰り返される。

 

13. セキュリティに関する考慮事項 English

暗号に関連するすべての技術情報と同様に、ここで使用されるアルゴリズムの脆弱性を見極めるため、常に現在の状況を知っておく必要がある。

この OpenPGP 仕様は、公開鍵暗号技術を使用する。鍵ペアの秘密鍵の部分の所有は、適切な関係者およびグループによってコントロールされると仮定される。

この仕様書で示す特定の処理は、乱数の使用を必要とする。それら乱数の生成には適切なエントロピーの源泉を使用する必要がある。(RFC 1750 参照)。

MD5 ハッシュアルゴリズムには、脆弱性(圧縮機能での疑似衝突: pseudo-collisions in the compress function)が見つかっており、MD5 の使用に不賛成な人も存在する。彼らは、SHA-1 ハッシュアルゴリズムがより安全だと考えている。

多くのセキュリティプロトコル設計者は、ひとつの鍵で秘匿性(暗号化)と完全性(署名)の両方の目的を担うのは、よいアイデアではないと考える。実際、署名と暗号化に異なる鍵を使用する v4 の鍵の形式には、このような動機が作成理由のひとつとなっている。2 とおりに使用できる鍵の実装を勧める実装者であるならば、この論争について少なくとも認識している必要がある。

DSA 暗号アルゴリズムは、どのような 160 bit ハッシュアルゴリズムとも機能するが、ハッシュアルゴリズムの品質には敏感であり、ハッシュアルゴリズムが弱い(broken)場合、秘密鍵漏洩の可能性がでてくる。DSS(Digital Signature Standard)では、DSA は、SHA-1 と使用するよう指定している。多くの暗号学者は、RIPEMD-160 を強いと見なしている。弱いハッシュアルゴリズムは、署名を偽造されるのみでなく、秘密鍵漏洩の可能性がある点で、実装は、どのハッシュアルゴリズムが DSA と共に使用されているかについて、注意する必要がある。これらハッシュアルゴリズムの品質に関する考察は、Elgamal 署名にも同様にあてはまる。

受領者が署名方式を指定可能な認証システムを開発するならば、単純に受領者がその署名方式を指定しているという理由によって、署名者があえて弱いハッシュ方式を使用する可能性があることを認識すること。

この中で紹介する暗号アルゴリズムのいくつかは、他の暗号アルゴリズムと比較してあまり分析されていないものもある。例えば、CAST5 は、現在のところ強いと見なされているが、TripleDES の方がより長く分析されている。他の暗号アルゴリズムにも、そのような物議がある可能性がある。

ここに挙げたいくつかの技術は、国によっては政府の管理下におかれている。

 

14. 実装に関するその他の事項 English

この章は、実装者への特に下位互換性についての補足コメントの集合である。以前の PGP の実装は、OpenPGP 互換ではない。(双方の)差は、それほど大きくないこともあるが、しばしば、小さな差が、大きな差よりもわずらわしい場合がある。それゆえ、ここに考えられる問題点と位互換性を考える開発者への了解事項を掲げる。

 

15. 著者とワーキンググループ English

ワーキンググループへは、現在のチェアを通して連絡可能である。

John W. Noerenberg, II
Qualcomm, Inc
6455 Lusk Blvd
San Diego, CA 92131 USA

電話: +1 619-658-3510
EMail: jwn2@qualcomm.com

このメモの主要な著者を以下に示す。

Jon Callas
Network Associates, Inc.
3965 Freedom Circle
Santa Clara, CA 95054, USA

電話: +1 408-346-5860
EMail: jon@pgp.com, jcallas@nai.com
Lutz Donnerhacke
IKS GmbH
Wildenbruchstr. 15
07745 Jena, Germany

電話: +49-3641-675642
EMail: lutz@iks-jena.de
Hal Finney
Network Associates, Inc.
3965 Freedom Circle
Santa Clara, CA 95054, USA

EMail: hal@pgp.com
Rodney Thayer
EIS Corporation
Clearwater, FL 33767, USA

EMail: rodney@unitran.com

このメモは、以下に挙げる多くの著者の作業も利用している。
Derek Atkins, Charles Breed, Dave Del Torto, Marc Dyksterhouse, Gail Haspert, Gene Hoffman, Paul Hoffman, Raph Levien, Colin Plumb, Will Price, William Stallings, Mark Weaver, and Philip R. Zimmermann

翻訳者のアドレス

篠田 佳奈
Neoteny

Email: kana@neoteny.com

宮川 寧夫
独立行政法人 情報処理推進機構

Email: miyakawa@ipa.go.jp

16. 参考文献

[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>

[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>

[DONNERHACKE] Donnerhacke, L., et. al,
"PGP263in - an improved international version of PGP", ftp://ftp.iks- jena.de/mitarb/lutz/crypt/software/pgp/

[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.

[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年。

[ISO-10646] ISO/IEC 10646-1:1993. International Standard -- Information technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane. UTF-8 is described in Annex R, adopted but not yet published. UTF-16 is described in Annex Q, adopted but not yet published.

[RFC822] Alfred Menezes, Paul van Oorschot, and Scott Vanstone,
"Handbook of Applied Cryptography," CRC Press, 1996.

[MENEZES] Crocker, D.,
"Standard for the format of ARPA Internet text messages",
STD 11, RFC 822, 1982年 8月.

[RFC1423] Balenson, D.,
"Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers",
RFC 1423, 1993年10月.

[RFC1641] Goldsmith, D. and M. Davis,
"Using Unicode with MIME", RFC 1641, 1994年 7月.

[RFC1750] Eastlake, D., Crocker, S. and J. Schiller,
「セキュリティのための乱雑性についての要件(Randomness Recommendations for Security)」,
RFC 1750, 1994年11月.

[RFC1951] Deutsch, P.,
"DEFLATE Compressed Data Format Specification version 1.3.",
RFC 1951, 1996年 5月.

[RFC1983] Malkin, G.,
"Internet Users' Glossary",
FYI 18, RFC 1983, 1996年 8月.

[RFC1991] Atkins, D., Stallings, W. and P. Zimmermann,
"PGP Message Exchange Formats",
RFC 1991, 1996年 8月.

[RFC2015] Elkins, M.,
"MIME Security with Pretty Good Privacy (PGP)",
RFC 2015, 1996年10月.

[RFC2231] Borenstein, N. and N. Freed,
"Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies.",
RFC 2231, 1996年11月.

[RFC2119] Bradner, S.,
「RFC において要請の程度を示すために用いるキーワード(ey words for use in RFCs to Indicate Requirement Level)」,
BCP 14, RFC 2119, 1997年 3月.

[RFC2144] Adams, C.,
"The CAST-128 Encryption Algorithm",
RFC 2144, 1997年 3月.

[RFC2279] Yergeau., F.,
"UTF-8, a transformation format of Unicode and ISO 10646",
RFC 2279, 1998年 1月.

[RFC2313] Kaliski, B.,
"PKCS #1: RSA Encryption Standard version 1.5",
RFC 2313, 1998年 3月.

[SAFER] Massey, J.L.
"SAFER K-64: One Year Later",
B. Preneel, editor, Fast Software Encryption, Second International Workshop (LNCS 1008) pp212-241, Springer-Verlag 1995年.

 

17. 著作権表記全文

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

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

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

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