stanford-oval/wikipedia huggingface dataset:
公開鍵基盤
概要

インターネットのような電子的な通信路を介して通信を行う際、通信の安全性を確保するための技術として、公開鍵暗号方式や電子署名方式がある。これらの技術では通信相手の公開鍵を用いることで送信する文書を暗号化したり、文章に対する署名を検証したりすることで、文章の秘匿性や真正性を保証する。
これらの技術を使う際には、暗号化や署名検証で用いた公開鍵が通信相手のものであることを事前に確認する必要がある。なぜなら、もしこの確認がなされていないと、たとえば、不正者が通信相手の公開鍵を偽の公開鍵とすりかえるなりすましなどの攻撃が可能になってしまうからである。
しかし、公開鍵とその持ち主との対応関係を確実に保証するのは容易ではない。インターネットは基本的に匿名の通信路であるので、公開鍵の所有者と名乗っている人物が本当に所有者当人であるのかを知るのは容易ではないからである。
PKIは、公開鍵とその持ち主の対応関係を認証局（CA、Certification Authority）という第三者機関を用いて保証するための技術である。
各認証局Aは自身の公開鍵pkAを公開しており、この公開鍵pkAとそれに対応する秘密鍵を用いることで、PKIの利用者や団体、他の認証局などの公開鍵pkBとその所有者名Bの組（とその他必要情報を合わせたもの）に対する署名文certBを作成する。この署名文certBを、公開鍵pkBの所有者がBであることを保証する公開鍵証明書（public key certificate）という。
PKIの各利用者Cは、自身が最も信頼できると思われる認証局Zの公開鍵を事前に何らかの方法で入手しておく（方法は後述する）。この認証局Zの公開鍵pkZは、PKIにおける全ての信頼関係の起点となるので、認証局ZをCのトラストアンカー（Trust Anchor、信用点とも）という。
PKIの利用者Cが別の利用者（もしくは団体、認証局）Dの公開鍵pkDが本当にDのものであることを確認するには、pkDに対する公開鍵証明書certDを入手する。次に、この公開鍵証明書certDを発行した認証局Eの公開鍵pkEと、pkEに対する公開鍵証明書certEとを入手する。以下同様に繰り返し、最後にトラストアンカーの認証局Zにたどり着き、しかもそれまでに入手した公開鍵証明書が署名文として正当なものであれば、公開鍵pkDをDの公開鍵として受理し、そうでなければ棄却する。
以上がPKIの基本的な仕組みである。PKIには、この他にも公開鍵を失効するための仕組みや利用者の属性を証明する仕組みなどが備わっている。
認証局

認証局は公開鍵証明書などの電子証明書を発行するエンティティである。
認証局 > 運用ポリシー

各認証局は証明書の利用目的を定める証明書ポリシー（CP、Certificate Policy）と、CA の運用方法を定める認証実施規定（CPS、Certification Practice Statement）を規定する（RFC 3647）。
認証局 > 信頼モデル

認証局同士の信頼関係のモデルを信頼モデルという。様々な組織が様々な信頼モデルに基づいて認証局を運用しているが、代表的な信頼モデルとして以下のものがある。
単独モデルは1つの認証局が全てのユーザに証明書を発行するモデルであり、企業内の認証局などユーザ数が小規模な場合に用いられる。
階層型モデルは複数の認証局がツリー型の階層構造をなすモデルであり、WebモデルはWebブラウザなどのクライアントアプリケーションに予め認証局の一覧を埋め込むモデルである。
メッシュモデルは階層構造を持たない認証局が相互に認証しあうモデルであり、異なる運用ポリシー(＝CPとCPSの記載内容)を持つ「CAドメイン」の間を横断して接続する際に使われる。メッシュモデルでは異なるCAドメインにある認証局同士が相互に認証しあう相互認証でつながりあう。相互認証で用いられる証明書を相互認証証明書という。
ブリッジCAモデルは認証局同士がブリッジCAという認証局を通して接続するモデルである。メッシュモデルと同じく異なるCAドメイン間を結びつけるときに用いるが、各認証局が相互に認証しあうメッシュモデルと違い、各認証局は1つのブリッジCAとのみ相互認証する。これにより認証局1↔ブリッジCA↔認証局2というブリッジCAを媒介とした信頼関係が形成される。認証局の数が多い場合、認証局同士が直接相互認証するメッシュモデルでは相互認証の数が膨大になるが、ブリッジCAモデルではブリッジCAを媒介としたスター型のトポロジーの相互認証が形成されるのみなので、認証パスの数を減らすことができるという利点がある。
認証局 > ルート認証局

ルート認証局とは上位の認証局の認証を受けず、自分の正当性を自分で証明する認証局のことで、階層型モデルにおけるツリーの頂点に位置する認証局やWebモデルでアプリケーションに事前に登録されている認証局がこれに相当する。この二種類のルート認証局を区別するため、Webモデルのルート認証局をパブリックルート認証局と呼ぶことがある。ルート認証局以外の認証局は中間認証局と呼ぶ。
ルート認証局はPKIの信頼の起点であるトラストアンカーとして機能する。いずれかのCAドメインに属するルート認証局をトラストアンカーとして採用すれば、そのCAドメインと相互認証されている他のCAドメインの認証局の証明書も、相互認証を介してトラストアンカーまでたどり着くことができる。
電子証明書

電子証明書とは公開鍵証明書をはじめとした、認証局が発行する証明書のことである。電子証明書の標準としてX.509が広く採用されている。X.509に従って作成された電子証明書は、X.509証明書と呼ばれる。
電子証明書 > 電子証明書の種類

X.509証明書には次の3種類がある。公開鍵とその所有者の対応関係を証明する公開鍵証明書、公開鍵証明書で証明された人が所有する権限や役割を証明する属性証明書、自然に対して発行することを目的とした適格証明書がある。単に証明書といった場合は公開鍵証明書を指すことが多い。
公開鍵証明書には認証局に対して発行するCA証明書とPKIのユーザに対して発行されるエンドエンティティ証明書がある。CA証明書の特殊なものとして、認証局が自身の秘密鍵で署名した自己署名証明書がある。
暗号用の公開鍵と署名検証用の公開鍵は別のものを用いることが多く、このためこれら２つの公開鍵に別々の公開鍵証明書を発行することが多い。このような方法をデュアル鍵ペア方式という。
認証局が他の認証局に証明書を発行する場合などでは、相手を完全に信用するのではなく、証明書の拡張領域に条件を記載することで条件付きの信頼関係を構築することも可能である。
電子証明書 > 公開鍵証明書の発行

