ルート証明書を無効にされた「WoSign」その後

　恣意的かつデタラメな認証局運用で各ブラウザから無効にされた、例の WoSign（と StartCom）その後どうなったかなぁ…と思ってアクセスしたら、普通にアクセスできた。
　アレ？ WoSign のルート証明書は「信頼されていない証明書」へ登録しているのに何で？…と証明書チェインを確認すると…DigCert の下位認証局になってた :-P

　しかし、この WoSign へ "助け舟" を出した「DigCert」だが、例の Symantec の認証局業務（Google からダメ出しされた）を買収したところでもあるんだよなぁ。
　なんだか認証局業界の廃物利用企業という感。

　話を WoSign へ戻すと、IE、Chrome、FireFox でルート証明書を無効にされて、ルート認証局から下位認証局へ落ちぶれたわけだけれども、何故か Opera だけはルート認証局として認めてくれているらしい。なんとも不思議な話ながら、その理由は以下の通り。

マイクロソフト、不正が指摘されていた中国CAの証明書を無効に - CNET Japan
----------引用ココから
　WoSignの証明書をおそらく今後も信頼するであろうウェブブラウザの1つが、Operaだ。Operaブラウザは2016年、Golden Brick Silk Roadを中心とする中国企業のコンソーシアムに買収されている。このコンソーシアムには、北京のモバイルゲームベンダーであるKunlun TechやQihoo 360が名を連ねており、WoSignとStartComはQihoo 360の傘下にある。
----------引用ココまで

　なんともかんとも胡散臭い話だ。

「マイナンバー」に代わるもの

　名簿の名寄せ乃至それに類した作業をしていると、同姓同名の人に悩まされる。
　他の属性（生年月日や住所）があって判定の材料にできれば良いのだが、必ずしもそういう属性が（対象リストに）あるとは限らないし、そもそも変化してしまう属性も多くある。

　そこで時の政府は「マイナンバー」なるものを考案したわけだが、もっと良いことを思いついた。
　ズバリ、「姓名」で一意になるようにしてしまえば良いのだ。

　人名に使える漢字を 2,998字として。
　もっともオーソドックスな「姓2文字 + 名2文字」の構成で考えても、名前空間は「2998^4」（80兆余り）。「姓1文字 + 名3文字」や「姓3文字 + 名1文字」の構成を許すなら「2998^4*3」（242兆余り）。更に「姓名で 5文字」まで許容すれば「2998^5*4」（96京余り）。

　本邦の人口を 1.27億人として、この名前空間がどれだけの広さか考えると…
　「2998^4」であれば、全人口に 63万回余り名前を付与できる。「2998^4*3」であれば 190万回余り。「2998^5*4」に至っては 76億回余り。
　言い換えると、それだけの世代交代の間、この名前空間は持つということ（人口が増減しないという前提）。ちなみに、生命誕生は 45億年前とか。生命誕生から毎年世代交代していても「2998^5*4」であれば、まだ 31億くらい残ってるね。

　…これ、何気に素晴らしいアイディアじゃないか。
　今からでも遅くないので「マイナンバー」なんていう無粋なものは廃止して、「マイネーム」制度として進めてはどうか。

ChatWork その認証（パスワード）関係の仕様について

　ビジネス向けチャットツールの雄である「ChatWork」。
　自分も好む好まざるに関わらずお世話になっているわけですが、その認証関係の仕様を確認して、今更ながらに愕然となった。

　ChatWork のパスワードは「半角英数記号8文字以上」となっている。
　でもこれ「半角英数記号から任意に使って8文字以上」という意味だったりする。半角英数記号を混在させる必要はない。入力チェックしているのは文字数だけなので、なんなら「11111111」（"1" を 8文字）でも通ってしまう。
　何だよこれ。

　これで二段階認証があるのならまだしも、それも無い（2年くらい前から実装するする言っているけど、未だに…）。
　管理者がパスワード強度を引き上げる（強いパスワードをユーザに強制する）オプションがあるのかと思いきや、それも無い。
　せめて、ユーザのパスワード強度を一覧できる機能でもあれば個別に指導もできるのだが、それすら無い。

