━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
    __
    /Ｐ▲        ◆ JPNIC News & Views vol.1650【臨時号】2018.12.19 ◆
  _/ＮＩＣ
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ News & Views vol.1650 です
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2018年11月上旬にタイ・バンコクで開催された第103回IETFミーティングのレ
ポートを、vol.1644より連載にてお届けしています。

連載第5弾となる本号では、サーバ証明書の発行や管理の自動化に関して検討
を行っている、ACME WGでの議論の動向をご紹介します。

連載の最終回となる第6弾では、DNS関連の動向をお届けする予定です。なお、
これまでに発行した第103回IETFの報告については、下記のURLからバックナ
ンバーをご覧ください。

  □第103回IETF報告

    ○[第1弾] 全体会議報告 (vol.1644)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2018/vol1644.html

    ○[第2弾] SUITとIETF Hackathon ～IoT機器の安全なファームウェア更
              新から～全体会議報告 (vol.1645)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2018/vol1645.html

    ○[第3弾] セキュリティエリア関連報告 ～オペレーション関連技術の動向
              CACAO/SMART～ (vol.1646)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2018/vol1646.html

    ○[第4弾] トランスポートエリア関連報告 ～HTTP over QUICからHTTP/3
              への改称～ (vol.1647)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2018/vol1647.html

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ 第103回IETF報告 [第5弾]  ACME WG関連報告
                            ～Let's Encrypt周辺の標準化動向～
                                               株式会社東芝 安次富大介
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2018年11月にタイ・バンコクにて開催されたIETF 103で、筆者が参加したACME
WG関連のトピックについてご紹介します。ACMEについてご存じない方でも雰
囲気をつかんでいただけるように、そもそもACMEとは？といった基本情報・
背景情報に紙幅を割いています。


■ ACMEとは

ACME (Automated Certificate Management Environment) WG(*1)は、SSL/TLS
サーバ証明書の発行・管理手続きを自動化するプロトコルを検討しているWG
です。ここで策定されているACMEプロトコル(*2)は、まだRFC化には至ってい
ないものの、SSL/TLS証明書の自動発行サービス「Let's Encrypt」(*3)で既
に使われており、Web PKIを支える重要なプロトコルになっています。

(*1) ACME (Automated Certificate Management Environment) WG
     https://datatracker.ietf.org/wg/acme/about/

(*2) Automatic Certificate Management Environment (ACME)
     https://tools.ietf.org/html/draft-ietf-acme-acme-16

(*3) https://letsencrypt.org/

最新動向の話に移る前に、ACMEプロトコルの概要と拡張仕様について、簡単
に紹介しておきます。

〇ACMEプロトコルの概要

まず、ACMEが発行する証明書は、DV (Domain Validation)証明書です。当該
ドメイン名の検証を含む発行・更新手続き、そして失効手続きを自動化する
プロトコルがACMEです。

ACMEプロトコルのインターネットドラフト(I-D)では、HTTPベースのRESTful
APIセットが規定されているのですが、特徴的なアイデアはドメイン名検証処
理にあります。まず、ACMEクライアント(Webサイトなど)がSSL/TLS証明書の
発行を要求すると、ACMEサーバ(認証局)は、「チャレンジ」と呼ばれる、ド
メイン名所有を証明する手続きの実行をACMEクライアントに課します。チャ
レンジとしては、HTTPサーバ上の特定のパスにACMEサーバが提供するトーク
ンを設置する(http-01)、DNSのTXTレコードに同様にトークンを設置する
(dns-01)、という二つの具体的な方法が定義されています。ACMEサーバは、
このチャレンジが達成されたことを確認した上で、証明書を発行します。

なお、このI-Dが初めてIESG (Internet Engineering Steering Group)のレ
ビューにかけられた-07 (2017年6月)の段階では、他にも二つのチャレンジ方
法が定義されていました。一つは、ACMEサーバが提供するチャレンジ情報に
確認用URL (href)を持たせて、ユーザーによる承認ステップを噛ませられる
ようにするOut-of-Bandチャレンジ(oob-01)。もう一つは、TLSのSNI (Server
Name Indicator)拡張を利用し、トークンのダイジェストを含む一時的なドメ
イン名と対応する自己署名証明書を設置するTLS-SNIチャレンジ(tls-sni-02)
です。しかしながら、前者は主要なACME実装でサポートされていないという
理由で削除されました。後者は、同じIPアドレスで複数のドメインをホスト
しているホスティングサービス上で、SNIが有効な場合に、IPアドレスを共有
している別ドメイン名の証明書を取得できてしまうという脆弱性が発見され
(2018年1月)、削除されました。当時、Let's Encryptは、TLS-SNIチャレンジ
を急きょ無効化するなどの対応に追われ、話題になりました。

〇ACMEプロトコルの拡張仕様