公開鍵証明書を発行する際、主に2つの作業を行う。1つ目は新しく証明書を発行してほしいエンティティ（以下、「加入者」）の本人確認などの登録手続きで、2つ目は加入者に実際に公開鍵証明書を発行することである。
この２つの手続きをいずれも認証局が行う運用形態もあるが、２つの手続きを別の機関で運用する運用形態もあり、この場合登録手続きを行う機関を登録局（RA、Registration Authority）、証明書発行手続きを行う機関を発行局（IA、Issuing Authority）という。
ただし「発行局」という言葉は実際にはあまり使われていず、発行局のことを「認証局」と呼ぶことが多い。本稿でも、以下では発行局を認証局と呼ぶことにする。
証明書の発行手順は以下のとおりである。まず加入者は自身が用いる公開鍵・秘密鍵ペアの生成と登録局における本人確認とを行う。
次に加入者は登録局に証明書の発行申請を行い、登録局は認証局に証明書の発行を依頼する。認証局は申請書を確認したあと証明書を発行し、登録局経由で証明書を加入者に配布する。
認証局はPKIの他の利用者が加入者の証明書を見つけやすいよう、（もしリポジトリがあれば）加入者の証明書をリポジトリに公開する。
上では加入者が自分で鍵ペアの生成するケースを説明したが、企業が全新入社員を加入者として一括登録するようなケースでは登録局である企業の側が全員分の鍵ペアを生成して各加入者に鍵ペアを配布する事も有り得る。この場合登録局が加入者に証明書を配布する際、一緒に秘密鍵も配布する。
電子証明書 > 他の利用者の公開鍵証明書の入手

PKIの利用者Aが別の利用者Bの公開鍵証明書を入手する方法として、利用者Bから電子メールなどの手段を用いて公開鍵証明書を送ってもらうというものがある。これをアウトオブバンドの送信方法という。
また公開鍵暗号や電子署名を利用する通信プロトコルの一部として公開鍵証明書の送信方法が組み込まれている場合があり、こうした通信プロトコルにしたがって利用者Bから公開鍵証明書を送信してもらう方法をインバンドな送信方法という。インバンドで公開鍵証明書を送信するプロトコルとしてS/MIME、PGP、TLSなどがある。
利用者Bから直接証明書を送ってもらうのではなく、多数の利用者の証明書を保存しているリポジトリからBの証明書を受け取る方法もある。リポジトリの実装方法に関しては様々なものがあり、いくつかはRFCになっている。具体的にはLDAP（RFC2559）やX.500のようなディレクトリ・サービスを利用したもののほか、FRPやHTTP（RFC2585）を使ったもの、DNS（RFC2538）を使ったものがある。
電子証明書 > 公開鍵証明書の更新

公開鍵証明書には有効期限が定まっており、この有効期限を超えた期限切れの証明書は無効になってしまう。
そこでPKIの利用者は証明書の期限が切れる前に新しい鍵ペアを生成し、新しい鍵ペアに対する証明書を発行してもらう必要がある。この作業を証明書の更新という。
更新時には古い鍵ペアを使って認証局から認証を受ける事ができるので、新しい証明書の発行の際にはネットワーク越しに更新手続きを行うことができる。
更新手続きを行ってから古い証明書が有効期限切れになるまでの間は、新旧両方の証明書がある事になる。この新旧の証明書を関連付けるため、リンク証明書という証明書を認証局から発行してもらう。リンク証明書にはNewWithOld、OldWithNewなどの証明書がある。NewWithOldは古い鍵ペアを使って作成した新しい公開鍵に対する証明書で、OldWithNewは逆に新しい鍵ペアを使って作成した古い公開鍵に対する証明書である。
利用者Aの古い公開鍵とその証明書（OldWithOld証明書という）をすでに所有している（Aとは別の）利用者Bは、利用者Aの新しい公開鍵とともにNewWithOld証明書を受け取る事で新しい公開鍵の真正性を確認できる。これにより利用者Bは利用者Aが新しい鍵ペアで署名した署名文の正当性を検証する事ができる。
逆に利用者Aの新しい公開鍵とその証明書（NewWithNew証明書という）をすでに所有している（Aとは別の）利用者Cは、利用者Aの古い公開鍵とともにOldWithNew証明書を受け取る事で古い公開鍵の真正性を確認できる。これにより利用者Cは利用者Aが古い鍵ペアで署名した署名文の正当性を検証する事ができる。
電子証明書 > 公開鍵証明書の失効

自身が保有する秘密鍵が漏洩した場合や、退職等により署名権限失った場合には、まだ期限が切れていない公開鍵証明書を無効化する必要がある。このための手続きを公開鍵証明書の失効という。
失効した証明書のリストの管理は認証局自身が行う場合と証明書の有効性検証に特化した組織が行う場合があり、後者の場合その組織を検証局という。
証明書が失効しているか否かを確認する方法としてCRLとOCSPがある。
電子証明書 > 公開鍵証明書の失効 > CRL

CRL（Certificate Revocation List、証明者失効リスト）はすでに失効した公開鍵証明書（のシリアル番号）のリストである。各利用者がこのリストを確認することで公開鍵の失効状況を確認ができる。
CRLの発行者は多くの場合証明書を発行した認証局自身であり、CRLにはその真正性を示すため発行者の署名が付与されている。
CRLはリポジトリという公開サーバに格納し、PKIの利用者はこのサーバにアクセスすることでCRLを入手できる。
CRLの中には、認証局の失効情報に特化したものが存在し、これを認証局失効リスト（ARL、Authority Revocation List）という。
CRLは定期的に更新され、新しい失効情報がCRLに随時載っていく。しかし利用者が証明書の失効を申請してからCRLが更新されるまでタイムラグが生じるという問題を抱える。そこでCRLの定期更新より早い頻度で最後の更新が行われてからの差分情報が公開することがある。この差分情報をデルタCRLという。
CRLの運用形態にはいくつかある。完全CRLは全ての失効情報を１つのCRLに記載する方法であるが、失効情報の数が大きくなるとCRL取得の負荷が大きくなる。
区分CRLでは失効情報を複数のCRLに分割する。区分CRLを用いるには証明書発行の段階で、その証明書が失効した場合に失効情報がどのCRLに載るかという情報（CRL配布点、CRLDP、CRL Distribution Point）を証明書に記載しておく。PKIの利用者はCRLDPを頼りにして、リポジトリから必要な区分CRLを取得する。
またPKI利用者の利便性を高めるため、様々な認証局が発行したCRLを別のCRL発行者が１つにまとめて配布する場合があり、このようなCRLを間接CRL（indirect CRL）という。
電子証明書 > 公開鍵証明書の失効 > OCSP