　このお粗末さは、ビジネスツールとして如何なものかと。
　「チャットツール」と聞けば軽いイメージがありますが、ビジネス向けともなれば重要な内容が飛び交うわけで、あまつさえファイル添付機能もある。

　ちょっと安心して使えるツールとは思えないなぁ。

「WoSign」と「StartCom」を「信頼されていない証明書」ストアへ

中国最大の認証局「WoSign」が証明書発行日改竄などを行っていたとしてFirefoxがブロックの方針 - GIGAZINE

　こんなルート証明機関を「信頼」していたら、公開鍵基盤が成立しないでしょう。
　遅まきながらではありますが、「Certification Authority of WoSign」と「StartCom Certification Authority」のルート証明書を、「信頼されていない証明書」ストアへ登録しました。

　ルート証明機関というのは、公開鍵基盤の要です。
　いまや色々な社会基盤、例えば銀行（オンラインバンク）でさえも公開鍵基盤に依存しているわけです。その要であるルート証明機関には、極めて高度なモラルが要求されます。
　問題のあるルート証明機関が一つでもあれば、公開鍵基盤全体が危機に晒されるからです。

　それが瑕疵や怠慢ですらなく、故意にルールに反した運営をしていたわけで、話にならないとしか言い様がないです。

Firefox ready to block certificate authority that threatened Web security - Ars Technica
----------引用ココから
A Google spokesman declined to say whether Chrome planned to issue similar recommendations against WoSign/StartCom.
----------引用ココまで

　なお、Google は上記引用のように呑気に構えているようです。
　FireFox 嫌いの自分ではありますが、FireFox の迅速なブロック方針には賛辞を贈りたいです。

「ー（長音）」。 いいえ、「―（ダッシュ）」です。

　一連のデータの中から、あるカタカナ名称を検索していてヒットしないので、おかしいなと思っていたら…「ー（長音）」であるべきところが「―（ダッシュ）」で記載されていた。
　もうね、ひたすら脱力。

　ややこしいデータで、ヒットしない（その名称が含まれない）可能性は色々考えられたので、あれやこれや調べていた。その後だっただけに尚更。

　で、その憂晴らし事後調査で見つけたのがこのページ。

日本語の横棒記号に絶望した - taichino.com
----------引用ココから
まず半角記号の’-'はハイフンマイナス(0x2d)と呼ばれていて、ハイフンとマイナスの意味を包含した記号になっています。ASCIIコードのビット数の制限があった事を考えても、センスの良さが光る決定だと思います。文脈でハイフンかマイナスかは容易に判断できる訳です。ハイフンとマイナスを別々にしていたら、今頃マイナスのつもりで書いたハイフンに対するコンパイルエラーで世界中のプログラマのイライラは100%水増しと言った状況なわけです。世界平和に繋がっているといっても過言ではありません。

一方でJIS記号由来でunicodeに採用されている一連のマルチバイトな横棒のセンスのなさと言ったらありません。色んな文脈で使われる横棒を全部別々に定義してしまっています。
----------引用ココまで

　一般論として、文字の意味を分けて定義しておくというのは、間違った選択ではないと思うんですよね。
　統合されたものを分離し直すより、分離されているものを統合し直すほうが遥かに楽なわけです。前者にはなにがしかの判断が（それが「容易」なものであれ）必ず必要ですが、後者は機械的におこなうことができますから。

　ただし、ここまで見た目が紛らわしい文字を、ここまで細かく分けて定義してしまっているというのは、間違いなく悪手でしょうね。
　ユーザの選択能力を過大評価したのか、単に何も考えていなかったのか…。

　慣れた人でも注意深く使い分けないといけないので、慣れていない人の場合は推して知るべし。
　さらに、PC上の文字はコードにより抽象化されているということを知らない人の場合、説明しても「見た目は同じなんだから、なんでダメなの？」となってしまうのです。んがくく…。

　ちなみに、自分の場合は「-（半角ハイフン マイナス）」、「－（全角ハイフン マイナス）」、「ー（長音）」、「一（漢数字の 1）」を "注意深く" 使い分けるので手一杯です。それ以外は意識的に無視して使わないようにしています。
　もっとも、それだけに今回は「―（ダッシュ）」に考えが及ぶのが遅れたんですが…はぁ…。