ACMEプロトコルのI-Dは、Web PKI上のドメイン名での証明書発行に焦点を当
てたものになっています。具体的には、クライアントが送信する証明書発行
要求メッセージの属性として、Web PKI上のドメイン名向けであることを表す
"identifier": {"type":"dns"}のみが規定されています。IPアドレスや電話
番号など別のID向け証明書発行方法や、新たなチャレンジ方法は、ACMEの拡
張仕様として別文書で規定することになっています。

IETF 103開催時点で、既にIESGに送られている拡張仕様がいくつかあります。
IPアドレス向け拡張("type":"ip")(*4)、上記tls-sni-02の後継とも言えるTLS
ベースの新たなチャレンジ拡張(tls-alpn-01)(*5)、そして、DNSのCAA
(Certification Authority Authorization)レコードに、認証局(CA)における
アカウント情報や対応するチャレンジ情報を加える拡張(*6)の3本です。
tls-alpn-01は既にLet's Encryptでサポートされています。

(*4) ACME IP Identifier Validation Extension
     https://tools.ietf.org/html/draft-ietf-acme-ip-04

(*5) ACME TLS ALPN Challenge Extension
     https://tools.ietf.org/html/draft-ietf-acme-tls-alpn-05

(*6) CAA Record Extensions for Account URI and ACME Method Binding
     https://tools.ietf.org/html/draft-ietf-acme-caa-05


■ IETF 103での動向

IETF 103におけるACME WGと、ACMEに関連するセキュリティ問題が扱われた
Security Dispatch WGのトピックについて、これまでの経緯も交えながら紹
介します。

〇ACMEプロトコルI-Dの状況

前回IETF後のIESGレビューの結果、-14から-15への改訂(2018年9月)におい
て、証明書発行要求から発行に至る複数のステップ(API呼び出し)で利用され
る無認証GETが、「POST-as-GET」に変更されるという、後方互換性の無い破
壊的な変更が加えられました。POST-as-GETとは、リソース取得用途で用い
る、認証用のJWS (JSON Web Signature)オブジェクトをボディに入れたPOST
リクエストを指します。クライアントに紐づかない一部のAPIを除き、クライ
アント認証を必須とする方向に倒したと言えます。

今回のIETFでは、ミーティングの冒頭で、ACMEプロトコルの現行I-Dが、2018
年11月2日にIESGにて承認された旨が報告されました。まだエディトリアルな
修正がいくつか残っているようですが、上記のような大幅な変更はもう発生
しないと言ってよい状況になったようです。

しかしながら、本原稿の執筆時点(2018年12月12日)でI-DのIssuesを見ると
(*7)、http-01チャレンジに、サーバ実装次第でクロスサイトスクリプティン
グ(XSS)脆弱性があることが指摘されています。MIMEタイプを自動判定してし
まうApacheモジュールや、Firefox等、一部のWebブラウザ実装の問題による
もののようですが、チャレンジのレスポンスにMIMEタイプを明記する等、何
らかの仕様修正が必要かもしれず、すんなりRFC化に至るかは微妙な状況で
す。

(*7) Make the HTTP Challenge require a response MIME type
     https://github.com/ietf-wg-acme/acme/issues/470

〇STAR証明書と権限委譲

STAR (Short-Term, Automatically-Renewed)証明書(*8)とは、その名の通り
有効期間が短く(例えば1～3日)かつ自動更新される証明書のことです。従来
の証明書における失効処理の信頼性や、ACMEでの短周期な証明書発行の効率
性に係わる問題を解消する枠組みとして、2016年10月にACME WGに提案され、
検討が進められています。方法はシンプルで、1回の証明書発行要求で、ACME
サーバ上でSTAR証明書が定期的に自動生成されるようにするものです。失効
に相当する手続きとして、証明書の新規発行を止めるキャンセル手続きが定
義されています。

前回IETF後にWGLCがかかりましたが、今回のIETFでは、前述したコア仕様の
変更(POST-as-GETの導入)を受けて、POST-as-GETでの証明書取得では効率が
悪いので、従来の無認証GETを指定できるオプションを追加したこと等が報告
されました。特に反対は無く、再度のWGLCがかかることになりました。

(*8) Support for Short-Term, Automatically-Renewed (STAR) Certificates
     in ACME
     https://datatracker.ietf.org/doc/draft-ietf-acme-star/

STARに関連する仕様として、ACME STAR Delegation(*9)があります。これは、
ID(ドメイン名など)所有者が、IDの証明書を取得する権限を、サードパー
ティーに委譲する仕組みを規定したもので、前回IETFでのSecurity Dispatch
WGでの議論の結果、ACME WGにて標準化を進めることで合意がなされました。
主要なユースケースとしては、TLSを終端するCDN (Content Delivery
Network)が、コンテンツプロバイダの代わりに証明書を取得・更新する、と
いうものが想定されています。