OCSP（Online Certificate Status Protocol）は証明書の失効状況の確認を実現するプロトコルであり、RFC 6960に規定されている。
この方法ではOCSPレスポンダというサーバに証明書が失効しているかどうかの情報が一括管理されている。証明書の失効状況を知りたい利用者（OCSPリクエスタ）がOCSPレスポンダに失効情報の問い合わせを行うと、OCSPレスポンダは「有効」、「失効」、「不明」のいずれかを返す。この際返答内容に対するOCSPレスポンダの署名文も同時に送信する。
失効情報をOCSPレスポンダで管理するため、認証局は失効情報をOCSPレスポンダに送信する必要がある。その際の送信プロトコルに規定はないが、CRLの形で失効情報を認証局から得たり、OCSPのプロトコルにしたがって認証局に失効情報を確認したりする。
またOCSPレスポンダとOCSPリクエスタの間の通信のレイヤに関しても規定がないが、HTTP、SMTP、LDAPなどが使われる。
日本の行政機関におけるPKI

政府認証基盤（GPKI、Government PKI）は日本政府が運用するPKIであり、全省庁共通の政府共用認証局（官職認証局）、政府認証基盤の外にある認証局と相互認証するためのブリッジ認証局、および国民や企業に配る文書やプログラムにつける署名に対する証明書を発行するアプリケーション認証局から構成される。
なおもともとは各省庁が自身で用いる認証局（府省認証局）を設置し、それらを総務省が設置しているブリッジ認証局を通して相互認証する構成であったが、府省認証局は平成20年以降順次廃止され、上述したスタイルになっている。
政府認証基盤では行政機関の公文書に対して署名するときに用いられる電子証明書を発行しており、これを官職証明書という。他にも府省等が運用する情報システムの認証等に使用する利用者証明書や暗号鍵の証明書として用いる暗号化通信用等証明書を発行している。
一方、日本の地方公共団体は地方公共団体情報システム機構が運営している地方公共団体組織認証基盤（LGPKI、Local Government Public Key Infrastructure）というPKIを利用している。LGPKIの認証局には地方公共団体の首長や管理職に職責証明書を発行する組織認証局、電子行政サービスのWebサーバの証明書などを発行するアプリケーション認証局、およびブリッジ認証局がある。
公的個人認証サービス（JPKI, Japanese Public Key Infrastructure）は都道府県単位認証局が各住人に対して住人の公開鍵に対する証明書を発行するサービスである。この公開鍵と証明書を使うことで各種行政サービスを受けることができる。2016年1月からは民間利用が開放されたので、民間のサービスを受ける際にも公的個人認証サービスが利用可能になった。
関連技術 > 時刻認証局とタイムスタンプ

→詳細は「タイムスタンプ」を参照
電子的なタイムスタンプとは、 信頼できる第三者機関（時刻認証局、Time Stamping Authority, TSA,）が電子的な文書に対してつける時刻の証明書（タイムスタンプトークン、Time-Stamp Token、TST）を発行する技術である。タイムスタンプトークンの生成方法には様々なものがあるが、後述のようにPKIを利用したものもある。なお時刻認証局が証明書に記載する時刻情報は、原子時計などの正確な時間計測器を管理している時刻配信局（Time Assessment Authority、TAA）から配信してもらう。
タイムスタンプには以下の種類がある。
PKIベース：PKIによる公開鍵証明書付きの電子署名を用いる
リンクトークン方式：ハッシュチェイン技術を利用した方式。時刻認証局がリンクトークンと呼ばれるハッシュ値１つを管理。不特定多数の利用者から文書が送られてくるたびに、その文書とリンクトークンとのハッシュ値を計算し、そのハッシュ値を新しいリンクトークンとする。
MACベース
アーカイビング方式：時刻認証局が文書のハッシュ値をすべて保管する方式
Transient鍵方式：短時間だけ有効な署名鍵を使う方式
| 方式 | RFC 3161 | X9> 95 | ISO/IEC 18014 |
| --- | --- | --- | --- |
PKI: Yes
| リンクトークン |  | Yes | Yes |
| MAC |  | Yes |  |
| アーカイビング |  |  | Yes |
| Transient鍵 |  | Yes |  |
| 署名つきリンクトークン |  | Yes |  |
より詳細な分類と評価は日本銀行の宇根正志による文献を参照。
なお、TAAに関する標準はJIS X5094:2011として標準化されており、これは後にISO/IEC 18014-4として国際標準化もされた。
関連技術 > 高度電子署名と長期署名

高度電子署名（Advanced Electronic Signature、略してAdES）とはEUの規則eIDASで定められたもので、電子署名の中で自然人ないしその代理人との対応付けがとれるものを指す。なお、高度電子署名で、安全な署名デバイスで生成され、さらに適格証明書（qualified certificate）がつけられたものは適格署名（Qualified Signature）という。
高度電子署名の標準化はCMS（暗号メッセージ構文）に従ったCAdES（ETSI TS 101 733、RFC5126、ISO14533-1）、XMLに従ったXAdES（ETSI TS 101 903、ISO14533-2）、PDFに従ったPAdES（ETSI TS 102 778、ISO 32000-1）がある。いずれも欧州電気通信標準化機構(ETSI)がその標準を策定し、ISOやRFCにも採用されている。
高度電子署名では提供される保護レベルの異なる6つのフォーマットを規定しており、その中には鍵の危殆化などに対応する長期署名の標準も規定されている。以下ではXAdESを例に説明したが、CAdESやPAdESも同様である：
XAdES, 高度署名(advanced signature)に関する欧州指針を単に満足するための基本フォーマット
XAdES-T（timestamp）：署名行為の否認に対して保護するためにタイムスタンプを追加する。
XAdES-C（complete), オフライン検証や将来的な検証ができるように(証明書や証明書失効リストなどの)検証データへの参照情報を署名文書に追加する。(しかしながら検証情報は保存しない)
XAdES-X（extended), 将来、チェーン中の証明書が危殆化する可能性から保護するために、XAdES-Cで導入された参照情報に対してタイムスタンプを追加する。
XAdES-X-L（extended long-term), 証明書や証明書失効リストの配布元が利用できなくなったとしても、将来検証できるように署名文書に証明書や失効リストそのものを追加する。
XAdES-A（archival), 長期に渡る保存期間において署名が脆弱になることによる危殆化を避けるために、アーカイブされたドキュメントに対し定期的(例えば毎年)にタイムスタンプを追加する
関連技術 > 権限管理基盤(PMI)と属性証明書

