bonbonniere

こんにちは。時々拝見しています。
私は FireGPG を使用していないので、その評価はどうでもいいのですが、
Content-Type の charset は暗号文の文字コードではないでしょうか？
文字化け防止に必要な情報は、復号文の文字コードだと思いますが。
だとしたら、FireGPG が charset を参照しても、あまり意味が無いです。
ほとんどの場合は同じ文字コードでしょうが、保証は無いですね。
ヘッダを含めて暗号化する PGP/MIME なら話は別ですが。

では、対策はどうすればいいのか？　正直言って私にも分かりません。
RFCに無い事をしたら、互換性が無くなるでしょう。
ちなみに PGP9 は暗号化で下記のような独自のヘッダを付けていますが。
X-Content-PGP-Universal-Saved-Content-Type: text/plain;
　charset="iso-2022-jp"
たぶん復号時には、このヘッダを参照しているのでしょう。
しかし、他のソフトがこれを参照するとは限りません。

> Content-Type の charset は暗号文の文字コードではないでしょうか？
メールの場合はContent-Typeのcharsetは暗号文ではなくて暗号化する前の文字コードです。暗号化した後はasciiにしかなりませんから。
メールでは文字化け防止（と署名検証）に必要な情報は暗号化前（と署名時）の平文の文字コードです。これをContent-Type:ヘッダから判断しています。

WebPageでは（今 表示しているページのエンコーディングの指定だけで）そんな相手の文字コードを示すものは無くて判断できないのでFireGPGはMUAから送られたメールの復号やPGP署名検証は必ず失敗するという話しです。同じWebPage上で処理するならば、たまたまHTMLのエンコードが同じになって文字化けしないという程度の話しです。

また、PGP/MIMEは添付ファイルになってしまうのでGmailでは使えなくなります。
なので、今のところ対策はなく、Gmailで他のMUAからのメールを復号したり署名検証には使えないでしょう。

> ちなみに PGP9 は暗号化で下記のような独自のヘッダを付けていますが。
> X-Content-PGP-Universal-Saved-Content-Type: text/plain;
> 　charset="iso-2022-jp"
> たぶん復号時には、このヘッダを参照しているのでしょう。
> しかし、他のソフトがこれを参照するとは限りません。
これはPGP Corp.のPGP9を利用している場合に限るでしょうね。他のMUAは一切見ないでしょう。
この意味では「仲間同士、内輪のみ」ということで、PGP9もFireGPGも同列なのかもしれません。
え！？　メールもこれですか？　違いますよね。
＃ プロキシで処理するからMUAは関係ないのかな

すみません、数年前にPGPの国内販売会社と小さなトラブルが有って、それ以来PGP Corp.の製品の話題には参加しないようにしています。協力も妨害も一切しないことにするには話題にしないことが一番なので。
＃元々妨害なんてしていませんけどね

> charsetは暗号文ではなくて暗号化する前の文字コードです。

私が一番知りたいのは、そこです。何かソースはありますか？
RFCのどこかに記載されていますでしょうか？
そのほうが役に立つからとか、暗号文が ascii しかないからというのは、
理由にはならないと思いますが。

> > charsetは暗号文ではなくて暗号化する前の文字コードです。
>
> 私が一番知りたいのは、そこです。何かソースはありますか？
> RFCのどこかに記載されていますでしょうか？
RFCに書いてあると思いますよ。もう10年くらい前にディスカッションは終わっていて、私はPGP/GnuPGを研究しているわけではないので当時示されていたドキュメント番号など示すことは出来ません。
当時 日本語対応を働きかけたMUAの作者もRFCなどドキュメントで納得して日本語に対応してくれているという事実しか覚えていません。Googleで検索すればドキュメントが見つかるのではないでしょうか。
いま日本語でPGP/GnuPGに対応しているほとんどのMUAの作者がドキュメントで納得して作業していたし、当時参加していなかったQMAIL3やSylpheedも同じように日本語対応されていたのでドキュメントは有るのでしょう。

しかし、私にソースを提示せよというのはお門違いで失礼も甚だしいとは思いませんか？　私は現状の動作を規定しているのでもないしMUAの作者でもありません。教えて欲しいと願うならそれなりの書き方もあるかと思います。

こういう疑問はMUA作者側に聞いてみると明確な回答が得られるでしょう。MUAの動作が何に基づいているかは彼らはすぐに示すことが出来るはずです。