ディスプレイ電源オフでウィンドウの配置やサイズが崩れる問題と、その回避方法

Windows7Home 省電力の設定でディスプレイの自動OFF後にマウスなどでディスプレイの電源ONになった際に開いていたいくつかのWindowが全て小さくなる - Microsoft コミュニティ

ディスプレイの電源を切って入れ直すとデスクトップの各ウィンドウサイズが変わる - Microsoft コミュニティ

　Windows 利用中にディスプレイの電源をオフにすると、何故かウィンドウの配置やサイズが崩れてしまう（画面左上方へ押し込められてしまう）現象。
　どうも画面解像度の変更処理（ないしはそれに類似した処理）が走ってしまっているようなのですが、この現象、自分も困ってるんですよね。

　翌日へ作業を持ち越すためにログオフしないでロックだけして帰る時、ディスプレイの電源をオフにできないのです。
　放置しておけば省電力モードへ移行するのですが、それまでの間に「マメな人」がディスプレイの電源を切ってくれたりするわけで、そんな時は翌朝悲惨なことになります。

　理屈で考えて「ディスプレイからの信号が無くなったからといって解像度を変える必要はなく、新たな信号がくるまで現状の解像度を維持すれば良いだけ」なのですから、この現象はディスプレイドライバの問題であると理解しています。
　しかし「仕様」と考えて（＝諦めて）あまり深く突っ込んでいませんでしたが、そうか、VGA端子を使うという手もありましたか。

　試しに VGA端子で（わざわざ VGAケーブルを探して）接続して試してみると…おぉ、自分の環境では再現しません。
　この辺り、リンク先でも書いておられるように、VGA規格の旧さが奏功しているのでしょうね。

　ともあれ、これでメデタシメデタシ…なわけ無いだろ！
　CRTディスプレイが絶滅した今、何が悲しくて VGA なんぞ使わなくてはいけないのかと。

----------

　そこで、この問題を（とりあえず）回避する「手抜き Tips」を紹介します。
　要は、ディスプレイの電源をオフする際、予めディスプレイとログオン中ユーザとの "リンク" を切断しておけばよいのです。

　「ディスプレイとログオン中ユーザとの "リンク" を切断」と言ってもどうするか。
　ロック（Windowsキー + Lキー）だけでは不可です。前述のとおり再現してしまいます。ログオフすれば当然に切断できますが、それだと意味がありません（やれるならやってる）。

　現行のクライアント向け Windows（Windows Vista ～ 8.1、そして恐らく 10 も）であれば、「Ctrlキー + Altキー + Delキー」のメニューを表示して、「ユーザの切り替え」を選択（Altキー + Wキー）します。これで切断されます（正しくは「コンソール・セッションでなくなる」と表現すればいいのかな）。
　実際に別のユーザでログオンする必要はなく、この手順でログオン画面にするだけで可です。

　復帰する時は、普通にパスワードを入力すればログオンしていたユーザへ戻れます（普通にロックしていた時より、若干時間は要しますが）。
　仮にディスプレイの電源が切られていても、ウィンドウの配置やサイズは元のままです。

　これで「マメな人」にディスプレイ電源をオフにしてもらっても大丈夫です（…しかし、なんでここまでせにゃならんのだ…という気はする）。

　以上、「手抜き Tips」でした。
　まぁ「手抜き」とはいっても、「手を抜かず回避」（＝解決）しようとすると、恐らくディスプレイドライバに対応してもらうしか無いんですけどね、この問題。

----------

Afterfollow 2016/10/03

　世の中、有徳の士というのはいらっしゃるもので、解決方法が公開されていました。

DisplayPort接続時のディスプレイのオンオフによるウィンドウの再配置について - 塵の雨日記

　以下のレジストリを変更すると、ディスプレイを切断してもウィンドウの配置やサイズが崩れないとのこと。
　物理ディスプレイ切断時に切り替わる仮想的なディスプレイがあって、その画面サイズがこのレジストリ値で指定できるのでしょう。

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GraphicsDrivers\Configuration\SIMULATED_（数字アルファベットの羅列）\00]
PrimSurfSize.cx = 横ピクセル数
PrimSurfSize.cy = 縦ピクセル数

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GraphicsDrivers\Configuration\SIMULATED_（数字アルファベットの羅列）\00\00]
ActiveSize.cx = 横ピクセル数
ActiveSize.cy = 縦ピクセル数