権限管理基盤（英語版）(Privilege Management Infrastructure、PMI)とは、PKIと類似した方法により、個人の持つ権限や属性を証明するための基盤技術である。この基盤において権限や属性を証明する証明書を属性証明書（英語版）（attribute certificate, or authorization certificate、AC）と呼び、PKIと同様X.509のフォーマットに従う。またPKIにおける認証局、ルート認証局に相当する機関をそれぞれ権限局（Attribute Authorities、AA。直訳は「属性権限者」）、ルート権限局（Sources of Authority、SOA）と呼ぶ。
その他 > 信用の輪 (Web of Trust)

公開鍵への署名を認証局が行う場合、その公開鍵の持ち主を信用するかどうかは、認証局の信用度に委ねられる。また、認証局による署名はコストや手間がかかる場合が多い。さらに、Webブラウザが認証局の公開鍵を同梱している場合、Webブラウザの配布元の信頼性を確保する必要がある。これらの問題を解決する手段として信用の輪 (Web of Trust) を構築する方法が挙げられる。これは、信頼し合う者同士が互いの公開鍵に自ら署名し合うことによって、互いの信用度を維持し、更に複数の者がこれを行うことで、直接署名の交換をしていない者同士でも、信頼している第三者を介することによって相手の信用度を維持できるというものである。この時の相手までの信頼関係の経路のことを信用パス (trust path) という。例としてPGP (Pretty Good Privacy) や、その標準仕様である OpenPGP のフリーな実装であるGnuPG (The GNU Privacy Guard) が挙げられる。PGPやそのクローンがEメールで広く使用されているので、最初にPGPによって実装された信用の輪は2004年現在最も広く使われている双方向PKIとなっている。CAcert.orgは、信頼関係の全情報がすべて中央のデータベースに入れられることを除いて、PGPの信用の輪と同等のPKI Web of Trustを運営している。
→詳細は「」を参照
その他 > 信用の輪 (Web of Trust) > MSD (mean shortest distance)

信用の輪における特定の鍵の信用度を表す指標の一つに MSD (mean shortest distance) がある。これは、信頼の輪に含まれているすべての人からの信用パスの最短長の平均値によって計算される。これは、信用パスが長いほど信用度は下がり、また多くの人から署名されているほど信用度が上がるという考え方に基づいている。右図の rio について、MSDを計算すると、信用パスの最短長は、james:1、mike:1、ken:2、john:2、lucy:3であるから、MSD はその平均の1.8となる。
その他 > 信用の輪 (Web of Trust) > キーサインパーティー

公開鍵への署名は、信頼性を確保するために署名する相手と直接会って行われるが、署名の交換を効率的に行うために、キーサインパーティー（英語版）が開催されることがある。これにより、個別に会って行う場合に比べ、一度に多数の人と署名の交換を行うことが可能である。
多くのキーサインパーティーでは、Sassaman-Efficient 方式（英語版）が利用されており、以下の手順によって行う。
キーサインパーティーの主催者に、自分の公開鍵を送付する。
主催者は、参加者の公開鍵が集まった時点で、公開鍵のリストを参加者全員に送付する。
参加者は受け取ったリストを印刷し、リストのハッシュ値を計算して印刷したリストに書き込む。
キーサインパーティーの開始時に参加者全員でハッシュ値を確認し、全員のリストが同一のものであることを検証する。
参加者は2列になって向かい合い、互いに本人確認（パスポートや免許証などの確認）をし、同時にリストのハッシュ値、及び記載された公開鍵の指紋（フィンガープリント）が正しいことを伝える。
本人確認と公開鍵の検証を行ったら、リストに印を付ける。
列をずらし、別の人と5、6の作業を繰り返し、これを全員に対して行う。
キーサインパーティーが終わったら、印を付けた相手の公開鍵をキーサーバーからダウンロードする。
公開鍵の指紋がリストに記載されているものと同一であることを確認し、自分の秘密鍵で相手の公開鍵に署名し、相手に送付する。
署名付きの公開鍵を受け取ったら、自分の鍵束に署名付きの鍵を取り込み、キーサーバーにアップロードする。
注意点として、公開鍵への署名を施す場合に念入りに本人確認を行うことである。インターネット上に配布されている公開鍵に対する安易な署名など、本人確認をせずに署名を行った場合、鍵の持ち主を特定することができず Web of Trust そのものの信頼性が著しく損なわれることになる。
また、未署名の公開鍵によるソフトウェアへの署名は、署名の意味をなさないことについても注意が必要である。
その他 > 信用の輪 (Web of Trust) > 利用

Debianやその派生OSなどの一部のLinuxディストリビューションでは、配布されているすべてのパッケージについて開発者がGnuPG署名を施すことで、パッケージの改ざんを防止している。したがって、Debianの開発者には Web of Trust への参加が義務付けられている。Linuxカーネルの開発においても、Web of Trust への参加が求められている。一方、開発者に限らず一般のユーザーも、Web of Trust に参加することで自分が使用しているソフトウェアの安全性を検証できる。
GitやBazaarなどの一部のバージョン管理システムには、リビジョンに対してGnuPG署名を施すことができるシステムが備わっている。
その他 > 簡易公開鍵基盤（Simple Public Key Infrastructure)

その他の選択肢として簡易公開鍵基盤（SPKI、スプーキーと読む）がある。これは公開鍵によるパブリック認証を行うものではないが、X.509の複雑さとPGPの Web of trust を克服しようという三つの独立した試みから生まれた。SPKIは人を鍵に結び付けることはしない。何故なら信頼されるのは人ではなく鍵そのものだからである。SPKIでは発行者が即ち承認者(verifier)でもあるので、信頼という概念がない。これはSPKIの用語で「オーソライゼーション・ループ」と呼ばれており、オーソライゼーションが設計に深く関わっている。
その他 > ロボットCA