> そのほうが役に立つからとか、暗号文が ascii しかないからというのは、
> 理由にはならないと思いますが。
もちろん、そんな馬鹿げた理由じゃないです。私の説明でそんな理由だという書き方はしていません。
フランス語の暗号がフランス語に、ドイツ語の暗号がドイツ語に、asciiの羅列がそれぞれ復号された結果が正しく表示されるのはContent-Type:ヘッダに従って正しくデコードされているからです。他になんの指示情報もありません。

申し訳ありませんが、この記事はFireGPGに関する記事なので無関係な話題は他の専門サイトでやって下さい。

FireGPG の文字化けに無関係な話題ではないでしょう。
FireGPG にヘッダを参照しろと、貴方は言いたいんでしょう？

> RFCに書いてあると思いますよ。

その程度の認識ですか？
FireGPG をここまで批判してらっしゃるのに根拠があいまいですね。

面白いことを仰いますね。あなたが興味のないFireGPGの文字化けの話しは あなたには関係ないのでは？
FireGPGに関しては別の場所で建設的な意見を求める形でのディスカッションになっています。そこにはその仕組みがわかっている人だけなのかRFCの話なんか出ません。MUAの動作も知らずにRFCを示せと言う人と、しかもFireGPGに興味がないと言い切る人とこんなところで議論する気はないです。

RFCなどのドキュメントに関しては私には関係ないのではないですか？　まともに日本語をサポートしている全てのMUAが そういう動作をしている事実がありますから、それらのMUAの動作では現状のFireGPGとは暗号やPGP署名を利用した通信が行えません。根拠と言うならその事実で充分ですし、その動作は曖昧なものではないです。（実際に通信できないので）

もう一度書きますね。
FireGPG の文字化けに無関係な話題ではないでしょう？
貴方の言う「まともな MUA」は RFC は関係ないんですか？
RFC を無視するなら FireGPG を批判するのは妙な話ですね。
ならば最初からヘッダ云々など書かなければ良いのに。

> FireGPG の文字化けに無関係な話題ではないでしょう？
FireGPGに興味のないあなたに関係がないということです。ここではあなたは私がヘッダ参照の仕組みを書いたことについてRFCを示せと言っているだけでしょう。
そういう質問は専門サイトでやってくださいと書いています。私のコメントをちゃんと読んでいますか？
それに、最初のコメントに対する私の疑問にあなたは答えていません。私は私のコメントがちゃんと読まれていないと判断しています。
関係のない話題に首をつっこんで自分の質問にすり替え、挙げ句の果てに私を非難するのは厨房の行動と言わざるを得ないです。

> 貴方の言う「まともな MUA」は RFC は関係ないんですか？
RFCに関係ないはずが無いじゃないですか、日本語を扱えるMUAはRFCに従っているからこそ互換性が保たれているんです。

> RFC を無視するなら FireGPG を批判するのは妙な話ですね。
> ならば最初からヘッダ云々など書かなければ良いのに。
私はRFCを無視した覚えはないですよ。単に説明責任もないし、RFCのドキュメント番号を示すなんてことは無関係だと言っているんです。ここではどのヘッダを見てどんな処理をやっているかという説明で十分だと思っています。
RFCやGnuPGの動作を研究しているわけでもないし、RFCに従っているかの実装の検証をしているわけでもありません。またそんな人たちを相手にするために書いているわけでもありません。実用性に関して事実をヘッダの参照の仕組みを説明しながら書いているだけなので、RFCに興味があるのなら自分で探して下さい、ということです。

最後に、
RFCのドキュメント番号まで言及していませんが、http://kiyo.chips.jp/blog/archives/2007/07/sylpheedpgpmime.html の記事、コメントに書いてある参照先のURLが参考になるかもしれません。
ただし、記事やMUA作者のコメントを熟読してから参照先へ飛んで下さい。（Flashプラグインが必要です）

私は FireGPG にではなく、貴方の考え方に興味を持ったわけです。
ヘッダ云々という話であれば、真っ先に RFC を考えるのは自然だと思いますがね。
リンク先の文を書かれたのは、かなり前ですね。
この時点で RFC を全く意識していなかったわけですか？
実際のところ、ちゃんとした文書が残ってるのは PGP/MIME だけですよ。
そこから考えると、US-ASCII になってるのは当然ですね。
貴方は異論があるでしょうが。