具体的な方法は、ID所有者(ACMEクライアント、コンテンツプロバイダ)が、
権限委譲対象のNDC (Name Delegation Consumer、CDN事業者)に対してACME
サーバとしてふるまう(つまり、NDCと認証局の間でACMEプロキシとしてふる
まう)というものです。NDCとID所有者の間ではID検証は行わず、ID所有者と
認証局間で、チャレンジを含む通常のACMEフローが実行されます。この仕組
みはSTAR証明書向けに考案されたものですが、今回のIETFでは、通常の
Long-Termな証明書にも適用できるか否かが議論されました。賛否両論で結論
は出ませんでしたが、WGドキュメントとして採用されることは決定しました。

(*9) An ACME Profile for Generating Delegated STAR Certificates
     https://tools.ietf.org/html/draft-ietf-acme-star-delegation-00

〇Web PKI以外のID向け拡張

今回のIETFでは、Web PKI以外のID向けのACME拡張として、TLS emailサービ
ス用およびS/MIME用の拡張、VoIPサービス用の拡張が議論されました(*10)
(*11)(*12)(*13)。いずれもWGドキュメントとして既に採用されており、今回
は、マイナーな改訂に関する報告が主なものでした。以下にI-Dを一覧してお
きます。

(*10) Extensions to ACME for email TLS
      https://tools.ietf.org/html/draft-ietf-acme-email-tls-05

(*11) Extensions to ACME for end user S/MIME certificates
      https://tools.ietf.org/html/draft-ietf-acme-email-smime-04

(*12) ACME Challenges Using an Authority Token
      https://tools.ietf.org/html/draft-ietf-acme-authority-token-01

(*13) TNAuthList profile of ACME Authority Token
      https://tools.ietf.org/html/draft-ietf-acme-authority-token-tnauthlist-01

〇Security Dispatch WG

ACME WG以外の動向として、今回のSecurity Dispatch WGで、"ACME Security
Considerations"という発表がありました。実は、前回IETFのACME WGで発表
された内容のアップデート版だったのですが、プロトコル自体の話ではなく
運用寄りの話題であるため、このWGにて一旦議論されることになったようで
す。

内容は、例えば、古いDNSレコードが指すIPアドレスを攻撃者が取得できる場
合に、そのドメイン名の証明書を取得できてしまう問題(ip-use-after-free
攻撃)などを取り上げ、その運用上の対策(TLSAレコードを使う等)を例示する
ものでした。中でもip-use-after-freeは、クラウドサービス利用が一般的に
なった昨今顕在化している問題で、例えばAWS EC2(Amazonクラウドの仮想マ
シン)由来のものだけで、70万以上の古いレコードが発見されたとのことでし
た。会場からは、やはりACMEプロトコルによらない運用上の問題を扱ってい
るため、AD Sponsored Draftにする方向でブラッシュアップするのがよいと
いう意見が出て、その方向で進められることになりました。今後、プロトコ
ルとして対策が落とせる話に発展するのであれば、再びACME WGで扱われるこ
とになるかもしれません。

(*14) Extended Security Considerations for the ACME
      https://tools.ietf.org/html/draft-fiebig-acme-esecacme-00


■ おわりに

ACME周辺の最新動向を、これまでの経緯も踏まえて駆け足ではありますが紹
介させていただきました。拙稿がACMEに対する理解・キャッチアップの一助
になれば幸いです。

ちなみにLet's Encryptのルート認証局の一つであるIdenTrust社は、今や証
明書発行のトップシェアを誇っており、Q-Successの観測によれば、そのシェ
アは今も伸び続けているようです(*15)。Let's Encrypt/ACMEが、WebのHTTPS
化の加速に大きく貢献している表れの一つと言えるでしょう。

(*15) Historical trends in the usage of SSL certificate authorities
      for websites
      https://w3techs.com/technologies/history_overview/ssl_certificate/all

余談ながら、筆者もLet's Encrypt利用者の1人です。ただ、昨今では大手ク
ラウドベンダが、ロードバランサとともに証明書自動発行サービスを無料で
提供しているため、あえてLet's Encryptを選択する機会は減ってきていま
す。それでも、ロードバランサを使わない(使えない)ケースはありますし、
そのために今でもACMEクライアントを運用し、Let's Encrypt/ACMEの恩恵に
あずかっています。


     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
          まわりの方にもぜひNews & Viewsをオススメください！
      転送にあたっての注意や新規登録については文末をご覧ください。
                  ◇              ◇              ◇
       わからない用語については、【JPNIC用語集】をご参照ください。
             https://www.nic.ad.jp/ja/tech/glossary.html
     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃     ◆◇◆◇◆   本号のご感想をお聞かせください   ◆◇◆◇◆     ┃
┃良かった                                                          ┃
┃  http://feedback.nic.ad.jp/1650/ab6ee263b5812712d4d04f7da36304c6 ┃
┃                                                                  ┃
┃悪かった                                                          ┃
┃  http://feedback.nic.ad.jp/1650/e1efee7665adcae47d5d415d38176166 ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
■■■■■  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.1650 【臨時号】

 ＠ 発行  一般社団法人 日本ネットワークインフォメーションセンター
          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