ロボットCAとは、公開鍵の正当性を特定の条件から自動的に検証し、その条件について有効性を証明するための署名を自動的に行う無人プログラムである。ロボットCAは公開鍵システムの攻撃者、特に合法なサイトからのすべてのネットワークトラフィックを一時転換する種の攻撃者を排除もしくは大いに抑制することができる。
歴史

1976年にディフィー（Whitfield Diffie)、ヘルマン（Martin Hellman）の両名によって発表された安全な鍵交換の仕組みであるDiffie-Hellman（DH)、そして1978年にロナルド・リベスト（Ron Rivest)、アディ・シャミア（Adi Shamir)、レオナルド・エーデルマン（Leonard Adleman）の3名によって発表された非対称鍵アルゴリズムであるRSAは、安全な通信について劇的な変化をもたらした。高速デジタル通信（インターネットやその前身）の更なる発展により、利用者がお互いに安全に通信できる方法や、更に利用者が実際に対話していた人を確認できる方法の必要性が明白になった。利用者の同一性を公開鍵に結び付ける、暗号的に保護された証明書のアイデアが精力的に研究された。
初期の暗号技術の中から効果的な使い方ができる組み合わせが発明および分析された。World Wide Web（WWW）の発明とその急速な普及と共に、認証（authentication）と安全な通信の必要性が更に深刻となった。（電子商取引や、Webブラウザから商用データベースへのオンラインアクセスなど）商用の理由だけで十分だった。ネットスケープコミュニケーションズ（Netscape Communications Corporation）のテヘール・エルガメル（Taher ElGamal）たちは、鍵の立証やサーバ認証（v3より前は片方向のみ）などを含む、Secure Sockets Layer（SSL）プロトコル（httpsプロトコル）を開発した。このようにPKIの構造はWebの利用者/サイトが望む（あるいはそれ以上の）安全な通信のために造られた
ベンダーや起業家が広大な市場の可能性を予測し、新しい会社や企業内プロジェクトを始め、責任からの保護と法的な承認について議論され始めた。米国弁護士協会（American Bar Association、ABA）のテクノロジ・プロジェクトはPKI運用に関して予測し得る法的な側面について広範囲に渡る分析を発表し（ABA digital signature guidelines（英語版） 参照）、その後間もなくして、（1995年の米国ユタ州を皮切りに）世界中のあらゆる国や自治体が、法律の制定および規則の採択をし始めた。消費者団体などは、プライバシー、アクセス、責任について、幾つかの地域では更に考慮するべきであるという問題を挙げた。
制定された法律や規則とは異なり、上手くいっている商取引にPKIの体系を組み込むには技術上や運用上の問題があり、またそれは先駆者が予想していたより遥かに進展が遅かった。
21世紀の初めの数年までには、基本的な暗号技術を正確に展開することは容易ではない事や、（手動または自動の）運用手順を正確に設計することは容易ではない事（もし技術的に完璧に実施するように設計したとしても）、そして定められた標準規格はそれらの目的のために尊重するには不十分なことが明確になった。
PKIベンダーは市場を造ったが、1990年代中頃には必ずしも思い描いていた物ではなく、ゆっくり、そして期待されていた物とは多少違った方向に成長していった。PKIは、期待されていた幾つかの問題は解決せず、いくつもの大手ベンダーが撤退したり他社に買収されることになった。PKI最大の成功は政府に採用されたことである。現時点における最大のPKI実装は、米国防衛情報システム局（Defense Information Systems Agency、DISA）PKI infrastructure for the Common Access Cards programである。
使用例

PKIはさまざまなベンダからさまざまな種類のものが提供され、さまざまな使用方法がある(公開鍵の配布、ユーザの個人情報の隠蔽など)。
文章の暗号化や認証 --- 文章がXMLであればXML署名やXML暗号化など。文章が電子メールであれば、OpenPGPやS/MIMEなど。
ユーザー認証 --- スマートカードログオン、TLSによるクライアント認証など。
安全な通信プロトコルの初期セットアップ --- インターネット鍵交換（IKE）やTLSなど。 IKE、TLSともに初期セットアップ時は公開鍵暗号を用いるが、実際の通信は公開鍵暗号より速度が速い共通鍵暗号を用いる。
実装

一部の主要な認証局（Verisignなど）は、他のソフトウェアが使用できないためここには記述していない。
Red Hat Certificate System
Computer Associates eTrust PKI
Entrust
マイクロソフト
US Government External Certificate Authority (ECA)
Nexus
OpenCA（サーバソフトを含む公的に利用可能なPKIを目指すオープンソース運動）
RSA Security
phpki
GenCerti
ejbca
newpki
Papyrus CA Software
pyCA
IDX-PKI
EuropePKI（休止中）
TinyCA
ElyCA
SimpleCA
SeguriData
Web of Trustの例。矢印は互いの公開鍵に署名したことを示す。例えばrioは、james、mike、kenを経由してlucyを信用できる。
キーサインパーティーの様子。参加者は互いに身分証明をするとともに、公開鍵リストに記載された鍵の同一性を検証する。
カノムサネーチャン

カノムサネーチャン （タイ語: ขนมเสน่ห์จันทน์  、発音 [kʰā.nǒm sā.nèː t͡ɕān] ）とは、タイで伝統的に食べられている菓子の一種。通常、丸く鮮黄色を呈する。タイでは、結婚式でよく出される。
語源

カノムサネーチャンの「チャン」は、後述しているように、この菓子に色や形が似ている果実「チャン」に由来する。「サネー」はタイ語で魅力を、「カノム」は菓子を意味する。
歴史

カノムサネーチャンの発祥に関する伝承の一つとして、次のようなものがある。
「ある若い男は、母親のためにある木から鮮黄色の果実を摘み取った。彼がその果実を夕食に食べるために持ってきたとき、その果実はどこへ行ったかわからなくなったものの、彼の家はまだその果実のにおいがした。彼は母親にこの果実を食べさせてあげたかったので、満月が出ている間に果実がなっていた木のもとへ戻った。彼が木のもとに着いたとき、そこには同じようにその果実を欲しがっている女性がいた。その女は男に、「私があなたに果物のうちのいくらかを与えたら、私の父が感謝するだろう」と言ったので、彼らはいくらかの果実を家に持ち帰った。その日から、彼は満月の夜ごとに木のもとへ行き、女性に会った。彼らは恋に落ちて結婚した。」
この伝説によると、チャンの果実は幸福と感謝をもたらすものである。
ソース

