S/MIME 暗号化+電子署名の検証で不正扱いNo.09011
Iranoan さん 21/12/16 18:18
 
秀まるおさん今日は Iranoan です

最初にお断りしておくと、自作プログラムの動作確認をしていてたまたま見つけたこ
となので、どのように扱っていただいても構わないお話です

S/MIME は multipart メッセージを Base64 エンコードされた内容になっています
そして、その multipart メッセージが
・改行コードが CR+LF に成っていない
・更に暗号化+電子署名
の両条件を満たすと電子署名の検証で不正署名扱いになります
電子署名のみの時は、CR+LF でなくても正しい署名と検証されます

最初に書いたと降り、どのように扱っていただいても構わない話なのですが
・Thuderbird (Windows, Linux)
・Mutt (Linux)
の手元で確認できる他のアプリでは、正しい署名と検証されたので投稿させた頂いた
次第です

[ ]
RE:09011 S/MIME 暗号化+電子署名の検証でNo.09012
秀まるお2 さん 21/12/17 08:32
 
 メールの改行コードがLFのみだとダメということで、たしかに秀丸メールは受信し
たメールの改行コードをCR+LFに全部変換してる関係で、不正署名扱いになるのはそ
の通りのような気がします。(まだテストしてませんが)

 バグはバグなので対策をなんとか考えてみます。

[ ]
RE:09012 S/MIME 暗号化+電子署名の検証でNo.09019
秀まるお2 さん 21/12/18 18:14
 
 S/MIMEの方はまだテストできてませんが、とりあえず、PGPの場合は改行コードがC
R+LFでもLFのみでも問題無いことを確認しました。

 普通に電子署名されメール本文をコピペしてテキストファイルに保存して、

  gnupg --verity XXXX.txt

 みたいにテストするんですが、秀丸エディタでそのファイルを開いて改行コードを
CR+LFやLFのみにしても検証に成功しました。CRのみにした場合は「gpg: 有効なOpen
PGPデータが見つかりません。」のエラーになるようです。

 S/MIMEもテストします。

[ ]
RE:09019 S/MIME 暗号化+電子署名の検証でNo.09024
秀まるお2 さん 21/12/20 11:43
 
 また中間報告ですみません。

 S/MIMEもテストしたんですが、まず、「暗号化+電子署名」または「暗号化」の場
合は、改行コードがLFのみでも大丈夫だと思います。

 暗号化すると、メール本文も電子署名も全部まとめて

Content-Type: application/x-pkcs7-mime;
 smime-type=enveloped-data;
 name="smime.p7m"
Content-Transfer-Encoding: base64

 みたいな形でエンコードされるので、エンコードされたメール本文の改行コードが
LFのみになっていても、base64された結果には影響しないです。秀丸メール自体もBA
SE64デコードした生データをそのままS/MIMEデコードにかけるので、それでエラーに
なることは無いはずです。

 S/MIMEデコードした結果のメール本文改行がLFのみになっていても、それはCR+LF
に変換されますが、それはS/MIMEの復号/検証が成功した後なので、問題無いはずで
す。???

---------------------------------------------------------
 ダメなケースは・・・、電子署名だけのケースがダメでした。この場合、

--Boundary-mYTBwUjyiYE7STXJK98Pz
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: quoted-printable

test
test
test

--Boundary-mYTBwUjyiYE7STXJK98Pz
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

......

 みたいなメールになって、上記例だと「test改行test改行test改行」の文字列をそ
のままS/MIMEデコードに渡します。そこの改行コードが違ってるとエラーになります。
これについては受信ログの中での本文改行コードがLFのみなら


  X-TuruKame-LF:  lf

 みたいなヘッダを埋め込んで、それがある場合は改行コードをLFのみに変換してS/
MIMEデコードをかけるような処理を追加しようと思います。

[ ]
RE:09024 S/MIME 暗号化+電子署名の検証でNo.09025
秀まるお2 さん 21/12/20 14:03
 
 とりあえず、改行がLFのみのメールを送信するテストをしてみたんですが、うまく
いきませんでした。

 まず、うちの会社で入ってる「ミテネ」ってプロバイダーの場合、LFのみ改行で
