自堕落な技術者の日記

基本は喰ってるか飲んでるかですが、よく趣味でカラオケ・PKI・署名・認証・プログラミング・情報セキュリティをやっています。旅好き。テレビ好きで芸能通

jsrsasignの寄付金を募ることにしてみました(やりがいって何だっけ?)

私はjsrsasignというJavaScriptのオープンソース暗号、PKIライブラリを個人的な趣味で開発し公開しています。ところが最近、npmパッケージのダウンロードが月間60〜70万件と、異常にユーザーも増え、製品でも使われ始め、ちょっと厄介なことになっており、いろいろ悩んだ挙げ句、これが正解なのかもわかりませんが、ライブラリの維持のために寄付金を募ることにした次第です。今日は、心の吐露をつらつら書いていくことにします。

jsrsasignとは

2010年ごろ、スタンフォードの学生さんであるTom Wooさんという人のJavaScriptでRSA暗号化できるコードを見つけ、自分はPKIや電子署名を専門にしていたので「JavaScriptでRSA署名できたら面白いな」と思い、2010年6月に、ほんのRSA署名単機能のライブラリとして公開したのが jsrsasign です。当時のはしゃぎっぷりはブログでこんな感じ。 小躍りしてツイートしてたのはこんな感じ。




その後、ASN.1ライブラリ、X.509証明書、CRL、CMS SignedData、タイムスタンプ、CAdES-BES/EPES/T、OCSP、CSR、共通鍵暗号、楕円曲線暗号、RSA-PSS署名、DSA署名、JSONのJWS、JWT、JWKの対応など、自分が欲しいと思う機能を少しずつ建て増しをして10年になります。多くの個人のオープンソースプロジェクトは1年くらいで終わってしまうそうですが、まぁ、なんとか自分のために追加開発やメンテナンスを続けています。

このライブラリが特徴的なのは、

なんでも入っている
一つライブラリに多くのPKI、暗号の機能がつめこんであります。 Swiss Army Knife(スイスの十徳ナイフ)スタイルというそうです。 自分がものぐさなので、これをロードしさえすれば何でも試せるように作りました。
とにかく使い方が簡単
どんな秘密鍵でも公開鍵でも自動判定してロードできるようになっていたり、ASN.1 DER構造の中身に簡単にアクセスできたり、面倒くさいことはなるべくライブラリに任せてできるようになっています。証明書やタイムスタンプなどはJSONのプロパティから簡単につくることもできます。共通鍵暗号も簡単です。APIの構成はJavaのBouncyCastleライブラリIAIKライブラリなどのJCEアーキテクチャを参考にしているので、それを知っていればさらに使いやすいでしょう。自分がものぐさだから(二回目)、極力短いコードでいろんなことができるようになっています。
ドキュメント、サンプルが非常に豊富
ライブラリはあってもAPIドキュメントがなくてどんなAPIがあるのわからなかったり、BoucyCastleみたいにメソッドはわかるけど呼び出し方がわからないなどのことが無いようにAPIドキュメントの記述が充実しており、APIドキュメント中に例も入れています。また、Wikiなどの入門解説ページや、多数のオンラインでも試せるサンプルコード、テストコードがあり、自学習でもかなり何とかなると思います。APIが前提知識最小でも行けるように工夫してますので。
環境依存がほぼ無い、他のパッケージの依存がない
JavaScriptが動く環境であればどこでも動作します。古いブラウザでもほとんどの機能は動作しますし、Node.jsでも動きます。npmパッケージでも公開されていますし、CloudFlareなどのCDNからも利用できます。必要なサードパーティの関数は含まれており、他のライブラリ、パッケージに全く依存しておらず単独で使えます。Nodeの中でOpenSSLに依存していることもありませんし、(ブラウザ互換性でいつも悩まされる、この先どうなるかもわからない)W3C Web Cryptography APIを使っているわけでもありません。
いろんなツールがすぐ使える
自分でプログラミングしなくても、オンラインで公開しているツールで証明書を発行したり、鍵ペアを生成したり、デジタル署名の生成や検証したり、JWTを生成したり、いろんなことができます。Nodeで実装されたいろんな便利なPKI関連ツールもついています。
速いとは言えない
自分がPKI関連のいろんなことを少ないコードで簡単にテストするために作っていますので、高速に動作することを目的にしていません。数百万のトランザクションを処理したいといった目的なら他のライブラリを使う方がいいでしょう。
一人でここまでよくやったなぁ、、、と。お節介か、、、www

jsrsasignの歴史を振り返る

10年だもの、まぁ、いろいろありますよ。自分のためにちょっと歴史を振り返ってみます。

  • 2010年6月:v1.0:jsrsasign初版公開。RSA署名だけ。
  • 2012年4月:v1.2:公開リポジトリをGitHubに移行。
  • 2013年4月:v2.0:PKCS#1 PEMなどの鍵のロード機能がつき始める。 JavaライクなSignature、MessageDigestクラス、ASN.1エンコーダー、X.509証明書エンコーダー、RSA-PSSサポートなど
  • 2013年5月:v3.1:暗号化されたPKCS#5鍵のロードのサポート
  • 2013年6月:v4.0:ECDSA署名サポート
  • 2013年9月:v4.1:PKCS8など柔軟な鍵ロード用クラス KEYUTIL を追加
  • 2013年10月:v4.2:DSA鍵、署名のサポート
  • 2014年4月:v4.5:CMS SignedDataサポート
  • 2014年5月:v4.6:RFC 3161 Timestampサポート
  • 2014年7月:v4.7:RFC 5126 CAdES-BES/EPES/Tサポート
  • 2015年6月:v4.8:NodeJS npm、JSON JWS、JWK、JWTサポート
  • 2015年10月:v5.0:CSRサポート、便利なNode.JSスクリプトの追加
  • 2016年9月:v6.0:OCSPサポート
  • 2016年11月:v6.2:識別名のmulti valued RDN、RFC 2253 LDAP識別名文字列表現のサポート
  • 2017年6月:v8.0:コードのスリム化、長期間非推奨(Deprecated)だった関数の削除
  • その後、細かい機能追加や脆弱性指摘対応などが続き現在に至る

jsrsasignはどれだけ使われているか

自分の趣味でやってる調査のために開発したライブラリですが、Node.JSのパッケージ npm で公開した2015年あたりから利用者ダウンロードが増えています。github.comからのダウンロードや、勝手に行われている公開CDNからの利用もあると思いますが、npmパッケージのダウンロード数だけでいうとnpm-stat.comさんのダウンロード数グラフを見てみるに、2018年あたりからブリブリ増えてしまっており、2019年あたりからサチりはじめ、それでも最近の月間ダウンロードは60万件超、先月は70万を超えてしまいました。npmでは他のパッケージの依存関係を書けるのですが、2020年7月現在で379ものnpmパッケージのプロジェクトがjsrsasignに依存していることがわかります。とほほ。
jsrsasign-monthly-dl-202006
jsrsasignは自由に使ってもらっていいですが、ライセンスは放棄はしていないので、ライセンス掲載の義務はあり、たまにエゴサーチでPDFで検索してみると、いろんな製品の中でも使われちゃってることがわかります。