“Menu”. oknation.net. 2015年5月6日閲覧。 Freya. (2013, December 10)
c. “ความหมายของขนมหวานไทย...”. GotoKnow. 2015年3月27日閲覧。 C. (2009, March 15).
ศิรสุภรณ์ ไสยวงศ์. “ขนมเสน่ห์จันทน์”. sirasuporn.blogspot.com. 2014年11月25日閲覧。 ศิรสุภรณ์ ไสยวงศ์. (2012, August 14).
レジリエンス (曖昧さ回避)

レジリエンス（英語: Resilience）とは、適応力、即ち「変化に対処する能力」である。脆弱性（英語: vulnerability）の反対語の意味で使われる。
レジリエンスはまた、次を指す場合もある。
自然科学

レジリエンス（環境）
環境分野における、レジリエンスは、生態系が被害に抵抗して迅速に回復することによって、摂動または外乱に対応する能力である。そのような混乱と外乱には、火災、洪水、暴風雨、昆虫の人口爆発、森林伐採、石油採取のための地面の荒れ、土壌に散布された農薬、外来植物や動物種の導入などの人間活動が含まれる。
レジリエンス（気候変動）
気候変動におけるレジリエンスは、気候変動によってそれに課される外部ストレスに直面してストレスを吸収し、機能を維持し、(2)システムの持続可能性を改善し、将来の気候変動への影響に対してよりよく準備したまま、より望ましい構成に適応させ、再編成し、進化させる社会・生態系システムの能力として一般的に定義される 。
土壌レジリエンス
社会科学

レジリエンス（経営・組織）
レジリエンス (心理学)
人間力レジリエンス
エネルギー開発#レジリエンス、エネルギーの開発
工学

レジリエンス（工学・建築・防災）
工学・建築および防災分野における、レジリエンスとは、建物やインフラにおける設計目標であり、完全な失敗によって苦しめられることなく、損傷を吸収または回避する能力である。国土強靭化（ナショナルレジリエンス）のように「強靭化」の和訳が使用されることもある。
レジリエンス（ネットワーク）
コンピュータネットワークにおける、レジリエンスとは、障害や通常運用の困難に直面しても、許容できるレベルのサービスを提供し維持する能力である。
レジリエンス（材料工学・物性）
材料工学・物性分野における、レジリエンスとは、物質が弾力的に変形したときにエネルギーを吸収し、アンロード時にエネルギーを放出する能力である。 耐力は、永久歪みを生じさせることなく、弾性限界まで吸収され得る最大エネルギーとして定義される。 弾性率は、永久歪みを生じさせることなく単位体積当たりに吸収され得る最大エネルギーとして定義される。
その他

クルードラゴン・レジリエンス ：スペースXが製造した有人宇宙船
レジリエンス (曲) - 彩音の曲。ゲームソフト『メモリーズオフ -Innocent Fille-』オープニングテーマ。
HAKUTO-R ミッション2のランダーの愛称。
ジェアリン・ブラシュケ

ジェアリン・ブラシュケ（Jarin Blaschke、1978年9月28日 - ）は、アメリカ合衆国の撮影監督。ロバート・エガース監督作品の常連スタッフとして知られている。
生い立ち

カリフォルニア州ウェストミンスター出身。16歳でニューヨークに移住し、スクール・オブ・ビジュアル・アーツに入学して撮影技術を学んでいる。
キャリア

2016年に参加した『ウィッチ』で注目を集め、多くの映画賞にノミネートされた。2019年には『ライトハウス』で再び注目を集め、アカデミー賞、英国アカデミー賞、クリティクス・チョイス・アワードにノミネートされたほか、インディペンデント・スピリット賞を受賞している。
撮影作品 > 映画

ブラッドナイト（英語版）（2009年）
Fray（2012年）
I Believe in Unicorns（2014年）
ウィッチ（2015年）
美しい湖の底（2017年）
Back Roads（2018年）
ダーク・スクール（英語版）（2018年）
ライトハウス（2019年）
ノースマン 導かれし復讐者（2022年）
ノック 終末の訪問者（2023年）
ノスフェラトゥ（2024年）
撮影作品 > テレビシリーズ

サーヴァント ターナー家の子守（2020年）
アガサ・クリスティー 蒼ざめた馬（英語版）（2020年）
受賞歴

| 年 | 作品 | 映画賞 | 部門 | 結果 | 出典 |
| --- | --- | --- | --- | --- | --- |
| 2015年 | ウィッチ | 2016シアトル映画批評家協会賞（英語版） | 撮影賞 | ノミネート |  |
| 2019年 | ライトハウス | 第35回インディペンデント・スピリット賞 | 撮影賞（英語版） | 受賞 |  |
| 2019年 | ライトハウス | 第92回アカデミー賞 | 撮影賞 | ノミネート |  |
| 2019年 | ライトハウス | 第73回英国アカデミー賞 | 撮影賞 | ノミネート |  |
| 2019年 | ライトハウス | 2019シアトル映画批評家協会賞（英語版） | 撮影賞 | ノミネート |  |
| 2019年 | ライトハウス | 第24回サンディエゴ映画批評家協会賞 | 撮影賞（英語版） | 受賞 |  |
| 2019年 | ライトハウス | 第32回シカゴ映画批評家協会賞 | 撮影賞（英語版） | ノミネート |  |
| 2019年 | ライトハウス | 第18回サンフランシスコ・ベイエリア映画批評家協会賞 | 撮影賞（英語版） | ノミネート |  |
| 2019年 | ライトハウス | 第18回ユタ映画批評家協会賞 | 撮影賞 | 次点 |  |
| 2019年 | ライトハウス | 第23回オンライン映画批評家協会賞 | 撮影賞（英語版） | ノミネート |  |
| 2022年 | ノースマン 導かれし復讐者 | 第17回ダブリン映画批評家協会賞 | 撮影賞 | ノミネート |  |
| 2024 | ノスフェラトゥ | 第96回ナショナル・ボード・オブ・レビュー賞 | 撮影功績賞 | 受賞 |  |
| 2024 | ノスフェラトゥ | 第8回アストラ映画賞（英語版） | 撮影賞 | ノミネート |  |
| 2024 | ノスフェラトゥ | 第23回ワシントンD.C.映画批評家協会賞（英語版） | 撮影賞（英語版） | 受賞 |  |
| 2024 | ノスフェラトゥ | 第29回サンディエゴ映画批評家協会賞（英語版） | 撮影賞 | 受賞 |  |
| 2024 | ノスフェラトゥ | 第37回シカゴ映画批評家協会賞 | 撮影賞 | ノミネート |  |
| 2024 | ノスフェラトゥ | ラスベガス映画批評家協会賞 | 撮影賞 | ノミネート |  |
| 2024 | ノスフェラトゥ | 第21回セントルイス映画批評家協会賞 | 撮影賞（英語版） | 受賞 |  |
| 2024 | ノスフェラトゥ | 第23回サンフランシスコ・ベイエリア映画批評家協会賞 | 撮影賞 | ノミネート |  |
| 2024 | ノスフェラトゥ | ニューヨーク映画批評家オンライン賞 | 撮影賞 | ノミネート |  |
| 2024 | ノスフェラトゥ | 第33回サウスイースタン映画批評家協会賞 | 撮影賞 | ノミネート |  |
| 2024 | ノスフェラトゥ | フェニックス映画批評家協会賞 | 撮影賞 | 受賞 |  |
| 2024 | ノスフェラトゥ | 2024シアトル映画批評家協会賞 | 撮影賞 | ノミネート |  |
| 2024 | ノスフェラトゥ | インディアナ映画ジャーナリスト協会賞 | 撮影賞 | 受賞 |  |
| 2024 | ノスフェラトゥ | ノーステキサス映画批評家協会賞 | 撮影賞 | 受賞 |  |
| 2024 | ノスフェラトゥ | 第20回オースティン映画批評家協会賞（英語版） | 撮影賞 | ノミネート |  |
| 2024 | ノスフェラトゥ | 第23回ユタ映画批評家協会賞 | 撮影賞 | 次点 |  |
| 2024 | ノスフェラトゥ | 第30回クリティクス・チョイス・アワード | 撮影賞 | 受賞 |  |
| 2024 | ノスフェラトゥ | 第29回サテライト賞（英語版） | 撮影賞（英語版） | ノミネート |  |
| 2024 | ノスフェラトゥ | 第28回オンライン映画批評家協会賞 | 撮影賞 | ノミネート |  |
| 2024 | ノスフェラトゥ | 第45回ロンドン映画批評家協会賞 | 技術功績賞（英語版） | ノミネート |  |
| 2024 | ノスフェラトゥ | EDA賞 | 撮影賞 | ノミネート |  |
| 2024 | ノスフェラトゥ | 第39回全米撮影監督協会賞（英語版） | 撮影賞（英語版） | ノミネート |  |
| 2024 | ノスフェラトゥ | 第97回アカデミー賞 | 撮影賞 | ノミネート |  |
佐藤さやか (アナウンサー)

| --- | --- |
: 競輪関係の業務に携わっている神奈川県平塚市出身のフリーアナウンサーとは異なります。
| さとう さやか佐藤 さやか> プロフィール |
| --- | --- |
本名:  中村 さやか
出身地:   日本 東京都立川市
生年月日:   (1981-07-23) 1981年7月23日（43歳）
血液型:  A型
最終学歴:  共立女子大学国際文化学部卒業
所属事務所:  ボイスワークス
職歴:  福島放送アナウンサー 静岡朝日テレビ契約アナウンサー（臨時）
活動期間:  2004年 -
ジャンル:  スポーツ番組、情報番組
配偶者:  有り
公式サイト:  公式プロフィール
担当番組・活動
出演経歴:  『熱烈応援マリーゼくらぶ』 『ウィークエンドケア』 『ウィークリー千葉県』
アナウンサー: テンプレート - カテゴリ
佐藤 さやか（さとう さやか、1981年7月23日 - ）は、関東地方を拠点に活動する日本のフリーアナウンサー。ボイスワークス所属。
本名は中村 さやか（なかむら さやか）、旧姓は佐藤。
来歴

東京都立川市出身 で、2000年に共立女子第二高等学校、2004年に共立女子大学国際文化学部、それぞれを卒業した。
2004年4月から2007年3月まで福島放送 (KFB) でアナウンサーを務めた。同期に元同局アナウンサーの莇陽子がいる。2005年 と2006年 にANNアナウンサー賞「原稿のないもの」部門奨励賞を受賞した。
2007年4月から関東地方でフリーアナウンサーとして活動を始める。2007年10月に『安住紳一郎の日曜天国』（TBSラジオ）のアシスタント中澤有美子の産休入りに伴う代役オーディションに合格する。2007年末まで中澤を代替し、中澤の産休復帰後は夏休み時にアシスタントを務める。2010年2月1日から4月30日まで静岡朝日テレビ (SATV) で臨時契約アナウンサーを務めた。
2011年に結婚して3月12日の披露宴に先駆け11日午前に婚姻届を提出したが、同日午後に東日本大震災が発生した。披露宴は延期して11月13日に改めて催したとブログで報告した。
2013年4月3日に長男を出産した。
担当番組 > テレビ番組

熱烈応援マリーゼくらぶ（福島放送）
ふくしまスーパーJチャンネル（福島放送） - 天気予報担当、中継担当
週刊ことばマガジン（東日本放送） - 福島方言の回担当。同期の莇陽子と交互に出演
TVイーハトーブ 土曜のてっぺん（東北地方のANN加盟6局ブロックネット番組） - 福島放送担当アナウンサー（2006年4月15日 - ）
ウィークエンドケア（福島放送）
KFBニュース（福島放送）
高校野球ダイジェスト（テレビ埼玉） - キャスター、リポーター（2007年7月）
ウィークリー千葉県（チバテレビ）
Forza!! Mareeze（TOKYO MX）
コミch（コミチャン）ニュース（J:COM 関東）
まちかわHometown（J:COM 関東）
とびっきり!しずおか（静岡朝日テレビ） - 特集コーナーリポーター（2010年2月15日 - 4月9日・2011年2月25日）
彩の国ニュースほっと（テレビ埼玉） - リポーター（2011年4月 - ）
ボクシング中継（スカイ・A sports+）
日本バスケットボールリーグ (JBL) 中継（スカイ・A sports+）
Jリーグ中継（スカパー!） - ジェフユナイテッド市原・千葉担当（2012年）、大宮アルディージャ担当（2014年・2015年）
なでしこリーグ中継（スカパー!） - おもにジェフユナイテッド市原・千葉レディース戦
日本車椅子バスケットボール選手権大会中継（スカパー!）
担当番組 > ラジオ番組

Come on REDS! (REDS WAVE) - パーソナリティ（2007年10月7日・11月24日・12月16日）
安住紳一郎の日曜天国（TBSラジオ） - 中澤有美子不在時に代理
産休：2007年10月28日 - 12月30日
夏休み：2009年9月6日・2010年11月7日・2011年11月27日・2012年11月4日・2013年11月3日・2014年11月9日・2015年11月1日・2016年10月30日・2017年11月5日・2018年8月19日・2019年8月18日・2020年8月23日・2021年11月14日・2022年10月2日・2023年8月13日・2024年8月11日
コンラート・バウアー

| コンラート・バウアー Konrad Bauer |
| --- | --- |
 
渾名:  ピット
生誕:  1919年2月9日  ヴァイマル共和国 ゲルゼンキルヒェン
死没:   (1990-06-17) 1990年6月17日（71歳没）  ドイツ連邦共和国 ゲルゼンキルヒェン
所属組織:   ドイツ国防軍空軍  ドイツ連邦軍空軍
軍歴:  不明 – 1945年(国防軍) 不明 – 1960年(連邦軍)
最終階級:  中尉(国防軍) 大尉(連邦軍)
テンプレートを表示
コンラート・バウアー(ドイツ語: Konrad Bauer、1919年2月9日 - 1990年6月17日)は、ドイツの軍人。最終階級は国防軍で空軍中尉、連邦軍で空軍大尉。第二次世界大戦では総撃墜数57機の戦果を上げたエース・パイロットである(39機は西部戦線で、18機は独ソ戦で撃墜)。その戦功により騎士鉄十字章を受章した。
経歴

第二次世界大戦が勃発すると、バウアーは独ソ戦に従軍した。1943年3月20日に初戦果を上げ、その後18機を撃墜したところで西部戦線へ配属替えとなった。
通算34機の撃墜を記録したことにより、バウアーは1944年10月31日に騎士鉄十字章を受章している。最終的に西部戦線では39機を撃墜し、大戦を通して57機の撃墜を記録した。戦後はドイツ連邦軍に入隊し、空軍大尉の階級で1960年に退役した。
叙勲

空軍名誉杯 (1944年3月31日)
ドイツ十字章
ドイツ十字章金章 (1944年7月10日)
騎士鉄十字章
騎士鉄十字章 (1944年10月31日)
JPEG 2000

| --- | --- |

オリジナルのJPEGフォーマットとJPEG 2000との比較
拡張子: .jp2, .jpg2,.jpc,.jph,.j2c, .j2k, .jpf, .jpx, .jpm, .mj2,.jph
MIMEタイプ: image/jp2, image/jp2, image/jpx, video/mj2, image/jpm,image/jph
開発者: Joint Photographic Experts Group
種別: 画像ファイルフォーマット
国際標準: ISO/IEC 15444
オープンフォーマット: はい。
JPEG 2000（ジェイペグにせん）は、静止画像圧縮技術及び同技術を用いた画像フォーマットの呼称である。ISOとITUの共同組織であるJoint Photographic Experts Groupによって、国際標準化が進められており、ISO/IECの規格書15444およびITU-Tの勧告書Rec.T.800シリーズとして出版されている。
JPEG2000と詰めて書かずに、JPEG 2000と書くのが正式な表記である。JPEG 2000では、JPEGを上回る圧縮効率とスケーラビリティなどの機能を付加することを目的に規格策定作業が進められた。なお、国際標準の規格書/勧告書で規定されているのは、JPEG 2000のコードストリームをデコードするための手順である。したがって、エンコーダの仕様については何も定められていない。どのように実装されたとしても、エンコーダに要求されるのは、標準によって規定された手順でデコードできるコードストリームを出力することである。
技術の概要

JPEG 2000では、JPEGと同様、入力画像に対して周波数変換を施し、その変換係数に対して量子化、エントロピー符号化を適用することで画像の持つデータ量を圧縮する。JPEGとの要素技術における主な相違点は、以下の通り。
周波数変換に離散コサイン変換ではなく、離散ウェーブレット変換 (Discrete Wavelet Transform:DWT)を用いること
エントロピー符号にハフマン符号ではなく、算術符号を用いること
可逆符号化(ロスレス)と非可逆(ロッシー)符号化を同一の方式にて実現可能であること
JPEG 2000は、一つの圧縮画像を様々な解像度やビットレート等で利用できるというスケーラビリティ機能を有しているが、これは特に、量子化された変換係数から圧縮されたビットストリームを生成する役割を担うEBCOT(Embedded Block Coding with Optimized Truncation)アルゴリズムの持つ、高い符号化効率、圧縮後のレート制御(Post Compression Rate Distortion Optimization:PCRD-opt)などの特長に依るところが大きい。
Part

2020年6月現在、JPEG 2000はPart1からPart16までが標準化されている。
ITU-T側で出版されている勧告書のうち、無料で入手可能なものには参照を付した。
| Part | 内容 | ISO/IEC IS | ITU- T Rec>  |
| --- | --- | --- | --- |
| 1 | 基本方式, 基本ファイルフォーマット .jp2 | 15444-1 | T.800 |
| 2 | 拡張 | 15444-2 | T.801 |
| 3 | Motion JPEG 2000, 動画像向けファイルフォーマット .mj2 | 15444-3 | T.802 |
| 4 | 適合性試験 | 15444-4 | T.803 |
| 5 | 参照ソフトウェア | 15444-5 | T.804 |
| 6 | 複合画像（文字と写真等が混在した画像）向けファイルフォーマット .jpm | 15444-6 | T.805 |
7: 
| 8 | Secure JPEG 2000, JPEG 2000画像のためのセキュリティサービス (JPSEC) | 15444-8 | T.807 |
| 9 | 双方向通信のためのツール, API, JPIPプロトコル | 15444-9 | T.808 |
| 10 | 3次元画像データのための拡張 | 15444-10 | T.809 |
| 11 | ワイヤレス通信のための誤り検出・訂正符号化 (JPWL) | 15444-11 | T.810 |
12: 
| 13 | エントリレベルエンコーダ | 15444-13 | T.812 |
| 14 | XMLによるファイルフォーマットあるいはコードストリームの記述法 (JPXML) | 15444-14 | T.813 |
| 15 | 高スループットブロック符号化, High Throughput JPEG 2000 (HTJ2K), .jph | 15444-15 | T.814 |
| 16 | JPEG 2000画像のHEIF(ISO/IEC 23008-12)へのカプセル化 | 15444-16 | T.815 |