━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
__
/Ｐ▲ ◆ JPNIC News & Views vol.1615【臨時号】2018.8.24 ◆
_/ＮＩＣ
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
---------- PR --------------------------------------------------------
□■□ データドックの「新潟・長岡データセンター」 ■□■━━┓
GPUサーバー、AIインフラを支えるデータセンター！
供給電力 = 最大30kVA/ラック
ラックサイズ = 800mm * 1200mm * 2200
┗━━━━━━━━━━━━ https://www.datadock.co.jp/
----------------------------------------------------------------------
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ News & Views vol.1615 です
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2018年7月中旬にカナダ・モントリオールで開催された第102回IETFミーティ
ングのレポートを、前号より連載にてお届けしています。
連載第2弾となる本号では、セキュリティエリアの中から特に、認証局からの
証明書発行ログを公開することで不正な証明書の発行を検出する技術である、
CT (Certificate Transparency)に関する議論の動向をご紹介します。CTをIoT
機器にも利用する場合、そのままだと数が膨大になり過ぎることから、どの
ように扱うべきなのかが議論の焦点になっています。
次号以降では、IoT機器のソフトウェア更新に関する議論や、IPv6関連の動向
についてご紹介する予定です。昨日発行した全体会議の報告については、下
記のURLからバックナンバーをご覧ください。
□第102回IETF報告
○[第1弾] 全体会議報告 (vol.1614)
https://www.nic.ad.jp/ja/mailmagazine/backnumber/2018/vol1614.html
また、本モントリオール会合のオンサイトでの報告会を、来週8月31日(金)に
東京・青山学院大学にて開催いたしますので、こちらもぜひご参加ください。
IETF報告会(102ndモントリオール)開催のご案内
https://www.nic.ad.jp/ja/topics/2018/20180803-01.html
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ 第102回IETF報告 [第2弾] セキュリティエリア関連報告
～TRANS WGにおけるCTに関する議論について～
セコム株式会社 IS研究所 伊藤忠彦
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
本稿では、セキュリティエリア関連報告と題し、TRANS WGにおけるCTに関す
る議論の最新状況をご紹介します。
■ TRANS WGとは
IETF TRANS (Public Notary Transparency) WGは、2014年に設立された、CT
(Certificate Transparency)に関する検討を行うWGです。CTとは、認証局が
証明書を発行した際のログを、公開のログサーバに登録することで、証明書
発行の透明性を確保する仕組みです。
■ CT技術誕生の背景
CT技術登場の背景としては、認証局から不正に証明書が発行されるインシデ
ントが相次いだことが挙げられます。2011年頃から、認証局に対する不正ア
クセスや運用上のミスによって、本来発行してはならない証明書が不正に発
行されるという事件が相次ぎました。そして、その中にはGoogleやYouTubeな
ど、メジャーサイトに対する証明書も含まれていたことが発覚しました。Web
ブラウザはWebサイトの証明書を検証し、サイト利用者はその証明書の情報(記
載事項)に基づいてWebサイトの運営者を確認します。そのため、証明書の不
正発行は、フィッシングなどの悪用につながりやすくなります。このような
事件を受けて、認証局の証明書発行という行為は、高いリスクと影響力を潜
在的に持つという認識が広がりました。
証明書の不正発行がもたらすインシデントに対応するべく、2013年にGoogle
社がCTという概念を提唱しました。Transparencyという言葉にあるように、
CTは証明書発行の透明性を確保する仕組みです。CTは2013年に、RFC6962(*1)
として仕様が定められました。
(*1) https://tools.ietf.org/html/rfc6962
■ CTの仕組み
CTでは、認証局が証明書発行を行う際に、公開されているCTログサーバに対
して、証明書発行の記録を登録します。ドメイン名の登録者はCTログサーバ
を監視することで、自身の持つドメイン名に対する証明書を、不正に発行し
ている認証局が存在するか否かを確認することができます。また、一部のWeb
ブラウザでは、証明書検証の際にCTログサーバにログ(CTログ)が存在するか
を確認し、存在しない場合は警告を行います。
CTを利用して証明書発行プロセスを透明化することにより、認証局の不適切
な証明書発行が行われた場合、それを確認することができます。しかし、認
証局が発行するすべての証明書がCTログサーバに登録されるため、公開する
ことを前提とせずに利用されていたサーバ証明書等も、公開されてしまうと
いう問題点もあります。
■ IETF 102 TRANS WGにおける議論
IETF 101では、TRANS WGは開催されなかったため、今回のWGは8ヶ月ぶりのWG
となりました。その期間において、Certificate Transparency Version 2.0
(CT V.2)(*2)に関するドキュメントの整備は、メーリングリストにて大きく
進みました。今回、WGにおける議論は、CT V.2策定後に、CT V.2を実装・運
用する時期や、その運用で得た知見をいかにIETFへ還元するか、といったも
のでした。IETF 102のTRANS WGでは、あまり多くの議論は行われませんでし
たが、以降、それらの動向の裏で、私が行っていた活動を紹介いたします。
(*2) https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/
■ CT適用の例外規定に関する議論の行方
IETF 100(2017年11月)以前は、Google社はChromeブラウザにおいて、署名検
証を行う際にPublic Root認証局から発行されるすべてのサーバ証明書につい
て、CTログサーバに記録されているログを確認する方針でした。CTログをWeb
ブラウザがどのように扱うのかに関しては、Webブラウザでトップシェアを占
める、Chromeの提供元であるGoogle社の意向に大きく左右されます。また、
何社かの認証局が、特定の企業内ネットワークにおけるCT適用除外や一部ロ
グ情報の部分的削減を要望しましたが、それらの要望をGoogle社は受け入れ
ない見通しでした。
その経緯から判断する限りにおいては、Google社はCTログ登録に例外を認め
ず、あらゆるサーバ証明書に対して適用すべきと考えているように見受けら
れました。しかし、それらの判断は一般的なWebサイト向け証明の発行を前提
とした判断であり、IoT向けの証明書発行を考慮した判断ではありませんでし
た。
そこで私は、IETF 100にて、大量のIoT機器向け証明書がCTログサーバに登録
された場合、CTログサーバのスケーラビリティという点で問題が発生し得る
点を指摘し、その問題解決策を提案しました。これは、Google社が管理する
Webブラウザの仕様で解決を行うのでなく、IETFの規定するログサーバの仕様
で解決を図るものでした(*3)。
(*3) https://www.nic.ad.jp/ja/mailmagazine/backnumber/2017/vol1557.html
その後、CA/Browser Forum(*4)に参加する何社かも交え議論を行い、紆余曲
折の末、Google社もCT適用除外規定の有用性を認めました。そして、Google
社は、適用除外機能はCTログサーバ機能でなく、Webブラウザの機能で実装す
ることが適切であると判断しました。その後Google社は、2018年6月にChrome
ブラウザの機能として、CT適用除外機能を設けたことを発表しました。この
機能は、すべてのIoT機器に発行される証明書に対して適用することはできな
いものの、CTログサーバに無用なスケーラビリティが求められないこととな
りました。そして、当該機能はログサーバで解決しなくても良いものとなり、
CT V.2には盛り込まないこととなりました。
(*4) インターネット用語1分解説「CA/Browser Forumとは」
https://www.nic.ad.jp/ja/basics/terms/ca_browser_forum.html
■ おわりに
これまでの活動により、CTの適用除外規定を通し、IoT機器へ証明書を発行す
る上での、課題の一部を解決することができました。今回制定された除外規
定は、どのようなIoT機器にも適用可能というわけではありませんが、悪用さ
れるリスク等を考慮すると、現状において妥当なものであると考えています。
今後、CT V.2策定後に、運用結果等も踏まえ、実社会への影響度合い等を加
味し、より多くのIoT機器で証明書が利用可能な仕組み作りに取り組みたいと
考えています。
なお、筆者の今回の活動(の一部)は、一般社団法人情報通信技術委員会によ
る助成を受けて行ったものです。助成の目的と主な内容については、公募に
関するWebページ(*5)をご覧ください。
(*5) 平成30年度「IoT/BD/AI時代に向けたデジュール及びフォーラム標準に
関する標準化動向調査」調査者の募集
http://www.ttc.or.jp/j/info/topics/20180410/
～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
まわりの方にもぜひNews & Viewsをオススメください！
転送にあたっての注意や新規登録については文末をご覧ください。
◇ ◇ ◇
わからない用語については、【JPNIC用語集】をご参照ください。
https://www.nic.ad.jp/ja/tech/glossary.html
～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ ◆◇◆◇◆ 本号のご感想をお聞かせください ◆◇◆◇◆ ┃
┃良かった ┃
┃ http://feedback.nic.ad.jp/1615/130815ae3073746b34764ef52d960e41 ┃
┃ ┃
┃悪かった ┃
┃ http://feedback.nic.ad.jp/1615/60c1f4d0039cd6c4b151ed101105ba82 ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
■■■■■ JPNICの活動はJPNIC会員によって支えられています ■■■■■
::::: 会員リスト ::::: https://www.nic.ad.jp/ja/member/list/
:::: 会員専用サイト :::: https://www.nic.ad.jp/member/ (PASSWORD有)
□┓ ━━━ N e w s & V i e w s への会員広告無料掲載実施中 ━━━┏□
┗┛ お問い合わせは jpnic-news@nic.ad.jp まで ┗┛
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
JPNIC News & Views vol.1615 【臨時号】
＠ 発行 一般社団法人 日本ネットワークインフォメーションセンター
101-0047 東京都千代田区内神田3-6-2 アーバンネット神田ビル4F
＠ 問い合わせ先 jpnic-news@nic.ad.jp
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
本メールを転載・複製・再配布・引用される際には
https://www.nic.ad.jp/ja/copyright.html をご確認ください
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
◇ JPNIC Webにも掲載していますので、情報共有にご活用ください ◇
登録・削除・変更 https://www.nic.ad.jp/ja/mailmagazine/
バックナンバー https://www.nic.ad.jp/ja/mailmagazine/backnumber/
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
■■■■■ News & ViewsはRSS経由でも配信しています！ ■■■■■
::::: https://www.nic.ad.jp/ja/mailmagazine/backnumber/index.xml :::::
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
■■◆ ＠ Japan Network Information Center
■■◆ ＠ https://www.nic.ad.jp/
■■
Copyright(C), 2018 Japan Network Information Center
JPNICはインターネットの円滑な運営を支えるための組織です
- JPNIC
-
IPアドレス・AS番号
指定事業者向け各種申請手続/お知らせ
一般ユーザーの方
- JPNIC会員