多分 Sylpheed の作者は PGP/MIME だけで充分だと考えているでしょうね。
私は以前、QMAIL3 の作者に PGP Partitioned のサポートを依頼したんですが、
いまだ未実装です。
どうも、こちらの作者も PGP/MIME だけで充分だと考えているようです。

> 私は FireGPG にではなく、貴方の考え方に興味を持ったわけです。
> ヘッダ云々という話であれば、真っ先に RFC を考えるのは自然だと思いますがね。
何度も書いていますが、私は自分のWeblogでRFCの記述を含めて説明する気はないんです。わかりやすいように何を見て動作しているかということを書くだけです。また、研究者や学習者を満足させるようなことを書く気は全くないです。

> リンク先の文を書かれたのは、かなり前ですね。
> この時点で RFC を全く意識していなかったわけですか？
メーリングリストでRFCの説明していただいたところは意識していますよ。それに従って書いている部分もありますから。しかし、RFCの記述と絡めて書く気はないです。実装の事実を書いているだけです。ユーザーには必要かつ充分でしょう。
最終更新は1年くらい前ですがSylpheedとQMAIL3は進化しています。検証したMUAのバージョンも書いているので参考にするには古いとは思っていません。

> 実際のところ、ちゃんとした文書が残ってるのは PGP/MIME だけですよ。
> そこから考えると、US-ASCII になってるのは当然ですね。
> 貴方は異論があるでしょうが。
そこでなぜPGP/MIMEだけと言い切るんですか。
PGP/MIMEのドキュメントが目立つのはMIMEの実装としてPGPを別にしてあるからというだけだと思います。他についてはPGP暗号とは関係なくMIMEのRFCです。だから目立つドキュメントがない。

異論も面倒で、間違いを正す気もないですが、
それほどRFCの記述に拘るなら、RFC2047に以下の記述があります。
The 'charset' portion of an 'encoded-word' specifies the character set associated with the unencoded text.
これは”符号化以前のテキストの文字セットを記述する”ということでしょう。
中味が日本語なのにcharset=asciiで吐き出すMUAはPGPの実装以前の問題としてRFCに照らせばcontent-typeが”中味を表していない”というバグとなります。暗号化していない日本語のメールをcharset=asciiとして書き出すのと同じレベルです。逆に復号時にcharsetでのエンコードを無視するのもバグ。
ということで暗号化メールについての個別のRFCは少ないと思います。結果的に全てMIMEについてのRFCと、PGPパケットの中味についてはOpenPGP規約で、全てちゃんとしたドキュメントです。これは検索エンジンなどで自分で探して下さい。

> 多分 Sylpheed の作者は PGP/MIME だけで充分だと考えているでしょうね。
> 私は以前、QMAIL3 の作者に PGP Partitioned のサポートを依頼したんですが、
> いまだ未実装です。
> どうも、こちらの作者も PGP/MIME だけで充分だと考えているようです。
私もPGP/MIMEで充分だと思いますよ。相手との通信のために都合の悪いところは修正していただいていますが。
PGP PartitionedについてはPGP Corp.独自の仕様なのではないかと思いますがノーコメントです。
私はSylpheedもQMAIL3もBBS以外にPMで実名にて、必要性や実際の運用状況などを説明して納得して修正していただいています。必要に応じてPMで実際に暗号メールのやりとりもします。もしかしてあなたは匿名で依頼していませんか？　もしそうなら厳しいかもしれません。

このWeblogは学習者のための学習の場でも研究の場でもありません。これ以上時間を費やしたくありません。
RFCについてはPGPよもやま掲示板でのほうが的確な回答が得られると思います。（昔のメーリングリストのほとんどのメンバーが監視しているはず）

もうコメントは不要です。コメントを管理下に入れ、一定時間経過後に不可視にしておきます。

今、帰宅しました。消える前で良かったです。

毎度、律儀に長いレスポンスどうもです。
べつに説明など要りませんよ。
貴方は丁寧にレスしすぎです。疲れませんか？

コンテンツはテキストでエンコードは無しですよ。
基本的に的外れですね。

私の最初のコメント以降、全部削除したらどうですかね。
当方は全然かまいませんので。

サイン・インを確認しました、 さん。コメントしてください。 (サイン・アウト)

(いままで、ここでコメントしたとがないときは、コメントを表示する前にこのウェブログのオーナーの承認が必要になることがあります。承認されるまではコメントは表示されません。そのときはしばらく待ってください。)

URL:
情報を登録する? はいいいえ

コメント: