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

第118回IETFミーティングは、2023年11月上旬にチェコ・プラハで開催されま
した。先日発行したvol.2053から、この第118回IETFミーティングの話題を連
載にてお届けしています。第3弾となる本号では、ハイブリッド公開鍵暗号ス
キームであるHPKEと、その応用技術動向についてご紹介します。

本号の内容は、JPNICブログでもお読みいただけます。発表資料などへのリン
クも辿りやすくなっておりますので、ぜひブログでご覧ください。

  JPNICブログ：IETFアップデート - 第118回IETF [第3弾] 
  ハイブリッド公開鍵暗号スキーム HPKE とその応用技術動向
  https://blog.nic.ad.jp/2024/9476/

なお、これまでに発行した第118回IETF関連の記事については、下記のURLか
らバックナンバーをご覧ください。

  □第118回IETF報告
    ○[第1弾] 全体概要、BOF、tigress WG
      https://blog.nic.ad.jp/2024/9459/
    ○[第2弾] WLS/SML/MLS/sidrops WG、HotRFC
      https://blog.nic.ad.jp/2024/9462/

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ IETFアップデート - 第118回IETF [第3弾] ハイブリッド公開鍵暗号スキー
   ム HPKEとその応用技術動向
                                            合同会社bibital 安次富大介
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

チェコ・プラハで開催された第118回IETFミーティング(IETF 118)にて、私が
策定に関わっている仕様の議論に参加し、関連する技術動向を現地で調査し
てきました。少々ニッチな内容ですが、私の活動領域に絞って、IETF 118の
動向を紹介させていただきます。具体的には、HPKE (Hybrid Public Key 
Encryption)というハイブリッド公開鍵暗号スキームの応用領域に関する話題
が中心になります。現在、IETFのセキュリティエリアでは、このHPKEを応用
したEnd-to-End暗号技術・プライバシー保護技術がいろいろと議論されてお
り、その全体像と概要、最新動向をざっくり伝えられればと考えています。

本編に入る前にあらかじめ断っておきますと、動向紹介までの前置きが長く
なってしまいました。なぜ私が IETF の標準化の議論に関わっているのか、
どのような技術領域でどのような議論をしているのか、雰囲気だけでも掴ん
でいただこうと経緯も含めて書いてしまったからです。そこは論文でも調査
報告書でもないメールマガジンの記事ということでご容赦ください。


■ 標準化活動への関与に至る経緯

まずは経緯から。私は所属会社でコードを書かなくなった3年ほど前から、趣
味でオープンソース(OSS)活動を始めました。JWT (RFC7519: JSON Web Token)
(*1)というアクセストークンをご存じの方も多いと思いますが、このJWTの
データ表現形式であるJOSE (JSON Object Signing and Encryption)(*2)のメ
ジャーなOSSへの貢献から入りました。所属会社で使っていたのがきっかけで
す。そのうち自分でスクラッチから作りたくなり、題材にしたのが COSE 
(CBOR Object Signing and Encryption)(*3)でした。JOSEのバイナリ版とで
も言うべきもので、トークンのデータサイズを極力小さくしたいユースケー
スのためにIETFで策定された仕様(RFC9052(*4)など)でした。例えば、
COVID-19のワクチン接種証明書の欧州規格(EUDCC)が、QRコードにデータを詰
め込むためにCOSEを採用しています。このCOSEを実装する中で、RFCへの疑問
点をCOSE WGのメーリングリストに投稿したのが標準化活動への関与の始まり
でした。その後も、標準準拠の暗号ライブラリをいくつか作ったのですが、
その中で、COSEの公開鍵暗号方式を使った機能への不満から興味を持って実
装したのが HPKE (RFC9180: Hybrid Public Key Encryption)(*5)です。同時
期、COSE WGで"Use of HPKE with COSE (COSE-HPKE)"(*6)という仕様が提案
されたので、どちらの実装も知っている立場で本格的に議論に参加するよう
になったのでした。

(*1) https://datatracker.ietf.org/doc/html/rfc7519
(*2) https://datatracker.ietf.org/wg/jose/
(*3) https://datatracker.ietf.org/wg/cose/
(*4) https://www.rfc-editor.org/rfc/rfc9052.html
(*5) https://www.rfc-editor.org/rfc/rfc9180.html
(*6) https://datatracker.ietf.org/doc/draft-ietf-cose-hpke/


■ COSE、HPKE、そして COSE-HPKE

経緯で触れた主要な技術仕様について、もう少し詳しく解説します。

まずは COSE (CBOR Object Signing and Encryption)から。

あるデータに電子署名を付けて送付するケースを想定してみてください。署
名者(送信者)から検証者(受信者)に渡す情報として、データ本体と署名デー
タの他にどんな情報が必要でしょうか。署名検証に使う送信者の公開鍵は信
頼できる別ルートから取得するのが普通ですが、公開鍵の識別子はあったほ
うがいいでしょう。電子署名のアルゴリズム、署名対象データのフォーマッ
ト情報もあった方が相互運用性が高まります。さらに、これらの付随データ
も一部は改ざんされないよう署名で保護する必要があるでしょう。署名では
なく暗号データを送付するケースも同様です。公開鍵暗号方式で共通鍵を導
出する際には、鍵合意・鍵導出のアルゴリズム情報、鍵合意に使う送信者の
公開鍵も必要になります。データ自体の暗号鍵は別に設けて、公開鍵暗号を
使って導出した共通鍵で、このデータ自体の暗号鍵を暗号化してあわせて送
るようにできると便利です。このように、署名データや暗号データを、それ
ぞれ検証・復号するために必要な種々の付随データとあわせて運ぶためのデー
タコンテナの仕様がJOSEであり、COSEなのです。前者はテキストベースのJSON
を、後者はバイナリベースのCBORを使います。COSEは、リソースに制約のあ
るデバイスやユースケースを前提とした主にIoTをターゲットとしたIETFのさ
まざまなWG (SUIT、TEEP、RATS、SCITT、LAKE など)で、ベースとなるデータ
コンテナ仕様として採用されています。

続いて、HPKE (Hybrid Public Key Encryption) について。

ハイブリッド公開鍵暗号とは、公開鍵暗号方式を使って共通鍵を導出し、こ
れを使って共通鍵暗号方式でデータを暗号化するスキームのことです。公開
鍵暗号方式と共通鍵暗号方式の合わせ技なので「ハイブリッド」というわけ
です。HPKEは、このハイブリッド公開鍵暗号を独立した以下の3ステップの組
み合わせとして整理し、それぞれのステップで用いるアルゴリズムを厳選し、
柔軟に組み合わせて使えるスキームとして再構成したものです。

・KEM (Key Encapsulation Mechanism)：
  暗号データの送信者と受信者がそれぞれ作成した鍵ペアの公開鍵を交換し、
  自身の秘密鍵と相手の公開鍵から共通の鍵素材(shared secret)を作成する
  ステップ。

・KDF (Key Derivation Function)：
  shared secretから共通鍵暗号方式の共通鍵を導出するステップ。

・AEAD (Authenticated Encryption with Associated Data)：
  導出した共通鍵で暗号化し、復号するステップ。

HPKEのポイントの一つは、通信プロトコルやデータ形式から独立したファン
クションとして定義されている点にあります。これにより、さまざまなレイ
ヤの通信プロトコルやデータ形式と容易に組み合わせて使うことができます。
このため、RFC化(2022年2月)される前から、ECH (TLS Encrypted Client 
Hello)(*7)、MLS (Messaging Layer Security)(*8)、ODoH (Oblivious DNS 
over HTTPS)(*9)など、IETFのセキュリティ領域のさまざまな仕様で採用され
ていました。本記事の後半では、IETFで取り組まれているこれらのHPKE応用
技術の全体像と最新動向について概説します。

(*7) https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
(*8) https://www.rfc-editor.org/rfc/rfc9420.html
(*9) https://www.rfc-editor.org/rfc/rfc9230.html


最後に、HPKE応用の一つ COSE-HPKE (Use of HPKE with COSE) について。

COSE-HPKEは、COSE上でHPKEを使うための仕様です。IoT機器向けファームウェ
アの暗号鍵配送に用いるユースケース(SUIT WG)を想定して、COSE WGに提案

されました。もともとCOSEにもハイブリッド公開鍵暗号を行う仕組みは備わっ
ているのですが、私は以前から改善の必要性を感じていました。主な理由は、
鍵合意・鍵導出アルゴリズムのバリエーションの少なさ、送信者の公開鍵配
送用データ形式の不必要な煩雑さ、鍵導出にアプリケーションコンテキスト
をバインドするやり方の不必要な煩雑さ、の3点です。(紙幅の都合上、説明
は省きますが) HPKEは、実はこれらの問題点をすべて解消してくれるソリュー
ションになっており、レガシーなCOSEの暗号関連機能(JOSEで言えばJWE)は、
おおむねCOSE-HPKEで置き換えられると個人的には期待を寄せています。

些末な話を除くと、COSE-HPKEのレイヤで仕様として決めるべきことは、送信
者から受信者に暗号データと共に渡す付随データ(カプセル化された送信者の
公開鍵と、選択したKEM・KDF・AEADの組み合わせ)をどのように渡すかだけな
のですが、私も参戦し、延々と1年以上もメーリングリスト上で議論が続きま
した。


■ COSE-HPKEへの貢献

なぜ延々と議論が続いたのか？ 主な争点は二つでした。一つは、カプセル化
された送信者の公開鍵(encapsulated key)の表現方法。もう一つは、KEM・
KDF・AEADの組み合わせをCOSE上でどう扱うか(後述する暗号スイート方式 vs 
アラカルト方式)。

前者について、初期のドラフトでは、encapsulated keyをCOSE Key (JOSEで
言えばJWK)という構造化データとして表現する仕様になっていたのですが、
HPKEの仕様上、これはシンプルなバイト列で表現すべきものでした。私(と、
もう1人)がメーリングリスト上で問題提起し、長い議論を経てバイト列に修
正されました。

後者がさらに大変でした。まず前提として、COSEには、利用するアルゴリズ
ムIDを入れるalgというヘッダがあり、このアルゴリズムIDは IANAレジスト
リ(*10)に登録された数値で表現されます。例えば、ECDHとHKDFを使う鍵合
意・鍵導出アルゴリズムには、-25 (ECDH-ES+HKDF-256)が割り当てられてい
ます。一方のHPKEのKEM・KDF・AEADにも同様に、それぞれ IANAレジストリ
(*11)に登録された数値のアルゴリズムIDが割り当てられています。例えば、
P-256曲線のECDHを使うKEMは、0x0010 (DHKEM-P256)、SHA256ベースのKDFは、
0x0001 (HKDF-SHA256)、鍵長128bitのAES-GCMは、0x0001 (AES-128-GCM)とい
うように。

(*10) https://www.iana.org/assignments/cose/cose.xhtml
(*11) https://www.iana.org/assignments/hpke/hpke.xhtml


ここで二つの方式が提案されました。一つ目は、COSEのalg値にKEM・KDF・
AEADの組み合わせを入れてしまう方式(暗号スイート方式)です。例えば、上
記例の組み合わせ(HPKE-Base-P256-SHA256-AES128GCM)に対してアルゴリズム
IDを割り当てる、といった感じです。二つ目の方式は、COSEのalg値には、
HPKEであることを表すだけの値を定義・指定しつつ、HPKEのKEM・KDF・AEAD
のアルゴリズムID値をそのまま使い、encapsulated keyも含める、つまり、
HPKEに必要な情報をそのまま含める新たなヘッダを定義する方式(アラカルト
方式)です。私はアラカルト方式推し、というか提案者の1人でした。理由は
いろいろあるのですが、アラカルト方式の場合、例えば耐量子KEMがHPKEのレ
ジストリに新規登録された際に、新たにCOSE-HPKEの拡張仕様を作る必要も、
実装を変える必要もないからです。またCOSEの実装者として、alg値に厳密な
暗号スイート定義を入れることへの抵抗もありました。実際、algヘッダに
は、今回の暗号スイート方式ほどの厳密な定義値を入れた例はあまりなかっ
たのです。私にとっては、アラカルト方式の優位は明白だったのですが、メー
リングリスト上での長い議論と投票の結果、暗号スイート方式に決まりまし
た。

この議論の間にも、私はいち早くCOSE-HPKEを実装して仕様へのサンプルデー
タの提供を行ったり、細かい修正提案を行ったりと地道に貢献していたこと
もあり、後者の議論には負けたものの、共著者の1人に迎え入れられました。
この辺り、やはりIETFは、良いカルチャーだなと思いました。

ここまでが、IETF 118開催前の話です。前置きが長すぎました。


■ IETF 118での活動

ということで、IETF 118は、Internet-Draftの共著者の1人として参加した初
めてのIETFになりました。IETFの期間は土曜日に始まり翌週の金曜日に終わ
るのですが、初日の土曜日朝から翌日曜日の夕方までハッカソンが開催され
ます。私もHPKEの拡張仕様を実装しようと1人ハッカソンを決め込んで参加し
ていたのですが、 共著者につかまり、COSE WG会合での発表資料作成と、そ
のための議論を行いました。

議論の主なテーマは、暗号スイートの選定でした。上述の通り暗号スイート
方式に決定したわけですが、HPKEのKEM・KDF・AEADはそれぞれ提案中のもの
もすべて含めると各々10種類、3種類、6種類。組み合わせは180通りになりま
す。この中からリーズナブルな暗号スイートを選択しなければなりません
(これも私が暗号スイート方式にネガティブだった理由の一つだったのです
が……)。ちなみに、他のHPKE応用仕様の中で、COSEと同じく暗号スイート方
式を採用しているのがMLSなのですが(ECH、ODoH、OHTTP 等、他はすべてアラ
カルト方式)、先行するMLSは7種類の暗号スイートを選定していました。これ
を軸に、いくつかの選択肢を提示する方向で資料をまとめました(*11)。発表
も「ダイスケがやって」と押し付けられ、アラカルト方式推しだった私が、
なぜか暗号スイートの選択肢を挙げて意見を募るプレゼンをするという、何
とも因果な顛末となりました。共著者になった洗礼ということでしょうか。

(*11) https://datatracker.ietf.org/meeting/118/materials/slides-118-cose-use-of-hpke-with-cose


さておき、IETF 118のCOSE WG会合での気になる発表として、"Hybrid Key 
Exchange in JOSE and COSE"(*12)がありました。Nokia からの提案なのです
が、この「ハイブリッド」は、HPKEのハイブリッドとは異なる"PQ/T 
Hybrid"、つまり耐量子暗号方式と既存暗号方式の組み合わせという意味での
ハイブリッドです。内容はKEMにフォーカスしていて、PQ/T Hybrid KEM (具
体的には、NISTが選定したKyberとX25519を組み合わせるKEM)をCOSEのアルゴ
リズムに加え、同時に両方式の鍵を同時利用するための鍵表現の提案も含む
ものになっています。COSE-HPKEは、KEM・KDF・AEADの組み合わせにアルゴリ
ズムIDを付与する(一気通貫のものとしてとらえる)選択をしたわけですが、
私には、このCOSE-HPKEの方針と大きな乖離のある提案に見えています。
COSE-HPKEの共著者とは、この提案の鍵表現に欠陥があるという話や、私が
IETF 116で提案したHPKE KEMの汎用的な鍵表現がベターな解決策になるとい
う話をしました。近々、カウンター提案を行うかもしれません。

(*12) https://datatracker.ietf.org/doc/draft-ra-cose-hybrid-encrypt/02/


以上ここまでが、HPKEの応用の一つ、COSE-HPKEにフォーカスした私の活動報
告でした。COSEという比較的ニッチな技術領域のお話でしたが、扱っている
内容は、暗号スイート方式 vs アラカルト方式(これは、ここ数年たまに話題
に上がるCryptographic Agility批判(*13)に通底する議論)だったり、暗号ス
イートの選択の話だったり、PQ/Tハイブリッドの適用・運用の話だったりと、
テーマ自体は意外とニッチではない汎用的かつ普遍的なものだったことが伝
われば幸いです。

(*13) https://www.blockchaincommons.com/musings/musings-agility/


■ IETFにおける HPKE応用技術の動向

前述したように、HPKEは通信プロトコルやデータフォーマットから切り離さ
れた独立したファンクションとして定義されており、使い回しが良く、IETF
セキュリティエリアの各所で議論されているEnd-to-End暗号技術・プライバ
シー保護技術のベースとして活用されています。

現在、HPKEの応用が議論されているWGは以下の通りです。

・CFRG
・COSE WG
・JOSE WG
・MLS WG
・OHAI WG
・PPM WG

以下、各WGの概要、動向について概観していきます。


○CFRG (Crypto Forum Research Group)

CFRGは、IETFではなく長期的な研究寄りの活動を担う IRTF (Internet 
Research Task Force)に属する研究グループです。プリミティブな暗号アル
ゴリズム等の要素技術の研究開発を行っており、HPKEもここでRFC化されまし
た。現在、HPKEの拡張仕様として、以下の三つが提案されています。

・Deterministic Nonce-less Hybrid Public Key Encryption：
  EC鍵のコンパクト表現に対応したECDHベースのKEMと、nonceの再利用への
  耐性があるAES-GCM-SIVをそれぞれ、HPKEのKEMとAEADのラインナップに加
  える提案。
  https://datatracker.ietf.org/doc/draft-irtf-cfrg-dnhpke/

・secp256k1-based DHKEM for HPKE：
  secp256k1曲線を使ったECDHベースのKEMをHPKEのラインナップに加える提
  案。
  https://datatracker.ietf.org/doc/draft-wahby-cfrg-hpke-kem-secp256k1/

・X25519Kyber768Draft00 hybrid post-quantum KEM for HPKE：
  前述したハイブリッド耐量子KEMをHPKEのラインナップに加える提案。
  https://datatracker.ietf.org/doc/draft-westerbaan-cfrg-hpke-xyber768d00/

今回のIETF 118では、いずれも議論されませんでした。ちなみに、
secp256k1曲線を使ったDHKEMについては、私は仕様が提案される前に試験的
に実装していました。提案も検討していたのですが、先を越されました。著
者には実装者としてフィードバックを行っています。

○COSE (CBOR Object Signing and Encryption) WG

前述の通り、Use of HPKE with COSE (COSE-HPKE)(*14)が議論されています。
今回のIETF 118で取り上げた暗号スイートは、MLSが選定したものを踏襲する
方向か、あるいは、これに選択肢の対称性を考慮してAEADにChaChaPolyを用
いる暗号スイートをいくつか追加する方向のいずれかでまとまる見込みです。
大きめの課題が数件残っているのですが、個人的には次バージョンのドラフ
トでWGLCに進めるのではないかと考えています。

(*14) https://datatracker.ietf.org/doc/draft-ietf-cose-hpke/


○JOSE (JSON Object Signing and Encryption) WG

JOSEは、Webセキュリティではお馴染みのJWT (JSON Web Token)を含む、JSON 
ベースのセキュリティデータコンテナ仕様を扱うWGです。JWT、JWA、JWS、
JWE、JWKという一連のJSONベースの仕様を策定し、活動をクローズしていまし
たが、横浜で開催された IETF 116から、新たにJWP (JSON Web Proof)を定義
する目的で再開されました。前回(IETF 117)から、JWP以外のテーマも扱うよ
うになり、今回のIETFでは、Use of HPKE with JOSE (JOSE-HPKE)(*15)が提
案されました。JOSEとCOSEは特に暗号まわりの仕様が微妙に異なるため、COSE
をJOSEで置き換えるような単純な話では済まない可能性が高いです。

(*15) https://datatracker.ietf.org/doc/draft-rha-jose-hpke-encrypt/


余談ながら、今回、具体的な提案が出てきたFully Specified Algorithms 
for JOSE and COSE(*16)は、JOSEやCOSEのalg値に、厳密なアルゴリズムを入
れるようにしようというMichael B. Jonesらの提案なのですが、これは、
COSE-HPKEの議論の中で、私が「alg値は(特にCOSEでは)アルゴリズムを厳密
に定義するものにはなっていない」と指摘したことが提案の端緒になってい
るものです。

(*16) https://datatracker.ietf.org/doc/draft-jones-jose-fully-specified-algorithms/


○MLS (Messaging Layer Security) WG

MLSは、End-to-Endメッセージングをセキュアに行うためのアーキテクチャと
プロトコルを扱うWGです。ここで扱うプロトコルは、メッセージング自体の
プロトコルではなく、主にEnd-to-End暗号通信を行うためのクライアント間・
グループ間での鍵素材の共有など、鍵管理、グループ・クライアント管理の
ための制御プロトコルです。むしろ、メッセージングプロトコルとは独立・
非依存のものになっています。HPKEは、もちろんEnd-to-End暗号を実現する
基本仕様として採用されています。

前回のIETF 117に先立つ2023年7月、プロトコル仕様(*17)がRFC化されました
(RFC9420)。IETFの会合でシャンパンがふるまわれるのを初めて目にしました
が、一つの区切りがついたということでしょう。片割れのアーキテクチャ仕
様はまだRFC化されていませんが、今回の会合では、WGのチャーター(趣意書)
の更新が主な議題でした。本記事の執筆時点では、チャーターのドラフト
(*18)は、MLSプロトコルの拡張にフォーカスした内容にアップデートされて
いました。

(*17) https://www.rfc-editor.org/rfc/rfc9420.html
(*18) https://github.com/mlswg/wg-materials/blob/main/wg-charter/01-01


○OHAI (Oblivious HTTP Application Intermediates) WG

OHAIは、匿名性の高いPrivacy-PreservingなHTTPアクセスを実現する仕組み
を扱うWGです。要は個々のHTTPアクセスをサーバ側から見たときに
"Unlinkable"にしようという話なのですが、これを実現するプロトコルとし
てOblivious HTTP (OHTTP)(*19)という仕様の策定を進めています。これは、
クライアントとサーバの間に、クライアントのIPアドレスはわかるがリクエ
ストの内容はわからない「リレー」と、クライアントのIPアドレスはわから
ないがリクエストの内容はわかる「ゲートウェイ」という二つのコンポーネ
ントを設けることで目的を達成するのですが、クライアントとゲートウェイ
が、リレーにわからないようにリクエストをやり取りするところにHPKEが使
われています。

(*19) https://datatracker.ietf.org/doc/draft-ietf-ohai-ohttp/


今回、OHAI WGの会合は開催されませんでしたが、私が本記事を執筆している
2024年1月時点で、コア仕様であるOHTTPはAUTH48に進んでおり、まもなくRFC
化される見込みです。

○PPM (Privacy Preserving Measurement) WG

PPMは、プライバシーを保護しつつメトリクス収集・集約するためのプロトコ
ルを扱うWGです。ここでは詳しい説明は省きますが、クライアントからのメ
トリクス収集や、集約データの共有にHPKEによるEnd-to-End暗号が活用され
ています。Let's Encryptを運営しているISRG (Internet Security Research 
Group)が、ここで策定中のDAP (Distributed Aggregation Protocol for 
Privacy Preserving Measurement)(*20)というプロトコルを使ったDivvi Up
(*21)というプライバシー保護メトリクス収集サービスをローンチしようとし
ています。このため、WGの会合では、Divvi Upの実装状況の報告も行われた
りしています。今回の会合のメイントピックはやはりDAP仕様で、Issueベー
スで活発なディスカッションが行われていました。

(*20) https://datatracker.ietf.org/doc/draft-ietf-ppm-dap/
(*21) https://divviup.org/

余談ですが、このDivvi Upが、Webブラウザ上で動くクライアント実装に私の
HPKEライブラリを採用してくれています。こういうところも、OSSや標準化活
動をする醍醐味の一つかなと思います。

以上、HPKEとその応用に関する動向について一通り概説してみました。既に
策定されたECHやODoHだけでなく、現在でも多様なユースケースやレイヤで
HPKEの活用検討が進んでいることが伝われば幸いです。


     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
      わからない用語については、【JPNIC用語集】をご参照ください。
             https://www.nic.ad.jp/ja/tech/glossary.html
                  ◇              ◇              ◇
            メールマガジン以外でも、情報を発信しています！
             JPNICブログ  https://blog.nic.ad.jp/
                 Twitter  https://twitter.com/JPNIC_info

      YouTubeでは各種セミナー資料や解説動画などを公開しています
                 https://www.youtube.com/@JPNIC_info
     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃     ◆◇◆◇◆   本号のご感想をお聞かせください   ◆◇◆◇◆     ┃
┃良かった                                                          ┃
┃ https://feedback.nic.ad.jp/2060/4f71ef3e1c5962b49533b4997516fe21 ┃
┃                                                                  ┃
┃悪かった                                                          ┃
┃ https://feedback.nic.ad.jp/2060/c98efdce0ef8ce0c926ef8e6567f890c ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
■■■■■  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へのご連絡/お問い合わせは極力電子メールでお願いします ━━
  ■ 各種お問い合わせ先：https://www.nic.ad.jp/ja/profile/info.html ■
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 JPNIC News & Views vol.2060 【臨時号】

 ＠ 発行  一般社団法人 日本ネットワークインフォメーションセンター
          101-0047 東京都千代田区内神田2-12-6 内神田OSビル4階
 ＠ 配信先変更・停止  https://www.nic.ad.jp/ja/mailmagazine/#regist
 ＠ 問い合わせ先 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), 2024 Japan Network Information Center