あとは、以前シャニマスのライセンス表示にjsrsasignが載っていたり、某社は使っているのにオープンにしていただいてなかったり、、、、(^^; こんな、個人が趣味で開発しているライブラリに、みなさん乗っかっちゃって大丈夫なんですかね。逆に心配になっちゃいますね。

ユーザが増えた悩みの始まり

最初は、「自分の調査のために趣味で維持しているライブラリがみなさんの役にたって、使ってもらえてるなら良いことだなぁ。これからも趣味で自分の必要そうな機能は追加していこうかなぁ、、、」で済んでたんですが、最近ユーザーも増えてそうも言ってられなくなってきたんです。

そもそも、jsrsasignは MITライセンスの下で無償、無保証で配布されています。もし、セキュリティ脆弱性やバグがあっても、私には修正する義務はないし(とはいえ、指摘されたら直すわけですが)、オープンソースなので問題があれば好きに修正して使っていただいていいわけです。もちろん修正コードをもらえれば、それは反映してすぐに公開します。

そんな中おきたThe RegisterやUsenixの指摘

2020年5月にITセキュリティのニュースサイトであるThe Registerで 「What happens when the maintainer of a JS library downloaded 26m times a week goes to prison for killing someone with a motorbike? Core-js just found out」という記事が掲載されました。JavaScriptのバージョンの違いを吸収するためのCore-jsという有名なライブラリがあって、その開発者がバイクで交通事故を起こして被害者の方が亡くなり収監されて、ソフトウェアのアップデートが滞っており問題だというものでした。

この記事の中で、私のjsrsasignも、2018年4月から2020年まで更新されてないと指摘をされてしまいました。

(記事引用)
Another JavaScript cryptographic library known as jsrsasign faces a similar challenge: its maintainer, Kenji Urushima, hasn't been active since April 2018. Programmers who use the software have expressed concern about the lack of communication and an unaddressed vulnerability, noting that 350 npm projects depend on the library, including some by Microsoft and Mozilla,
(抄訳)
jsrsasignとして知られている別のJavaScript暗号ライブラリも同様の課題に直面している。その管理者である Kenji Urushima は、2018年4月から活動していない。このソフトウェアを使用しているプログラマは、対話の欠如と対応されていないある脆弱性について関心を寄せている。注目すべきは、MicrosoftやMozillaを含む350のnpmプロジェクトがこのライブラリに依存しているという事である。
指摘された問題は、Minervaと呼ばれるECDSA署名のタイミング攻撃により処理時間を大量監視していれば秘密鍵が復元できる可能性があるというもので、元々、楕円曲線暗号の部分はBitcoin-JSを使っており、自分のコードではないので、調査するにしてもかなり時間がかかる根の深い問題でした。また、自分は本業の方も忙しい時期だったのでなかなか調査もできず、誰からも修正コードの支援をしてもらえないままでいました。jsrsasignは大量のトランザクションで使われることもあまりないし、攻撃の実現はかなり低いと考えていました。他の簡単に回答できるものには回答していましたが、根が深いのでこの問題は手付かずにしていたのです。

おそらくこの記事をうけて、USENIXという団体の機関紙のコラム「Who Will Pay the Piper for Open Source Software Maintenance? Can We Increase Reliability as We Increase Reliance?(誰がオープンソースソフトウェアの保守の費用を負担するのか?(オープンソースの)依存が増える中、信頼性を上げることできるのか?」の結論でも、jsrsasignを「(開発を)撤退したソフトウェア」として取り上げられてしまいました。

やっとMinerva脆弱性の修正

jsrsasignの根深い問題の調査まで手がまわらない状態が続いていたのですが、プライベートで慌ただしい時期がようやく終わりかかり落ち着きだした2020年4月、Node.JSのパッケージマネージャーを管理するnpmのセキュリティチームからもMinervaの脆弱性指摘が来てしまい、いよいよ直さざるをえない状況になりました。他の人が作ったコードを解析し、修正し、テストケースを作成して確認し、修正リリースを出しました。[勧告]

そしてまた別のMalleabilityに関する脆弱性指摘が3つも

2020年6月に Antonio de la Piedra さんから、3つのmalleability(展性)に関する脆弱性の指摘を受けてしまい、初めてUS-CERT、MITREの脆弱性データベースにCVE登録されてしまいました。3つのうちの1つは、npm のセキュリティチームからも対応依頼が来ました。「malleability(展性)」とは、金属を叩いて延ばしても破壊されずに広げることができる性質のことを言うのですが、ソフトウェアの世界では、同じ意味のデータを別の表現ができるという事をmalleabilityと呼んでます。例えば、10進数で数値の12345という値があったとして、先頭にゼロを幾つかつけて00012345としても値は同じであるといった事です。

暗号では、大きな数値を使って暗号文、署名値など表現することが多いですが、 指摘された3つの脆弱性は簡単には以下のようなものでした。

  • CVE-2020-14966 ECDSA署名の署名値が、前述のようなゼロを先頭に足した値を使ったものでも正しい署名として受け入れてしまう等。(CVSS3.X 7.5, CVSS2.0 5.0)
  • CVE-2020-14967 RSA暗号の暗号文が、前述のようなゼロを先頭に足した値を使ったものでも復号ができてしまう。(CVSS3.X 9.8, CVSS2.0 7.5)
  • CVE-2020-14968 RSA-PSS署名の署名値が、前述のようなゼロを先頭に足した値を使ったものでも正しい署名として受け入れてしまう。(CVSS3.X 9.8, CVSS2.0 7.5)
これが深刻な脆弱性にあたるかに関しては疑問があり、前述のようにゼロを足したとしても、別の署名対象文書を正しい署名として受け入れたり、暗号文の内容を別の内容に書き換えることができたりといった攻撃とは無関係です。また、大量にゼロを足した場合にメモリ破壊が起きると指摘されましたが、JavaScriptのBigIntegerでは、C言語のような桁あふれも発生しないので指摘にはあたらず、脆弱性を利用した攻撃は実現できないと考えています。vulndbのCVSSスコアはそれほどでもなかったですが、US-CERTのスコアはやたら高いです。

6月頃は仕事もプライベートも落ち着いていたので、週末や夜に対応の時間を取ることができ、問題の調査をし、コードを修正し、Antonioさんにもらったテストコードで問題なくなった確認し、2週間くらいで修正リリースし、セキュリティアドバイザリを公開しました。 [勧告1] [勧告2] [勧告3] かなり短期に対応できたかと思います。ちなみに、RSA-PSSはDaveさんが提供してくれたコードで、自分で解析して修正しなければならないので厄介でした。ECDSAについては、署名値が厳密なASN.1 DER構造であることをチェックしていなかったために起きた問題で、その厳密なチェックをする機能を追加するのにテストケースが多すぎて骨が折れました。

job_yarigai_sausyu_suit というわけで、オープンソースのライセンスで、現状有姿、無保証で提供するという条件で利用してもらっているにもかかわらず、結局、義務的に直さざるを得ず、問合せ対応や、報告者への対応、セキュリティアドバイザリの作成などしなければならない状況になっているのです。ソフトウェアの開発や保守でお金をもらっているわけでもないのに、とてもモヤモヤします。もちろん、本当に攻撃の影響を容易に受けてしまうような深刻な脆弱性については、何とか時間を作って急いで修正します。でも、「自分のために作ったライブラリを他の人が喜んで使ってくれるなら開発にかかったコストも要求せず、無料で、現状有姿で提供しましょう。」と言っただけなのに、多くの土日や夜まで潰して手厚いサポートまでタダで求めてくるのは「それは善意の搾取です!!!」とガッキーのように叫びたくなります。

同じオープンソースの暗号ライブラリでも、OpenSSLのように多くのメンバーが開発に関わっていて、修正パッチの提供も有志がやってくれるような状況なら、脆弱性指摘を対応する体制も作れますが、私一人で開発しているような状況なので、仕事やプライベートの都合でタイムリーに脆弱性対応できないケースがあります。そんな手厚いサポートを求められても困るのです。

私は、製品のセキュリティインシデントレスポンスチームであるPSIRTの仕事もしていたので、外部から脆弱性を指摘された場合に、しかるべき機関と調整しながら脆弱性対応する必要があることもわかっています。ただ、こうしたライブラリの場合は厄介で、よく使われる機能も、そうでない機能も様々取り揃えてライブラリを構成しているので、問題への影響が大きいのか小さいのかという判断をつけにくいです。そのため、リスクが高かろうが低かろうが「直せ」と要望が来てしまいます。なんか、段々、オープンソースを公開するのが面倒くさくなってしまいました。

そして寄付金を募ることにしました

「お金もらってるわけでもないのに文句言うな」とモヤモヤした気持ちを抱えたまま、jsrsasignを維持し続けるのもモチベーションが持ちそうにないので、ふと「寄付金」を受け付けてみてはどうかなぁ、、、と思いました。寄付金制度を導入すれば、どれだけの人がこの一人プロジェクトを応援してくれてるのかわかるし、「こんなに応援してくれてるんだから、ちょっと頑張らなきゃなぁ」という気持ちになるかもと思ったわけです。調べてみると、

  • (1) GitHubのスポンサー制度(毎月いくらとか設定して応援してもらえる。日本の口座もOK)
  • (2) Bitcoin、Bitcoin Cashなどの仮想通貨による寄付(自分の口座が放置されてた)
  • (3) Paypalによる寄付 (日本の金融機関ではできない)
  • (4) Open Collective (日本ではかなり敷居が高そう)
  • (5) Buy Me A Coffee (これも面倒くさそう。でも決済がGitHub Sponsorsと同じStripeだから可能性あるかな)
(1)は検索してみると日本の開発者の方も設定しているようで、いろんな方の設定内容を参考に設定することができました。(2)は、仮想通貨口座のアカウントの復旧、追加本人確認手続きが結構面倒だったんですが何とか復活させることができました。(3)はちょっと考えがあるので、そのうちチャレンジしてみようと思います。(1)の審査までの準備は、わからないことも多くて相当かかったのですが、審査申請して2週間と言われてたところを2日くらいで承認されました。(2)と合わせて、ようやく今日、READMEに寄付受付を書いてみました

今後、そのうちどうするか

と、まぁ、サポートや脆弱性対応のモチベーションは何とか寄付金で自分をだましだましやろうと思うんですが、自分もいい歳なので、自分が開発、サポートができなくなった時にどうするかですよね〜〜。急遽、長期入院などして何もできないことがあるかもしれませんし。GitHubでは、後継者を指定して何かあったとき、その人に管理を譲ることができる機能があるんですが、こんなわけのわからないソフトのメンテと問合せサポートを他人に押し付けるわけにもいかないので、多分自分が開発できなくなったら一代限りで終わりなんでしょうねぇ。ソースは全てリポジトリにあるので、引き継いでくれる人が世界のどこかから出てくるのかもしれませんが、完全にお任せで好きにしてもらうのが良いんじゃないかと思ってます。

ただ、自分に何かあったとき、「このプロジェクトは今後一切、メインの開発者がサポートできなくなりました。」と伝えてあげる必要はあるなぁと思っています。娘か知り合いに託すしかないのかなぁ。そうしないと、また The Registerの記事のような騒ぎになってしまうので、、、なんか、デジタル遺品とか終活ノートみたいな話ですね。

趣味でちょっと、好きなものだけ好きなように開発したかっただけなのになぁ、、、なんでこんなことになっちゃったのかなぁ、、、

こんなこと書いちゃってますが、開発はぼちぼち続けていきますよ。本人はいい加減な人間なので、そんなに気に病んでるわけでもないので、どうかお気になさらずに。 なんか、愚痴っぽい話につきあってもらってすみません。今日はこの辺で。

最近の証明書の話題(3): デジタル証明書形式の電子委任状のプロファイルに関する考察

お詫び:この記事は3月に書き始め、5月に大方できていたのですが、なんかボリューム満点な割に、落とし所がなくなってしまい、辛くなって放置していました。これが終わらないせいで、他の記事も何となく書くのが億劫になっていました。やっと8月末の今日、少し書き足して生煮え記事として供養させてくださいm(_ _)m。ただここで言いたいのは
(電子証明書方式の)電子委任状は、お役所への申請だけでなく、企業間の電子契約でも、前より格段に使いやすい証明書なので「ちゃんと普及してください!!!」
ってことだけです。

今日は正確には証明書ハンターネタとは言えないんですが、今後おもしろそうな、「電子委任状」という証明書が出てきそうってことで紹介したいと思います。ちょっと長いです。ご容赦ください。

もくじ
1. 電子委任状とは
2. 証明書の識別名の構造(おさらい)
3. デジタル証明書形式の電子委任状のサンプル発行
4. 汎用の証明書ビューアーで主体者別名の表示は問題ないか
 4.1. Windowsの表示
 4.2. macOSの表示
 4.3. Firefoxの表示
 4.4. Adobe Acrobat Reader DCの表示
 4.5. Java JCE SUNプロバイダの表示
 4.6. Java JCE BouncyCastle BCプロバイダの表示
 4.7. OpenSSLのx509 -textコマンドによる表示
 4.8. 表示結果サマリ
5. 電子委任状の識別名に関する考察
 5.1. 属性タイプについて
 5.2. organizationIdentifier属性タイプについて
 5.3. description属性タイプについて
 5.4. OUを使う事の是非について
 5.5. ではどの属性タイプを使うのが良かったのか
 5.6. 似た日本語文字の問題
 5.7. その他、記載例における細かい課題

1. 電子委任状とは

既にご覧になっている方もいるかもしれませんが、 2018年1月から「電子委任状の普及の促進に関する法律(電子委任状法)」が施行されました。

ある程度の規模以上の会社になってくると、契約や行政手続きなどで、社長さん自らそのような事務処理をすることは少ないと思いますが、ICカード使って電子署名するとか言うと本人しか暗証番号知らないはずなので困っちゃうんですよね。パソコン苦手な社長さんだと、ICカードと暗証番号毎渡しちゃって処理をお願いしたりしてね。
電子委任状fig1
そこで、社長さんが決めた代理の人に対して、電子委任状なるデータを与えることによって、そのような契約や申請手続きをオフィシャルに社長の代理でできるようにして、電子化を促進しようという法律なのだそうです。
電子委任状fig2
ICカードと暗証番号は、本人しか使えないように管理しなければならないというのが利用の原則なんですが、電子委任状によって、ちゃんと申請や契約する本人(=代理人)が管理するICカードができるようになるというのがミソかと思います。

そういえば先日、5月23日に日本ネットワークセキュリティ協会(JNSA)の電子署名WG春祭り「電子署名の世界(SIGN WORLD)」があり、弁護士の宮内宏先生が「個人の電子証明書と法人役職者の電子証明書  〜意外と使える電子委任状法〜」というタイトルでお話ししてくださいました。 電子委任状については、一番良い解説スライドだと思うのでみなさん見て欲しいんですが、 一番ストンと腑落ちしたのがこの電子証明書の比較に関するスライドで、マイナンバーカードも、認定認証業務の証明書も、特定認証業務の証明書も、商業登記の証明書しかり、日本の電子署名法で使える証明書は

  • 基本的には会社の代表者(会長さん、社長さん)向けの証明書か、
  • 個人の氏名と住所情報が入っている証明書
しか、使えないんですよね。ビジネスだと、部長さんの自宅住所なんかどうでもよくて、名前も場合によっては必要なく、むしろ肩書きなんかを書いていある方が重要ですよね。こりゃ、これまでの証明書はビジネスで使いにくいわけだなぁ、、、と。これとは違って、省庁の方の官職証明書は名前も、住所も入っていないくて、省庁の名前と役職で、使いやすくなってるのにね。

電子委任状の発行は、誰でも発行できるわけでなく、役所がするわけでもなく、電子委任状取扱業務の資格を持つ第三者のサービスがそれを行うことになるそうで、申請確認プロセスが同じなので、国内の証明書発行サービスが担うようになりそうとの事。電子委任状は普通のPDF(署名)文書のような形式もあるそうですが、X.509デジタル証明書による形式もあるそうです。(ココ、食いつき所ですよっ!!!)

デジタル証明書形式の電子委任状について、どのような項目を記載するか、いわゆる証明書プロファイルについては、総務省が発行している指針の解説書の25ページに記載例があります。この記載例を作る時に、総務省、日本電子認証局会議、日本ネットワークセキュリティ協会(JNSA) 電子署名WGが議論する会合がありまして、私もたまたま声をかけて頂けました。

この記載例には、幾つか課題もあるように思いますが、そこはスルーして、電子証明書方式の電子委任状のポイントは以下かと思います。

  • 社長さんなど委任する側の人(委任者)と委任される人(受任者)の情報はsubjectAltName(SAN)に、 directoryNameとして記載される。
  • (SAN)のdirectoryNameの属性タイプは、 O、OU、CN、ST(stateOrProvince)、L(Locality)、T(title)、description、organizationIdentifierが使われる。
  • 記載内容の詳細については、定められたプリフィクスも含めて、ディレクトリ属性値に設定している。例えば、社長さんなど組織の代表者には「組織代表者名:」というプリフィクスを使って 「組織代表者名:山田太郎」のように設定している。

2. 証明書の識別名の構造(おさらい)

証明書の識別名は

属性1タイプ1=属性値1, 属性1タイプ2=属性値2, 属性1タイプ3=属性値3 ...
の構造になっています。属性タイプはオブジェクト識別子(OID)で、2.5.4.10みたいなやつ、属性値はASN.1の文字列タイプ(DirectoryStringType)になります。

3. デジタル証明書形式の電子委任状のサンプル発行

趣味でjsrsasign という、JavaScriptベースの暗号/PKIライブラリを公開していますが、 今回の調査に合わせて、この電子委任状に必要な全属性タイプのサポートを追加しましたので、 サンプルのCAページ を使えば簡単に電子委任状もどきの証明書を生成し、証明書の表示確認などに 使うことができます。
toolca

電子委任状では主体者別名(subjectAltName)に特徴があるので、 確認ではこれのみを設定すればよく、 タイプを「DN」にし、値に以下をペーストし、
toolca-san

/organizationIdentifier=JCN1111111111111/O=株式会社アイツー/description=組織所在地:東京都渋谷区神宮前3−3/description=組織代表者肩書き:代表取締役社長/description=組織代表者生年月日:1972/04/27/description=組織代表者名:鈴木花子/CN=山田太郎/T=購買部長/description=部門所在地:東京都新宿区西新宿5−5/description=代理権内容:日本国内の1億円以下の購買行為/description=代表権制限:1億円以下の発注購買
気になるならば、主体者名(subject)を以下に設定します。
/CN=Taro Yamada/ST=Tokyo/L=Shinjuku-ku Nishi-Shinjuku 5-5
「Issue Certificate(証明書発行)」ボタンを押せば、証明書データが生成れます。 上記の入力では、主体者別名の属性タイプを選択できるものは一般的なOUではなく、表示テストのために珍しいdescriptionを使っています。また、解説書では主体者名の都道府県でS=TokyoのようにstateOrProvinceは"S="を使っていますが、OpenSSLやjsrsasignでは"ST="を使います。

上記の主体者別名の例を見やすいように改行を入れると以下のようになります。

/organizationIdentifier=JCN1111111111111 /O=株式会社アイツー /description=組織所在地:東京都渋谷区神宮前3−3 /description=組織代表者肩書き:代表取締役社長 /description=組織代表者生年月日:1972/04/27 /description=組織代表者名:鈴木花子 /CN=山田太郎 /T=購買部長 /description=部門所在地:東京都新宿区西新宿5−5 /description=代理権内容:日本国内の1億円以下の購買行為 /description=代表権制限:1億円以下の発注購買
値は、自分の名前など、自由に変更して入力してもらえれば良いかと思います。

4. 汎用の証明書ビューアーで主体者別名の表示は問題ないか

電子委任状でデジタル署名された申請文書やデータの表示には、専用アプリケーションが提供される可能性も高いですが、PDFやWordなど汎用アプリケーションのデータとして交換されることもあるかと思います。OSやブラウザに搭載されている証明書ビューアーで電子委任状用のデジタル証明書を表示させた場合、特に主体者別名の表示に問題がないか、ちょっと見てみましょう。

4.1. Windowsの表示

Windowsでは以下のような表示になり概ね問題なさそうです。スクロールさせなきゃいけないので画像は少し貼り付けしてます。
attorney5_win1merge

4.2. macOSの表示

macOSのキーチェーンをつかって、上記の方法で作成した電子委任状証明書サンプルの主体者別名を表示させると以下のようになります。
cer-attorney-mac

4.3. Firefoxの表示

Firefoxでは以下のような表示になり概ね問題なさそうです。スクロールさせなきゃいけないので画像は少し貼り付けしてます。
attorney5-ff1merge

4.4. Adobe Acrobat Reader DCの表示

デジタル署名したPDFを作成し、Adobe Acrobat Reader DCで表示させると以下のようになります。こちらも概ね問題ありません。
attorney5-pdf1

4.5. Java JCE SUNプロバイダの表示

Java JCEで標準のSUNプロバイダを使って証明書を読み込みオブジェクトをprintln()で表示させた時の、主体者別名部分の表示は以下の通りです。こちらも特に問題はありません。

[4]: ObjectId: 2.5.29.17 Criticality=false SubjectAlternativeName [ OID.2.5.4.13="代表権制限:1億円以下の発注購買 ", OID.2.5.4.13=代理権内容:日本国内の1億円以下の購買行為, OID.2.5.4.13=部門所在地:東京都新宿区西新宿5−5, T=購買部長, CN=山田太郎, OID.2.5.4.13=組織代表者名:鈴木花子, OID.2.5.4.13=組織代表者生年月日:1972/04/27, OID.2.5.4.13=組織代表者肩書き:代表取締役社長, OID.2.5.4.13=組織所在地:東京都渋谷区神宮前3−3, O=株式会社アイツー, OID.2.5.4.97=JCN1111111111111 ]

4.6. Java JCE BouncyCastle BCプロバイダの表示

Java JCEで、フリーで有名な暗号ライブラリ BouncyCastleのBCプロバイダを使って証明書を読み込みオブジェクトをprintln()で表示させた時の、主体者別名部分の表示は以下の通りです。ASN.1ダンプとして表示されるだけですが、こちらも特に問題はありません。

Tagged [4] DER Sequence DER Set DER Sequence ObjectIdentifier(2.5.4.97) UTF8String(JCN1111111111111) DER Set DER Sequence ObjectIdentifier(2.5.4.10) UTF8String(株式会社アイツー) DER Set DER Sequence ObjectIdentifier(2.5.4.13) UTF8String(組織所在地:東京都渋谷区神宮前3−3) DER Set DER Sequence ObjectIdentifier(2.5.4.13) UTF8String(組織代表者肩書き:代表取締役社長) DER Set DER Sequence ObjectIdentifier(2.5.4.13) UTF8String(組織代表者生年月日:1972/04/27) DER Set DER Sequence ObjectIdentifier(2.5.4.13) UTF8String(組織代表者名:鈴木花子) DER Set DER Sequence ObjectIdentifier(2.5.4.3) UTF8String(山田太郎) DER Set DER Sequence ObjectIdentifier(2.5.4.12) UTF8String(購買部長) DER Set DER Sequence ObjectIdentifier(2.5.4.13) UTF8String(部門所在地:東京都新宿区西新宿5−5) DER Set DER Sequence ObjectIdentifier(2.5.4.13) UTF8String(代理権内容:日本国内の1億円以下の購買行為) DER Set DER Sequence ObjectIdentifier(2.5.4.13) UTF8String(代表権制限:1億円以下の発注購買 )

4.7. OpenSSLのx509 -textコマンドによる表示

OpenSSLの以下のコマンドで証明書情報を表示させた場合、

% openssl x509 -in aaa.cer -noout -text
結果は以下のようになります。
X509v3 Subject Alternative Name: DirName: /2.5.4.97=JCN1111111111111 /O=\\xE6\\xA0\\xAA\\xE5\\xBC\\x8F\\xE4\\xBC\\x9A\\xE7\\xA4\\xBE \\xE3\\x82\\xA2\\xE3\\x82\\xA4\\xE3\\x83\\x84\\xE3\\x83\\xBC
日本語部分は16進数表示されてしまいました。

4.8. 表示結果サマリ

調査した複数の汎用アプリケーションにおいて、証明書ビューアーで電子委任状のデジタル証明書を表示した結果のまとめは以下のようになりました。問題のある箇所を赤系のセルにしています。

macOS Windows Firefox Acrobat Java SUN Java BC OpenSSL
読み込み 問題なし 問題なし 問題なし 問題なし 問題なし 問題なし 問題なし
表示崩れ なし なし なし なし なし なし あり(※1)
stateOrProvince(ST)属性表示 都道府県/州 S=(※2) ST= st= ST= OIDまま ST=
locality(L)属性表示 所在地 L= L= l= L= OIDまま L=
organization(O)属性表示 組織 O= O= o= O= OIDまま O=
organizationalUnit(OU)属性表示 部署 OU= OU= ou= OU= OIDまま OU=
commonName(CN)属性表示 通称 CN= CN= cn= CN= OIDまま CN=
description属性表示 説明 Description= OIDまま OIDまま OIDまま OIDまま description=
title(T)属性表示 タイトル T= OIDまま title= T= OIDまま title=
organizationIdentifier属性表示 その他名前(※9) OIDまま(※3) OIDまま(※4) OIDまま(※5) OIDまま(※6) OIDまま(※7) OIDまま(※8)
※1:OpenSSLコマンドではSANの全てのRDNは表示されない。日本語属性値が16進数表記で可読性がない。
※2:WiindowsのみstateOrProvinceを"S="のように省略表記する。
※3:WindowsのOID表記例「OID.2.5.4.97=値」
※4:FirefoxのOID表記例「Object Identifier (2 5 4 13) = 値」
※5:Adobe Acrobat Reader DCのOID表記例「2.5.4.13=値」
※6:Java JCE SUNプロバイダーのOID表記例「OID.2.5.4.97=値」
※7:Java JCE BCプロバイダーのOID表記例「DER Sequence ObjectIdentifier(2.5.4.13) UTF8String(値)」
※8:OpenSSLのOID表記例「2.5.4.97=値」
※9:macOSでは「その他名前」となり元OIDが何であったか情報が無くなる。

5. 電子委任状の識別名に関する考察

解説書に基いてサンプルの電子委任状を発行してみましたが、主体者名、主体者別名における課題について考察したいと思います。

5.1. 属性タイプについて

主体者名(subject)や主体者別名(subjectAltName)の識別名において、 属性タイプはITU-T X.509としては何でも構わないが、 標準的なものはITU-T X.520で定義されていて、 X.500 attirube typesの一覧はここでも見られます。 ただ、ITU-T X.520では、X.500ディレクトリやLDAPで使用可能な 属性タイプが全て含まれていて、例えばLDAPエントリとして、 ユーザーのパスワードを格納する id-at-userPassword属性や、 CA証明書を格納する id-at-cACertificate 属性が定義されていたとしても、 証明書でこの属性タイプを使うことは常識的にないでしょう。

そこで、インターネットで証明書を含むデータを交換する場合のために、 ITU-T X.509では、選択肢が広すぎて困っていたものを、 利用可能なオプションを制限するためのプロファイルを RFC 5280として 定義しています。

属性タイプに関する記述は、 4.1.2.4節 発行者(Issuer)の節に書かれており、 これと同じルールが主体者名、主体者別名にも適用されます。 ルートしては、実装が処理または受理できる属性タイプについて述べられています。

  • C、O、OU、distinguishedNameQualifier、ST、CN、serialNumber、DCは受理できなければならない(MUST)。
  • L、T、surname、givenName、initials、pseudonym、generationQualifierは受理できるべきである(SHOULD)。
これらにない属性タイプが全く使われないわけではなく、例えばEV証明書でjurisdictionOfIncorporationC(登録管轄国)などの属性が使われているが、別のガイドや標準で規定しない限りは、上記以外の属性タイプを使って、プログラムが異常終了したり、エラーが発生したとしても文句は言えないわけです。相互運用性の問題が発生するので、RFC 5280で記載された属性タイプを使う方が安心かと思います。

5.2. organizationIdentifier属性タイプについて

organizationIdentifier属性タイプは、一般には企業や組織の番号を表すために用いられ、電子委任状では「国税庁が指定する法人番号」を記載するとしています。欧州の国民IDであるeIDAS規則の電子証明書でも、organizationIdentifierが使われており、徐々に浸透していくであろう属性ではありますが、

  • 5.1節で述べた通り、RFC 5280には無い属性であり
  • 4.8節の汎用証明書ビューアーでも表示されない属性タイプである
  • 他のほとんどの属性では、「代理権内容:」のようなプリフィクスを使った表記にしている
などの事から、この属性だけを、無理に厳格にorganizationIdentifierを使う必要もなかったのではないかという気がします。

5.3. description属性タイプについて

電子委任状の主体者別名(subjectAltName)に記載される多くの属性は、 description(2.5.4.13) もしくは organizationName(2.5.4.10)のいずれかの属性タイプを用い、 「代理権内容:」のようなプリフィックスを値に含めて記載することになっています。 私は、様々な変わったX.509証明書を収集するのが趣味で、 いろんな証明書をこれまで見てきましたが、識別名にdescription属性タイプを使用した 証明書を見たことがありません。 descriptionは一般には、LDAPなどのディレクトリにおいて、 あるエントリの補足情報や備考情報をメモ的に記載するために用いるのが 一般的な使用法かと思います。 相互運用性の観点から、あまり使用しない方が良かったのではないかと考えます。 海外のPKI有識者も「日本はヘンな事やっちゃってるなぁ、、、」と考えるんじゃないかと思います。

5.4. OUを使う事の是非について

前述のように電子委任状の多くの属性では、 その属性が本人に帰属するものか、 組織に帰属するものかに関わらず、 識別名の属性タイプがOUもしくはdescriptionの いずれかを使うことになっています。

一般に、OUは人事部、総務部、開発部、採用課といった 部署名を表すための属性ですので、 主体者に紐づく雑多な属性 を記載するためのふさわしい属性タイプではありません。 OUを使った場合に、特に違和感がある電子委任状の属性は、 以下のところかと思います。

  • 委任者する側の法人の商業登記における本店所在地:(例)OU=組織所在地:本町3−3
  • 委任者する側の法人代表者の肩書き:(例)OU=組織代表者肩書き:代表取締役社長
  • 委任者する側の法人代表者名:(例)OU=組織代表者名:山田太郎
  • 委任者する側が個人事業主の場合、その生年月日:(例)OU=組織代表者生年月日:1970/04/01
主体者の属性であれば、CN(commonName)を使うべきだったのではと思います。

5.5. ではどの属性タイプを使うのが良かったのか

以上で示してきたように、

  • description属性タイプの利用は、過去に使用例が見当たらず相互運用性の観点からも問題があるのではないか。
  • OU属性タイプの利用は本来、部署名を表す属性であるため適切ではないのではないか。
いずれも、多少なりとも問題があるように思います。 主体者個人に帰属する属性はcommonName(CN)を使用するのが良かったのではないかと考えています。

EV証明書のように、個々の属性に対し、個別の属性タイプ、例えば「組織代表者生年月日」に対して「0.2.440.100145...23」を定義する方法もあったわけですが、そのような特殊な属性は汎用の証明書ビューワーでは表示されず視認性が悪いので、descriptionやOUを使い、「組織代表者生年月日:」のようなプリフィクスを用いて表記するのは、それほど悪くない方法だったのかなと考えています。

5.6. 似た日本語文字の問題

プリフィクスに「組織所在地:」のようにコロン「:」が使われていますが、 解説書のページでは全角文字を使う事になっているようです。表記の揺らぎがないように、プリフィクスはUTF-8でどのようなバイト列(オクテット列)になるのか、明記しておくのが良いように思います。

また、ある文字と異なる文字、非常ににた形の文字がバイト列上(=Unicodeコードポイント上)別の文字にされてしまうことがあります。これを攻撃に使った場合ホモグラフ攻撃と呼ばれており、これを不正な証明書の発行に使われてしまうかもしれません。例えば、下の「日」文字は形が似ていますが別の文字です。

日野市 (日=U+65E5 正しい)
曰野市 (曰=U+66F0)

日本、中国、韓国で使われる文字でこのような似たような形で、異なる文字はあるようで、電子委任状においては解説書別表

日本語で記載する場合、JIS第1水準・第2水準、補助漢字以外の文字は、代替文字に変換すること。このとき、代替文字仕様位置情報を証明書に付与することが望ましい。
と記載されており、上記の「日」も正しい「日」で統一されるように代替文字の変換情報が提供されるかもしれません。認証局は「JIS第1水準・第2水準、補助漢字」の範囲内であるかの確認が必要になりますね。

アパートやマンションの名称でローマ数字(IV等)が使われることがありますが、これは拡張漢字となるので注意が必要で、アルファベットで表記する必要があります。(「I」+「V」=「IV(二文字)」)

5.7. その他、記載例における細かい課題

解説書別表の記載例で、他に少し気になったところをまとめておきます。

  • CRLDistributionPointsの記載例がCRLを参照しておらずHTMLへのURLになっています。*.crl のように正しい拡張子にするのが良いかと思います。
  • 組織代表者生年月日が「yyyy/mm/dd」となっているが、スラッシュ"/"はOpenSSLでのディレクトリ名表記と相性が悪いので無い方がよかったでしょう。
  • 記載例は、どこに何が記載されているのかバラバラで見辛く、ちゃんと証明書プロファイルの構造で記載するのが良かったかなと思います。一部、アルゴリズムやシリアルなどプロファイルのみに記載すべき情報も記載されており、混乱しやすいように思います。以下のようなプロファイルの基本構造を示すとわかりやすかったかと思います。
    フィールド/拡張名内容
    発行者名 電子委任状取扱サービス(=発行者)の英語名称
    有効期間 委任される期間
    主体者名 (部長さん等)受任者に関する主要な英語情報(氏名、所在地等)
    発行者別名 電子委任状取扱サービス(=発行者)の日本語名称
    主体者別名 ・(部長さん等)受任者に関する日本語の情報
    ・(社長さん等)委任者に関する日本語の情報
    ・(部長さんの権限範囲等)代理権の情報

なんか、長々と取り留めもない話を書いちゃってごめんなさいね。

最近の証明書の話題(2): CloudFlare DNS 1.1.1.1サイトのIPv6証明書

今日も、証明書ハンターネタの第二弾ということで、、、

4月1日に公開になったAPNICとCloudFlareが提供する、レスポンスが速くて、プライバシーに配慮した噂の1.1.1.1というパブリックDNSサービスが利用できるようになりました。DNSサーバーは、通信が暗号化されていても、どのIPからどのIPにアクセスしたかという記録が残るので、それをターゲティング広告などに使ったりするそうです。このDNSサービスは、プライバシーに配慮してログの保存期間を1週間とし、広告などに使われないようにしているそうです。

こんな記事見ちゃうと通信全体で早くなるのかどうかはよくわからないですね。で、このサービスの公式紹介サイトhttps://1.1.1.1/なんですが、FQDNでなく、IPアドレスで発行しているわけです。何やらおもしろそうじゃないですか。早速、証明書をダウンロードしてみて、内容を見てみましょう。

$ openssl x509 -in ip1.1.1.1.cer -noout -text Certificate: Data: Version: 3 (0x2) Serial Number: 05:6c:de:b4:14:65:ff:27:07:16:c0:6e:91:16:2e:19 Signature Algorithm: <font color=“orange”>ecdsa-with-SHA256</font> Issuer: C=US, O=DigiCert Inc, CN=DigiCert ECC Secure Server CA Validity Not Before: Mar 30 00:00:00 2018 GMT Not After : Mar 25 12:00:00 2020 GMT Subject: C=US, ST=CA, L=San Francisco, O=Cloudflare, Inc., CN=*.cloudflare-dns.com Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:b2:45:0b:31:ac:50:63:ce:21:e6:7c:34:23:1a: c5:c1:53:45:96:97:7a:31:87:bb:e0:ea:1d:95:f5: ff:25:04:ca:75:f0:f6:3f:b5:df:51:e9:5b:c9:3d: ad:b4:03:05:73:20:92:3e:74:be:8e:4b:1b:e2:68: 86:44:6e:62:bb ASN1 OID: prime256v1 NIST CURVE: P-256 X509v3 extensions: X509v3 Authority Key Identifier: keyid:A3:9D:E6:1F:F9:DA:39:4F:C0:6E:E8:91:CB:95:A5:DA:31:E2:0A:9F X509v3 Subject Key Identifier: DF:97:4D:E5:43:B3:B0:41:A7:42:F2:90:CF:89:7F:AE:12:57:84:E1 X509v3 Subject Alternative Name: DNS:*.cloudflare-dns.com, IP Address:1.1.1.1, IP Address:1.0.0.1, DNS:cloudflare-dns.com, IP Address:2606:4700:4700:0:0:0:0:1111, IP Address:2606:4700:4700:0:0:0:0:1001 X509v3 Key Usage: critical Digital Signature X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication X509v3 CRL Distribution Points: Full Name: URI:http://crl3.digicert.com/ssca-ecc-g1.crl Full Name: URI:http://crl4.digicert.com/ssca-ecc-g1.crl X509v3 Certificate Policies: Policy: 2.16.840.1.114412.1.1 CPS: https://www.digicert.com/CPS Policy: 2.23.140.1.2.2 Authority Information Access: OCSP - URI:http://ocsp.digicert.com CA Issuers - URI:http://cacerts.digicert.com/ DigiCertECCSecureServerCA.crt X509v3 Basic Constraints: critical CA:FALSE Signature Algorithm: ecdsa-with-SHA256 30:65:02:31:00:8e:8c:b2:d8:e8:21:d6:2d:7f:2a:1f:7e:a6: c3:1c:d4:e0:a1:95:02:2f:40:5e:80:92:88:d9:4b:cc:a5:89: aa:fa:9b:ca:b9:9e:a0:b7:a9:ed:21:1d:1d:1f:13:1c:0b:02: 30:2e:79:64:67:1d:7e:10:27:d9:68:a8:c8:6c:3e:4d:cd:07: 40:ac:d2:64:ad:b0:d0:cd:1b:af:c3:a4:26:30:ed:79:a3:a0: 6d:f2:d4:b4:bb:66:46:59:9a:a3:67:d9:0f
この証明書の特徴はこんなとこ:
  • DigiCertが発行している
  • 楕円曲線(ECC)の公開鍵証明書
  • 主体者別名(subjectAltName)にIPv4アドレスとIPv6アドレスが記載されている
いや〜〜〜、すごいですね。証明書ハンターなのでいろいろ証明書を探して見てますけど、IPv6アドレス向けのプライベートじゃない証明書を初めて見ましたよ。これは、早速コレクション対象ですよっ!!!

先日、データ通信協会のセミナーで総務省の方の講演を拝聴したんですが、 「iPhoneとかスマホのおかげでIPv6って本当に普及しちゃった。」と仰っていました。 ホント、その通りなんですねぇ。日本からGoogleへのアクセスは17%がIPv6なんだそうです。 Apple iOSでは、IPv4だと(わざと?)遅延させる仕組みが入るそうで、今後、IPv6への移行が加速されるだろうとの事でした。

実は、趣味で作ったjsrsasignというJavaScript実装の暗号/PKI関連ライブラリを公開しているんですが、よく考えてみたらIPv6対応してなかったんですよ。こりゃマズイなぁ、、、と。早速、対応させてみました。

最後のサンプルはいろんな証明書を簡単に作れるので、遊んでやってください。 そういう意味ではOpenSSLの証明書の表示は
IP Address:2606:4700:4700:0:0:0:0:1001
のような感じでRFC 5952で正規化されているわけではない、一意じゃない表記のやつなんですねぇ。正規化したらこうなりますよね。
IP Address:2606:4700:4700::1001
RFC 5952なんて知らなかったんですが、JPNICさんの「RFC5952-IPv6アドレスの推奨表記 IPv6アドレス表記の柔軟性が起こす問題とRFC5952の解説」を見て勉強させてもらいました。ありがたや。ありがたや。

てなわけで、今日もナイスな証明書をゲットだぜ。今日はこの辺で、、、

最近の証明書の話題(1) 韓国政府PKIのマズいワイルドカード証明書発行

どうも、証明書ハンターです。最近、個人的におもしろい証明書の話題がポンポン出てきたので、何回かに分けてご紹介したいと思います。

山賀さんのFacebookのフィードを見ていたら、 韓国政府PKIでまずい証明書を発行したというニュース(Google翻訳で読んでくださいw)を教えていただきまして、ハンターとしてはゲットしてコレクションに加えておきたいところ。

その問題というのは、韓国政府PKIが慶尚南道教育庁に不適切なワイルドカードSSLサーバー証明書を発行してしまったというもの。 慶尚南道は韓国の南東、釜山のすぐ北にあるのだそうです。

韓国のサイトは日本と同じでセカンドレベルを組織種別とする属性型ドメイン名を採用していて、政府系ドメインは「go.kr」のようになっていますが、以下のドメインに対してワイルドカードSSLサーバー証明書を発行してしまいました。

  • *.hs.kr - 高校
  • *.ms.kr - 中学校
  • *.es.kr - 小学校
  • *.kg.kr - 幼稚園
  • *.sc.kr - その他の学校
  • *.or.kr - 非営利団体
すると、この証明書と秘密鍵があれば、韓国の任意の学校のフィッシングサイトを作ったり、暗号通信の盗聴や改ざんができてしまう可能性があり、韓国政府認証基盤(GPKI)の信頼が揺らいでしまったとニュースでは指摘しています。一体、どんなドメイン確認処理(validation)をしてたんですかねぇ?

Google先生に聞いてみてもすぐはそのマズイ証明書が見つかりませんでしたが、Certificate Transparencyのログを見てみたら。ココにありました。(CTありがと〜〜〜〜、昔非難しててごめんよ〜〜〜(泣))

subjectAltNameを見てみると

X509v3 Subject Alternative Name: DNS:www.haeseong.kr DNS:haeseong.kr DNS:www.gandhischool.net DNS:gandhischool.net DNS:www.milgo.org DNS:milgo.org DNS:*.go.kr DNS:*.co.kr DNS:*.sc.kr DNS:*.or.kr DNS:*.kg.kr DNS:*.hs.kr DNS:*.ms.kr DNS:*.es.kr DNS:*.gne.go.kr DNS:support.gne.go.kr
一部の特定の高校まで入ってるのもどうかと思いますが、 バッチリワイルドカード入っちゃってますねぇ、、、って、あれれ??? 「*.go.kr」の政府向けドメインや「*.co.kr」企業向け のワイルドが入っちゃってるじゃないですか??? ニュースにある証明書のキャプチャと違うぞ!!! 学校サイトなんかど〜〜でもよくて、それより、 全韓国政府系ドメイン向けや、全韓国企業向けのワイルドの方が、 特大の問題で、盗聴なんかされたらマズイんじゃないですかねぇ。 そのあたりは報道が忖度したんですかねぇ、、、

ただ、このSSLサーバー証明書は、ルートが韓国政府のルートCAで、ChromeでもFirefoxでも信頼されたルートに入っていないから、韓国の人以外が被害に合うことは、ほとんど無いんじゃないかと思います。

で、この証明書がちゃんと失効されているか知りたかったんですが、CRLDPが

URI:ldap://ldap.epki.go.kr:389/cn=crl1p1dp14256,ou=CRL,ou=GPKI,o=Government of Korea,c=kr?certificateRevocationList;binary
LDAP URIになっていて、このLDAPサーバーがどうも匿名アクセスができず、普通にはCRLを取得できなそうにないんです。ChromeもFirefoxもIEもLDAP URIによる失効検証は(IEとADサーバーの組み合わせ以外は?)サポートしていないので、CRL失効検証はできず、OCSPもないようなので、どうやってブラウザで失効検証すりゃいんですかね?韓国のPKIに詳しいお友達がいる方は、教えていただけると嬉しいです。

というわけで、韓国GPKIのマズイ証明書発行のニュースを紹介し、私は無事、おもしろい証明書「ゲットだぜ!」

今日はこの辺で、、、あと二本ぐらい、近日中に書きたいと思ってます。

追記(2018.04.11)

他の韓国GPKI発行の証明書を見ていたら、HTTPからCRLを取れるようになっているようで、LDAP URIの情報から当該のCRLを取得することができました。で、中身を見てみたところ、このマズイ証明書も含め、現時点で一枚も失効させている証明書はありませんでしたので、一応ご報告。

追記(2018.04.14)

ちょっと探しものをしていたところ見つけた、韓国GPKIが発行している

Subject DN: CN=e-csinfo.*.go.kr
SAN DNS: e-csinfo.*.go.kr
このワイルドカード証明書もとても怪しい。 管理主体が全くわからず、全省庁の e-csinfo.*.go.kr サイトを保護しているって、 これ何だ???具体的なサイトは jbe.go.krsen.go.kr などがあるようで、共通管理はされているっぽいんだけど。

(小ネタ) Chrome 60で証明書を表示させるフラグ設定

Chrome 56からGoogleの「素人はすっこんでろ」UI/UXポリシーによりHTTPSで接続した際に使用しているSSLサーバー証明書の表示が鍵アイコンから簡単にできなくなってしまいました。証明書大好きっ子にはなんとも辛い仕打ちでした。開発ツールからは証明書が表示できるので、メニューを辿って操作するか、ショートカットキーを素振り100回していた方も多いのではと思います。

Windows: Ctrl + Shift + I or F12
Mac: ⌘ + Opt + I

今日は、やっとChrome 60からフラグ設定で証明書が簡単に表示できるようになったので、今日はその設定について紹介します。

何も設定していないと、HTTPSサイトを見ている際の、鍵アイコンをクリックして見られるメニューはこんな感じ。
before
そこで、アドレスバーで以下のように入力します。

chrome://flags/#show-cert-link
すると、このようなフラグ設定が表示されます。
flag
「有効にする」をクリックし、指示に従ってブラウザを再起動します。すると、HTTPSサイトを表示した場合このように
after
「証明書、有効」というリンクが表示されるようになり、クリックすると証明書が表示されるようになります。いや〜〜、よかった、よかった。
52

最新記事
Categories
Archives
記事Google検索

本ブログ内をGoogle検索
Twitter
Yahoo!アクセス解析
Travel Advisor
QRコード
QRコード

  • ライブドアブログ