　この現象、Windows 10 では発生しませんが、やはりまだまだ Windows 7 や 8 の方もいらっしゃることですし、Afterfollow として追記しておきます。

Heartbleed 脆弱性への対応と、技術への理解

　セキュリティ関連企業のホワイトペーパを読んでいたら、Heartbleed 脆弱性への対応で SSL証明書を入替えた際、秘密鍵を変更しないまま証明書を再発行している Webサーバーが多いらしい。
　馬鹿な、有り得ないだろ。

　事実だとすれば、大きく二重の不見識だと思う。
　一つは、Heartbleed 脆弱性の内容（プロセスのメモリ内容が漏洩 ＝ 秘密鍵が漏洩）を理解しないまま、「SSL証明書を再発行しないといけない」という上っ面だけの対応をしてしまっていること。
　もう一つは、そもそも SSL証明書を再発行（更新）する際は、新しい秘密鍵を使わなければいけないという大原則に反していること。

　セキュリティ関連企業のホワイトペーパーである（多少なりと宣伝の色彩がある）ことを割引いて読まないといけないのだろうけれど、自身の経験でも、何も考えずに長い有効期限（複数年）の証明書を選択したり、あまつさえ CSR を使い廻したりするのを見てきているので、あながち誇張だとばかりも思えない。
　どちらも、複数年にわたって「同じ秘密鍵を使い続ける」という事なので。特に後者（CSR の使い廻し）は、公開鍵基盤や公開鍵暗号の仕組を理解していたら絶対にしない選択だと思う。

　「技術」というのは IT関連に限らず、詳細はともかく概要だけでも理解していないと安全に使うことすら叶わないのだと、改めて思うのです。

OpenDKIM の評価は、ヘッダFrom（≠ envelope-From）に対して実施される

　SendMail + OpenDKIM の構築をしていて、検証作業でハマりました。

教訓：
OpenDKIM の評価は、ヘッダFrom（≠ envelope-From）に対して実施される

　設定が終わって、検証しようと telnet でポート 25 へ接続して手作業でメール送信したのですが、何故か全く署名されない。
　？？？となりつつ、散々あっちを弄りこっちを弄りした後、ふと思い立って通常のローカルメーラから送信したところ…此は如何に、あっさり署名が付加されました。

　カラクリは恐らくこうかと。
　telnet にて手作業で送信した場合、明示的に記述しない限りヘッダ From は付加されません（まぁ当然です）。その場合、次の MTA へ配送される前に、MTA により envelope-From を使ってヘッダ From が補完されます。その為、通常は意識されません。
　しかし、OpenDKIM の処理（というか SendMail INPUT_MAIL_FILTER の処理）は、このヘッダ From が補完前におこなわれるようなのです。
　結果、空のヘッダ From が評価され、「署名対象外メール」と判定されていたのだと考えています。

　その後、ヘッダ From が補完され、そのメールが届いていたので「ちゃんと対象の From だよなぁ…」と気がつくのが遅れました。
　OpenDKIM の評価はヘッダ From に対して実施される（これもまぁ当然です）、と明示的に認識していれば、もう少し早く気がつくことができたと思うのですが…。

Excel データの改行コードを変換

　謎仕様なのですが、Microsoft Excel のセル内改行コードは LF（0x0A）だったりします。
　一方、Windows OS 標準の改行コードは、CR+LF（0x0D0A）です。

　この辺りの相違にはきっと歴史的な経緯があるのでしょうが、具体的な事情は寡聞にして謎のままです。一説によると、Excel は当初 Mac 用（Mac の改行コードは LF）のアプリケーションとして開発された為だそうですが、真偽の程は？
　確かなことは、この改行コードの相違が時としてトラブルの原因になることです。

　Excel でデータを一括で入力して、それを他のシステムで利用するといったシーンで、改行コードの相違を意識せずに処理してしまうと、利用先システムで改行されずにベッタリ一行で表示されてしまったりします。
　なので、そういう場合どこかで改行コードを変換する必要があります。

