自堕落な技術者の日記

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

最近の証明書の話題(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

GmailアカウントでS/MIME 署名/暗号メールを使う(その1 iOS標準メーラー編)

とある匿名の紳士がご厚意で、JCANのS/MIME証明書をわたしのGmailのアドレスに発行してくださり、iOSの標準メーラーのGmailアカウントからS/MIME署名/暗号メールが送れるようになりました。 docomoアカウントのメールはS/MIME使えないので渡りに船でした。(匿名の淑女からいただいていたS/MIME証明書はとっくに期限切れになり困っていました。)

「ブログに書いて下さいよ〜〜〜」とその紳士に言われていたので、ちょっと書いてみたいと思います。

ここに書いてあるのは、JCAN証明書に限った話ではないので、iOS標準メーラーの任意のアカウント向けの証明書で使える話です。現時点で最新のiOS 10.3.2で試しました。

,泙困麓分のS/MIME証明書のインストール

発行された証明書と秘密鍵のファイルである「*.p12」や「*.pfx」を添付ファイルにしてiOS標準メーラーのアカウントに送り、添付ファイルを開きます。
IMG_2600m
表示されている「インストール」のリンクをクリックし、iOSのロック解除パスコードを入力し、続いて *.p12 または *.pfx ファイルのパスワードを入力すれば証明書がインストールされます。
IMG_2601m

⊆,GmailアカウントへのS/MIME証明書の設定

次に、iOSの標準メーラーからGmailのアカウントでS/MIME署名メールを送れるように、証明書(と鍵)の設定をします。「設定>メール>アカウント>Gmail>アカウント>詳細」の一番下の方にS/MIMEの設定があります。S/MIMEをオンにして「署名」を開き、
IMG_2602m
「署名」をオンにして証明書を選択します。JCANからの証明書は「BN-英語氏名」となっていると思います。
IMG_2603m
この時点では「デフォルトで暗号化」は「いいえ」のままがいいです。

iOS標準メーラーからS/MIME署名メールを送ってみる

iOS標準メーラーからGmailアカウントを選んで新規メールを送ってみましょう。
IMG_2604m
宛先が空欄の時には、錠前アイコンは「グレーで開いた」状態です。錠前が開いている状態は「相手に対して暗号化しませんよ」という意味です。また、グレーの錠前がある状態は「S/MIMEが利用可能」な状態にあるということです。次に、S/MIME署名メールを送りたい相手を選んでみましょう。
IMG_2606m
青い錠前が開いている状態は「メールの送信が可能で、相手にはS/MIME暗号化をしない」ということを意味しています。初期状態では相手の証明書をもらっていないので、暗号化できないのは当然です。ここで、無理やり「開いた青い錠前」をクリックしてみましょう。
IMG_2607m
相手の証明書を持っていないので、宛先が赤くなり「赤い錠前」のアイコンになり「暗号化できません」と表示されます。もう一度クリックして青に戻し、送信してみてください。

ちられてきた署名メールを受けてみる

iOSのメーラーから送られてきたメールをS/MIME対応のメーラー、例えばOutlookで見てみましょう。
zzz01m

ゥ僖愁灰鵐罅璽兇S/MIME署名メールから証明書を登録する

iPhoneから暗号メールまたは、署名暗号メールを送る場合には、iOSの標準メーラーのS/MIME関係の利用方法はいろいろイマイチな面が多いですが、署名メールに単純に返信する形では送れず、iPhoneでの相手証明書の事前登録が必要です。ここでは、その「相手の証明書」の登録方法を紹介します。

まず、送られてきた署名メールを開きます。
IMG_2606m
青い錠前をクリックしても、証明書が無いので赤くなるだけなので、もう一度タッチして青になるように戻します。
IMG_2607m
ちなみに、送られてきたメールが署名暗号メールだと、以下のようにバッジ(署名)と錠前(暗号化)の2つのアイコンつきます。
IMG_2609m
ちなみに、このメールをiPhoneの標準メーラーではなく、Gmailのウェブアプリで見てみると以下のようになっています。smime.p7mというファイルが添付されているだけで、暗号化されており、バイナリファイルを見ても内容はわからないでしょう。(そのうち、この中身のバイナリファイルの形式について述べることもあるかもしれません。) Googleにもメールの内容を知られることなく、安心ですね。
スクリーンショット 2017-06-09 22m
そこで、相手のアドレスをタッチすると、相手の連絡先が表示され、証明書に関する記述も書かれています。
IMG_2597m
「証明書を表示」のリンクをタッチすると、相手の証明書が表示されますので、「詳細」を表示などして、内容をざっと確認して「インストール」をタッチするとインストールされます。
IMG_2598m
IMG_2610m
以上で送信先の証明書を登録することができました。

iPhoneからS/MIME署名暗号メールを送る

先ほど証明書を登録した人に新規にメールを送ってみます。宛先にメールアドレスを入力すると、最初は青い錠前は開いている状態です。
IMG_2613m
青い錠前をクリックすると、無事「暗号化済み」と表示されています。あとは送信ボタンを押すだけです。
IMG_2614m
パソコンのOutlookで受け取ってみると無事、署名暗号化メールを見ることができます。
zzz07m

おわりに

以上、JCANのS/MIME証明書をいただいたので、iPhone標準メーラーのGmailアカウントに設定し、 署名暗号メールを送受信してみました。 すこし、登録などまどろっこしい所もあるんですが、AndroidではまともなS/MIMEメーラーは無いので、 iPhoneの標準メーラーはS/MIMEを「ちゃんと」使えて大したもんだなぁ、、、と思います。 今回の証明書はJCANさんのでしたが、英語の申請が気にならなければCOMODOからも 無料のS/MIME証明書を発行してもらえます。よかったらトライしてみてください。

これで、Googleはユーザーのメールの内容を監視していたりするんでしょうが、安心してムフフなメールのやり取りを他の人には決してみられることなく送れるわけです。いや〜〜、素晴らしいですね。

Gmailアカウント用のS/MIME証明書を欲しかったのは、実は GoogleのG-Suite Enterpriseではサーバーに秘密鍵と証明書を設定して クラウド型でS/MIMEの署名暗号メールが使えるそうで、それを使ってみたかったというのが あります。最近、インシデント対応に追われてなかなか時間が取れないんですが、 なんとか時間作って試したいなぁと思っています。 ではでは。

関連記事

最新記事
Categories
Archives
記事Google検索

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

  • ライブドアブログ