メールを送信しても、メールサーバーで勝手にCRLFに変換されてしまうようです。届
いたメールはCFLF改行になってしまってました。

 うちの自前のWebサーバーの場合(Windows用のIMail Server)は、LFのみ改行だと
メールの送信でエラーになりました。メールの最後に「crlf.crlf」みたいなデータ
を送るのがSMTPサーバーのルールとしてあるんですが、それの改行が「lf.crlf」み
たいになると受け付けてくれないようです。

 gmailでも試しましたが、うちのWebサーバーと同じ結果で、送信できませんでした。

 ってことで、やっぱりLFのみ改行メールの方がたぶん一般的に存在する物じゃない
と思うし、そもそも的に僕の所でテストも出来ないようなので、対応できないってこ
とで終わりにさせていただこうかと思います。

[ ]
RE:09025 S/MIME 暗号化+電子署名の検証でNo.09026
秀まるお2 さん 21/12/20 14:11
 
 RFCもちょっと検索してみたんですが、CRのみ、LFのみ改行はダメみたいに書いて
ありました。

http://srgia.com/docs/rfc2822j.html

CR と LF とは CRLF としてのみ現れなければならず(MUST)、ボディ内にそれらが独
立して現れてはならない(MUST NOT)。

[ ]
RE:09025 S/MIME 暗号化+電子署名の検証でNo.09028
Iranoan さん 21/12/21 01:41
 
秀まるおさん今日は Iranoan です

件名の件は元々
> 最初に書いたと降り、どのように扱っていただいても構わない話なのですが
> ・Thuderbird (Windows, Linux)
> ・Mutt (Linux)
> の手元で確認できる他のアプリでは、正しい署名と検証されたので投稿させた頂い
>た次第です
なので、どのように判断していただいても構いません

>  とりあえず、改行がLFのみのメールを送信するテストをしてみたんですが、うま
>くいきませんでした。
>
>  まず、うちの会社で入ってる「ミテネ」ってプロバイダーの場合、LFのみ改行で
>メールを送信しても、メールサーバーで勝手にCRLFに変換されてしまうようです。
>届いたメールはCFLF改行になってしまってました。
ただこのあたりを読むと、私の意図が伝わっていないようなので、再度書かせていた
だきます

暗号化+電子署名のメールなので、検証するには
0.ヘッダ部分以外の取り出し
1.Base64 をデーコード
2.復号化 (暗号化解除)
3.電子署名の検証
という手順が必要です
そして私が取り上げた「改行コードが LF になっている」とは、0 の段階の送信され
てきたメール・データそのものではありません
2 が行われ、3 の検証対象となるデータのことです
よってメールの送受信によって改行コードが変換されるか否かは関係がありません
メール・ファイルの文字コードも関係がありません

[ ]
RE:09028 S/MIME 暗号化+電子署名の検証でNo.09029
秀まるお2 さん 21/12/21 08:50
 
 暗号化+電子署名の場合の、復号前のデータが「LFのみ」になってる場合というこ
とですが、そういうケースも一応僕の所でテストしたつもりなんですが、それは特に
問題は出なかった次第です。なので、最初の話にある「暗号化+電子署名」というの
が、「電子署名のみ」の間違いかと思った次第です。

 元データがLFのみになってようがバイナリデータだろうが、暗号化した場合は全部
が1つのbase64エンコードされたMIMEパートになって届くので、秀丸メール的にはba
se64のデコードをしてそれをそのままS/MIMEデコードのAPIに渡すだけでして、中身
の改行コードによってデコード/署名検証が失敗するのはちょっと理由が分からない
です。

 とりあえず、Iranoanさん自身が直して欲しいと思ってる訳でもないようなので、
この辺でやめときます。

[ ]
RE:09029 S/MIME 暗号化+電子署名の検証でNo.09030
Iranoan さん 21/12/21 11:02
 
秀まるおさん今日は Iranoan です
>  暗号化+電子署名の場合の、復号前のデータが「LFのみ」になってる場合という
>ことですが、そういうケースも一応僕の所でテストしたつもりなんですが、それは
>特に問題は出なかった次第です。なので、最初の話にある「暗号化+電子署名」とい
>うのが、「電子署名のみ」の間違いかと思った次第です。
それであのような書き込みになっていたんですね
変更なしということで問題はありません

[ ]