　いろいろな段階で、いろいろな手法があり、「真面目」なやり方としたら Excel 上で VBScript を使ったり、データベース上で SQL を使ったりとかになるかと思います。
　しかし、今回の方法はズバリ、相当にズボラな方法です。

　必要な物は、テキストエディタ。
　ただし、改行コードの自動変換をしてくれないとダメですので、「メモ帳」では NG です（ただし、これはこれで使い様が…後述）。
　動作確認したのは「秀丸エディタ」ですが、「サクラエディタ」とかも同様に処理してくれるようです。

　手順は以下のとおり。
　ちなみに、Excel は 2010 ですが、他のバージョンでも問題ないものと思います。

1. Excel： 適宜範囲選択して Ctrl+C でコピー
2. テキストエディタ： Ctrl+V で貼り付け
3. テキストエディタ：  [名前を付けて保存] （選択できるようなら、改行コード CR+LF を選択）
4. テキストエディタ： 保存したファイルを開き直す
5. テキストエディタ： 貼り付けた範囲を選択して Ctrl+C でコピー
6. Excel： Ctrl+V で貼り付け

　以上で、見た目は変わりませんが、Excel 上のデータの改行コードは CR+LF になっています。
　ただし、後から追加した改行については LF になりますのでご注意を。

　ちゃんと改行コードが変換されたかの確認方法ですが、これは「メモ帳」を使ってズボラします。
　「メモ帳」は LF のみの改行に対応していないので、貼り付けたデータが改行されていなければ LF ですし、改行されていれば CR+LF と判断できます。
　試しに、手順1 のデータを（複数セルだと判りにくいので 1セルだけ）貼り付ければ改行されないでしょうし、手順6 のデータを貼り付ければ改行されるはずです。

　なお、手順 3, 4 は省いても多分問題無いと思います。少なくとも、「秀丸エディタ」の場合は問題ありません。
　ただ、保存するときに機種依存文字がチェックされますので（これも「秀丸エディタ」の場合は…ですが）、自分は一手間入れるようにしています。

Windows の悪仕様 [F1] キーを無効化

　[F1] キーで「ヘルプ」が開くのは Windows の悪仕様である…というのは、衆目一致するところだと思うのですが、バージョンを重ねても代々踏襲され続けていますよね。
　多分、Windows 10 でも引継がれるんでないでしょうか。

　これ、[F2] キーを使用する際によく押し間違えるんですよ。[F2] キーは、ファイル名の変更や、Excel セル値の変更で多用するキーです。
　押し間違える都度、「ヘルプ」が開くわけです。しかも、マシンスペックによっては開くまでに相応の時間を要する上、その間操作できなくなり非常にストレスフルです。

　そこで、OS のスキャンコードマップを変更して、[F1] キーを無効にしてしまいます。
　これ、かれこれ 2、3年ほど前から設定していますが、意図せず開く「ヘルプ」に煩わされることもなくなり、非常に快適です。

　この方法の問題点としては、OS レベルで完全にキーを無効にしてしまうので、[F1] キーが全く使えなくなるということがあります。
　とはいえ幸か不幸か、ほとんどのアプリケーションで [F1] キーは「ヘルプ」に割当てられているため、今のところ困ったことはありません。ただ、一部特殊なアプリケーション（キーボードをフルに使うゲームとか）では問題が発生するかもしれません。まぁ私の場合は、ゲームをあまりしない人間なので。

　さて、設定方法ですが、レジストリを変更します。
　「『レジストリ』って何？」という方は、とんでもないところを編集してしまうとシステムに致命的なダメージを与えかねませんので、やらないほうが無難だと思います。なので、エディタの起ち上げ方等、作業の具体的手順については触れません。

　ターゲットのレジストリキーは、以下になります。

OS 全体に適用する場合：
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout]

ログオン中のユーザにのみ適用する場合：
[HKEY_CURRENT_USER\KeyBoard Layout]

　いずれかのキーの下へ、以下の値を追加します。

名前： Scancode Map
種類： バイナリ値（REG_BINARY）

　で、この値に入れるデータは次のとおり。

00 00 00 00 00 00 00 00 02 00 00 00 00 00 3B 00 00 00 00 00

　これの意味するところは、以下のようになります。

00 00 00 00 ：ヘッダ（固定）
00 00 00 00 ：ヘッダ（固定）
02 00 00 00 ：設定の数（1） + 1（フッタ分）
00 00 3B 00 ：無効（0x0000） ← F1（0x003B）
00 00 00 00 ：フッタ（固定）

　なので、別に「無効（0x0000）」としなくても、他のキーに割り当てることも可能です。
　コードの一覧は、以下が参考になります。

Keyboard Scan Code Specification - Microsoft
http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/scancode.doc

　なお、レジストリ値に組込む際は、リトルエンディアンになることに留意してください。例えば、[右Alt] キーはコード 0xE038 ですが、レジストリ値へは 38 E0 となります。
　コードは左右入換て使わないといけない、と覚えておけば良いかと思います。

　ご参考まで、私の設定値を上げておきます。

00 00 00 00 ：ヘッダ（固定）
00 00 00 00 ：ヘッダ（固定）
04 00 00 00 ：設定の数（3） + 1（フッタ分）
5C E0 38 E0 ：右Windows（0xE05C） ← 右Alt（0xE038）
5D E0 1D E0 ：Application（0xE05D） ← 右Ctrl（0xE01D）
00 00 3B 00 ：無効（0x0000） ← F1（0x003B）
00 00 00 00 ：フッタ（固定）

Web Form での IME制御を無効化

　Web Form で自動的に IME（日本語変換）が on/off される、あの制御の話です。

　あれ、正直非常に迷惑です。
　多くの人がそうだと思うんですが、勝手に制御されずとも半ば無意識に左手が動いて IME の on/off を切り替えるんですよね。「あ、ここは日本語で入力しないと（無意識に IME on）」、「ここは英文字入力ね（無意識に IME off）」といった具合です（厳密に言えば、自分の場合は日本語入力が終わったら、直ちに IME を off にするんですが）。
　なので、勝手に IME の制御をされると、言わずもがなですが途端におかしな事になってしまいます。

　そこで、この IME の自動制御を、強制的に無効化します。

Internet Explorer

　Internet Explorer 8 以降であれば、以下の方法で無効化できます（それより旧い Internet Explorer でもできるかもしれませんが、手元にないもので）。

　まず、テキストエディタ（メモ帳とか）で以下のファイルを作り、拡張子「.css」（ファイル名は何でもいいです）で適当な場所へ配置します。
　自分でしたら、%APPDATA%\Microsoft\Internet Explorer 辺りに配置しますが、間違って消さないような場所であれば、どこでも結構です。

---------- .css ココから
* {
  ime-mode: auto !important;
}
---------- .css ココまで

　そして、Internet Explorer の [ツール]-[インターネット オプション]-[全般]-[ユーザー補助] と開いて、[自分のスタイル シートでドキュメントの書式を設定する] チェックボックスを on にします。[参照] ボタンが有効になるので、ボタンを押して先に作成した「.css」ファイルを指定します。
　あとは [OK] ボタンを押していって設定ダイアログを閉じれば完了です。

　念のため、OS 再起動（おまじないです）。
　これで、IME の制御を無視してくれるようになります。

Fire Fox

　現行バージョンの FireFox（Ver. 38）であれば、以下の方法で無効化できます（それより旧いバージョンに関しては…同上）。

　Internet Explorer と同じ内容で、CSS ファイルを作ります。
　ただしファイル名は「userContent.css」とします。

　そのファイルを以下のフォルダへ配置します。
　最後の「chrome」というフォルダは、最近の FireFox であれば存在していないと思いますので、その場合は自分でディレクトリを作ってください。

%APPDATA%\Mozilla\Firefox\Profiles\英数字.default\chrome\

　以上で完了です。

　念のため、OS 再起動（同上）。
　これで、IME の制御を無視してくれるようになります。

Google Chrome

　Google Chrome の場合は、設定の必要がありません。
　IME への制御を端から無視するようになっています。いえそもそも、どう頑張っても制御することができません。

　この辺り意見が分かれるかもしれませんが、IME制御反対派としては viva Google Chrome!