リファレンス

用語集

デジタル署名、証明書、トークン、プロトコル、ポスト量子暗号に関する 302 件の用語を収録しています。それぞれを数文で定義し、規定している規格と結び付けています。

302 件中 302 件を表示

アルファベット順

A

AAGUID（認証器アテステーション GUID）: WebAuthn のアテステーション済み認証情報データに含まれ、特定のセキュリティキーやパスワードマネージャーなど認証器のモデルを示す 16 バイトの識別子で、メタデータやアイコンの検索に使われます。
ACME の dns-01 チャレンジ: クライアントが _acme-challenge.domain に base64url(SHA-256(鍵認可)) を含む TXT レコードを公開する ACME のドメイン認証の方法で、ワイルドカードの名前を検証できる唯一の ACME の方法です。
ACME の http-01 チャレンジ: クライアントがポート 80 の http://domain/.well-known/acme-challenge/token で鍵認可を提供し、CA が複数のネットワーク視点からそれを取得する、ACME のドメイン認証の方法です。
ACME 更新情報（ARI）: CA が各証明書を更新すべき期間（ウィンドウ）をクライアントに通知する RFC 9773（2025年6月）の ACME 拡張で、これにより CA は負荷を分散し、大量失効に先立って早期の更新を促すことができます。
ACME（自動証明書管理環境）: Let's Encrypt のために作られた RFC 8555 のプロトコルで、クライアントはチャレンジによって識別子の管理権限を証明し、人手を介さずに CA から証明書を取得します。
AEAD（関連データ付き認証付き暗号）: 機密性と完全性を 1 回の操作で提供し、さらにヘッダーなど暗号化しない関連データも認証する共通鍵暗号のモードで、RFC 5116 で汎用的に定義されています。
AES-GCM: ガロア・カウンターモード（NIST SP 800-38D）の AES で、最も広く使われている AEAD です。カウンターモードの暗号化に GHASH によるメッセージ認証を組み合わせ、通常は 96 ビットの nonce と 128 ビットのタグを使います。
age（ファイル暗号化）: Filippo Valsorda による小さくモダンなファイル暗号化ツールおよび形式（age-encryption.org/v1）で、X25519、SSH、ポスト量子ハイブリッドの受信者、またはパスフレーズに宛てて暗号化し、署名も設定もありません。
alg none（保護されていない JWS）: 署名部が空の、署名されていないトークンを表す JWS のアルゴリズム値 none（RFC 7518 §3.6）で、保護されていないコンテンツを明示的に想定している場合を除き、検証者は決して受け入れてはいけません。
alg（JOSE アルゴリズムヘッダー）: JWS の署名または MAC のアルゴリズム（例：ES256）や、JWE の鍵管理アルゴリズム（例：RSA-OAEP-256）を指定する JOSE ヘッダーのパラメーターで、RFC 7518 とその後の RFC で登録されています。
ALPN（アプリケーション層プロトコルネゴシエーション）: クライアントが h2 や http/1.1 などのアプリケーションプロトコルを提示し、サーバーがハンドシェイク内でそのいずれかを選ぶ RFC 7301 の TLS 拡張で、余分なラウンドトリップが発生しません。
APK 署名スキーム（v1〜v4）: v1 の JAR 署名、APK 署名ブロックに格納するファイル全体の署名である v2（Android 7.0）と v3（Android 9、鍵のローテーション）、対象を絞ったローテーションの v3.1（Android 13）、増分インストール用の v4（Android 11）からなる、Android のアプリ署名形式です。
Apple の公証（notarization）: Developer ID で署名された Mac ソフトウェアを対象とする Apple の自動マルウェアスキャンです。開発者は notarytool でビルドをアップロードし、Apple は Gatekeeper が確認するチケットを返します。このチケットはアプリやインストーラーにステープルできます。
ARC（Authenticated Received Chain）: メッセージを扱う各中継者が、自身が確認した認証結果を記録して封印する RFC 8617（2019年）の実験的プロトコルで、転送やメーリングリストによって後から壊れた認証結果を、最終的な受信者が信頼できるようにします。
ASCII アーマー: OpenPGP のバイナリパケットを、-----BEGIN PGP PUBLIC KEY BLOCK----- や -----END PGP PUBLIC KEY BLOCK----- などの行で挟んだ base64 として表すテキストエンコーディングです（RFC 9580 §6.2）。
ASN.1（抽象構文記法 1）: データ構造をエンコーディングとは独立して記述するための ITU-T X.680 の言語で、X.509 証明書、CMS、PKCS #8 の鍵、OCSP、LDAP、通信プロトコルの定義に使われます。
aud（オーディエンスクレーム）: トークンの宛先となる受信者を文字列または文字列の配列で示す、登録済みの JWT クレーム（RFC 7519 §4.1.3）で、各受信者は自分の識別子が含まれていることを確認しなければなりません。
Authenticode: Windows の実行ファイル、ドライバー、インストーラー、スクリプト向けの Microsoft のコード署名形式で、ファイルのハッシュに対する PKCS #7 SignedData を PE の証明書テーブルに埋め込み、通常はタイムスタンプも付けます。

B

Base64url: RFC 4648 §5 で定められた、URL とファイル名に安全な base64 のアルファベットで、+ と / を - と _ に置き換え、JOSE では = のパディングを省略します。JWT の各部分はすべて base64url でエンコードされます。
BIMI（メッセージ識別のためのブランド指標）: DMARC を強制ポリシーで運用しているドメインが、Gmail、Yahoo、Apple Mail など対応するメールボックスでメッセージの横に自社のロゴを表示できるようにする、DNS レコードと証明書による方式で、現在も IETF のインターネットドラフトの段階です。
BIP-32（階層的決定性ウォレット）: 1 つのシードから HMAC-SHA512 とチェーンコードを使って鍵のツリーを導出する Bitcoin の標準で、1 つのバックアップですべてのアドレスをカバーでき、拡張公開鍵を使えば秘密鍵なしで受取アドレスを導出できます。
BIP-39（ニーモニックシードフレーズ）: ウォレットのエントロピーを 2,048 語の単語リストから選んだ 12〜24 語で表し、そのフレーズを PBKDF2-HMAC-SHA512（2,048 回の反復）で引き伸ばして、BIP-32 で使う 64 バイトのシードにする標準です。
BIP-137（署名メッセージ形式）: 公開鍵を復元できる 65 バイトの ECDSA 署名を使う Bitcoin のメッセージ署名形式で、ヘッダーバイトがリカバリ ID とアドレスの種類の両方を表します（27〜30 は非圧縮の P2PKH、31〜34 は圧縮の P2PKH、35〜38 は P2SH-P2WPKH、39〜42 は P2WPKH）。
BIP-322（汎用署名メッセージ形式）: アドレスから支払う仮想トランザクションに署名することで、SegWit、Taproot、マルチシグを含むあらゆる種類のアドレスの管理を証明する Bitcoin のメッセージ署名標準です。
BIP-340（secp256k1 の Schnorr 署名）: 32 バイトの x 座標のみの公開鍵とタグ付きハッシュを使う、secp256k1 上の 64 バイトの Schnorr 署名を定めた Bitcoin の仕様で、Taproot と Nostr で使われています。
Bitcoin アドレス: Bitcoin の出力スクリプトを人が読める形でエンコードしたもので、従来の P2PKH（1…）と P2SH（3…）は Base58Check、SegWit v0（bc1q…）は bech32、Taproot（bc1p…）は bech32m で表します。
BLAKE2: 高速なハッシュ関数のファミリー（64 ビットプラットフォーム向けで最大 64 バイトのダイジェストを出力する BLAKE2b と、32 ビット向けで最大 32 バイトの BLAKE2s）で、RFC 7693 で規定され、Argon2、WireGuard、PASETO、libsodium で使われています。
BLS 署名: ペアリングに基づく署名方式（Boneh、Lynn、Shacham、2001年）で、署名が短く、決定的で、そのまま集約でき、最もよく知られた用途は BLS12-381 曲線を使う Ethereum のプルーフ・オブ・ステークのコンセンサスです。
Brainpool 曲線: パラメーターが検証可能な擬似乱数として生成された楕円曲線のファミリー（RFC 5639、2010年）で、NIST 曲線の代替として、ドイツをはじめとするヨーロッパ各国の政府系プロファイルで好まれています。

C

C2PA（コンテンツ認証情報）: コンテンツの来歴と真正性のための連合（C2PA）が策定した、画像、動画、音声、文書に埋め込まれる署名付きの来歴マニフェストの標準で、誰がどのツールでコンテンツを作成・編集したか（AI による生成を含む）を記録します。
CA（認証局）: 証明書に記載する名前や身元が申請者のものであることを確認したうえで、証明書を発行して署名する組織またはサービスです。
CA/Browser Forum: 認証局とブラウザー・オペレーティングシステムのベンダーからなる任意団体で、公的に信頼される TLS、S/MIME、コード署名の証明書について、Baseline Requirements（ベースライン要件）をはじめとする規則を定めています。
CAA（認証局認可）: ドメイン所有者が、自身のドメイン名に対して証明書を発行してよい CA を列挙する DNS レコードの種類（RFC 8659）で、すべての公的な CA は発行前にこれを確認しなければなりません。
CBOM（暗号部品表）: システム内の暗号関連の資産（アルゴリズム、鍵、証明書、プロトコル、ライブラリとそのパラメーター）を機械可読な形で一覧にしたもので、ポスト量子暗号への移行などの計画と進捗管理に使われます。
Certificate Transparency（CT）: CA が公的に信頼されるすべての TLS 証明書を登録する、公開の追記専用マークルツリーのログ群（RFC 6962）による仕組みで、ドメインの所有者や監視者が誤発行された証明書を検出できるようにします。
ChaCha20-Poly1305: ChaCha20 ストリーム暗号と Poly1305 認証子を組み合わせた AEAD（RFC 8439）で、256 ビットの鍵、96 ビットの nonce、128 ビットのタグを使い、AES のハードウェア支援がなくてもソフトウェアで高速に動作します。
ClientHello: TLS ハンドシェイクで最初に平文で送られるメッセージで、クライアントはここに、対応するバージョン、暗号スイート、グループ、署名アルゴリズム、キーシェア（key share）、そしてサーバー名などの拡張を列挙します。
CMS（暗号メッセージ構文）: IETF による PKCS #7 の後継規格（RFC 5652）で、署名付きデータ、エンベロープ化されたデータ、認証付きデータを扱い、S/MIME、Authenticode、PDF 署名、RFC 3161 タイムスタンプ、多くのファームウェア形式で使われています。
CNSA 2.0: NSA の商用国家安全保障アルゴリズムスイート 2.0（2022年9月）で、米国の国家安全保障システムに対し、2030〜2035年までに ML-KEM-1024、ML-DSA-87、LMS または XMSS、AES-256、SHA-384 または SHA-512 を使うことを求めています。
COSE（CBOR Object Signing and Encryption）: JOSE に相当する CBOR ベースの仕様（RFC 9052 と RFC 9053）で、署名、MAC、暗号化、鍵を扱い、WebAuthn、mdoc 形式の運転免許証、CWT、C2PA で使われています。
cosign: コンテナイメージ、blob、アテステーションを署名・検証するための Sigstore のコマンドラインツールで、鍵を使う方式と、OIDC の ID と有効期間の短い証明書を使うキーレス方式があります。
CRL（証明書失効リスト）: 失効した証明書のシリアル番号を CA が署名して定期的に公開するリスト（RFC 5280 §5）で、検証者はこれをダウンロードし、証明書ごとに CA へ問い合わせることなく失効を確認します。
CRLite: Certificate Transparency に記録されたすべての証明書の失効状態をコンパクトなフィルターに圧縮する Firefox の失効確認の仕組みで、フィルターはブラウザーにダウンロードされ、ローカルで照会されます。
CSPRNG（暗号論的擬似乱数生成器）: 以前の出力を見た攻撃者でさえ、出力を予測することも真の乱数と区別することもできない乱数生成器で、鍵、nonce、ソルト、トークンに必要です。
CSR（証明書署名要求）: サブジェクト名、公開鍵、要求する属性を含む PKCS #10 メッセージ（RFC 2986）で、鍵の所有を証明するために対応する秘密鍵で署名されており、CA はこれをもとに証明書を発行します。
CTAP（Client to Authenticator Protocol）: クライアント（ブラウザーまたはオペレーティングシステム）と外部の認証器の間で、USB HID、NFC、Bluetooth、またはスマートフォンを使うハイブリッドトランスポートを介して通信するための FIDO Alliance のプロトコルで、authenticatorMakeCredential などの CBOR でエンコードされたコマンドを使います。
Curve25519: Daniel J. Bernstein が 2005年に提案した、素数 2²⁵⁵ − 19 上のモンゴメリー曲線 y² = x³ + 486662x² + x で、X25519 鍵交換の基盤であり、エドワーズ形式では Ed25519 署名の基盤にもなっています。
CWT（CBOR Web トークン）: JWT に相当する CBOR 版の仕様（RFC 8392）で、整数のクレームキーを持つ CBOR マップとしてエンコードしたクレームセットを、COSE の署名、MAC、暗号化で保護します。

D

DANE（DNS ベースの名前付きエンティティの認証）: DNSSEC で署名された TLSA レコード（RFC 6698、RFC 7671）を使って、TLS サービスが提示しなければならない証明書または公開鍵を指定する仕組みで、公的な CA と併用することも、公的な CA の代わりに使うこともできます。
DER（識別符号化規則）: ITU-T X.690 で定められた ASN.1 の正規バイナリエンコーディングで、すべての値のバイト表現をちょうど 1 通りに定めるため、証明書、CSR、CRL、鍵、そして多くの署名が DER でエンコードされています。
DID（分散型識別子）: did:method:identifier 形式の URI（W3C DID Core 1.0、2022年）で、公開鍵とサービスエンドポイントを列挙した DID ドキュメントに解決され、中央のレジストリではなくそのサブジェクト自身が管理します。
DKIM の正規化: DKIM でハッシュを計算する前にメッセージのヘッダーと本文を正規化する 2 つのアルゴリズム、simple と relaxed（RFC 6376 §3.4）で、c= タグでヘッダーと本文に別々に指定します。
DKIM リプレイ: 正当に DKIM 署名されたメッセージを変更せずに多数の新しい受信者へ再送し、署名ドメインのレピュテーションを利用する手口で、署名が SMTP エンベロープを対象にしていないため、DKIM では防げません。
DKIM-Signature ヘッダー: DKIM 署名を tag=value の組として格納するヘッダーフィールド（RFC 6376 §3.5）で、v、a、c、d、s、h、bh、b のタグと、任意の i、l、t、x タグを含みます。
DKIM（DomainKeys Identified Mail）: 送信ドメインがメッセージの選択したヘッダーと本文に署名し、公開鍵を DNS で公開する RFC 6376 のメール認証規格で、受信者はメッセージがそのドメインから改変されずに届いたことを検証できます。
DMARC: ドメインベースのメッセージ認証・報告・適合（RFC 9989、2026年5月）は、表示される From のドメインとアライメントした状態で SPF または DKIM に合格することを求め、失敗したメールの扱いを受信者に指示する DNS のポリシーです。
DMARC の識別子アライメント: SPF（エンベロープ送信者）または DKIM（d= のドメイン）で認証されたドメインが、From ヘッダーのドメインと、完全に（strict）または同じ組織ドメインの範囲内で（relaxed）一致することを求める DMARC の要件です。
DNSSEC: DNS セキュリティ拡張（RFC 4033〜4035）で、DNS のレコードセットに署名し、検証を行うリゾルバーが、応答がゾーン所有者から改変されずに届いたことを、ルートゾーンの鍵から連なる信頼の連鎖によって確認できるようにします。
DoH（DNS over HTTPS）: DNS のクエリとレスポンスを HTTPS リクエストで運ぶ RFC 8484 のプロトコル（メディアタイプ application/dns-message）で、経路上の観測者からそれらを隠し、Web アプリケーションが直接名前解決できるようにします。
DPoP（鍵の所有証明）: アクセストークンとリフレッシュトークンを、クライアントが保持する鍵に紐付ける RFC 9449 の OAuth の仕組みで、リクエストごとに新しく署名した DPoP プルーフ JWT を付けるため、盗まれたトークンだけでは使えません。
DSA（デジタル署名アルゴリズム）: 有限体上の離散対数問題に基づく FIPS 186（1994年）の署名アルゴリズムで、2023年の FIPS 186-5 で新しい署名への使用が廃止され、既存の署名の検証用にのみ残されています。

E

ECDH-ES（JWE の鍵共有）: RFC 7518 §4.6 で定められた JWE の鍵管理方式のファミリーで、送信者が一時的な EC 鍵を生成し、受信者の静的な鍵との間で秘密を共有して、Concat KDF でコンテンツ鍵を導出します。
ECDH（楕円曲線ディフィー・ヘルマン）: 各当事者が自分の楕円曲線の秘密鍵と相手の公開鍵を組み合わせて、同じ共有秘密（d_A·d_B·G の x 座標）を計算する鍵共有です。
ECDHE（一時的な楕円曲線ディフィー・ヘルマン）: ハンドシェイクごとに新しい鍵ペアを使う楕円曲線ディフィー・ヘルマンで、TLS に前方秘匿性をもたらす鍵交換です。TLS 1.3 では x25519、secp256r1 などのグループ上で実行されます。
ECDLP（楕円曲線離散対数問題）: 楕円曲線上の点 G と Q = d·G からスカラー d を求める問題で、その困難性が ECDSA、EdDSA、ECDH、Schnorr 署名の安全性の前提になっています。
ECDSA 公開鍵の復元: ECDSA 署名とメッセージのハッシュ値から署名者の公開鍵を計算すること（SEC 1 §4.1.6）で、Ethereum と Bitcoin のメッセージ署名では、鍵を送信する代わりにこの方法を使います。
ECDSA（楕円曲線デジタル署名アルゴリズム）: FIPS 186-5 と SEC 1 で規定された DSA の楕円曲線版で、署名は秘密スカラーと毎回新しい秘密の nonce から計算される整数の組 (r, s) です。
ECH（Encrypted Client Hello）: 本来の ClientHello をサーバー名も含めて DNS で公開された鍵で暗号化し、ネットワークからは共有の公開名しか見えないようにする、RFC 9849 で定義された TLS 1.3 の拡張です。
ecrecover: アドレス 0x01 にある Ethereum のプリコンパイル済みコントラクト（および Solidity の ecrecover 関数）で、32 バイトのハッシュ値と secp256k1 上の ECDSA 署名 (v, r, s) から署名者のアドレスを復元します。
Ed448: 「Goldilocks」と呼ばれる Edwards448 曲線上で SHAKE256 を使う EdDSA（RFC 8032 §5.2）で、セキュリティは約 224 ビット、公開鍵は 57 バイト、署名は 114 バイトです。
Ed25519: Curve25519 のエドワーズ形式上で SHA-512 を使う EdDSA（RFC 8032 §5.1）で、公開鍵は 32 バイト、決定的な署名は 64 バイト、セキュリティは約 128 ビットです。
EdDSA（エドワーズ曲線デジタル署名アルゴリズム）: RFC 8032 で定義され FIPS 186-5 で承認された、ツイストエドワーズ曲線上の Schnorr 型署名方式で、標準のインスタンスは Ed25519 と Ed448 の 2 つです。
eIDAS: 電子識別とトラストサービスに関する EU 規則（No 910/2014、2024/1183 により改正）で、この規則のもとでは、適格電子署名に手書き署名と同等の法的効力があります。
EIP-155（リプレイ保護）: チェーン ID をトランザクションの署名ハッシュと v の値（v = chainId × 2 + 35 または 36）に含める、2016年の Ethereum の変更（Spurious Dragon、ブロック 2,675,000）で、あるチェーン向けのトランザクションは他のチェーンでは無効になります。
EIP-191（署名付きデータの標準）: 署名するメッセージをバイト 0x19 とバージョンバイトで始めることで、有効なトランザクションになりえないようにする Ethereum の規約で、バージョン 0x45 はほとんどのウォレットが使う personal_sign 形式です。
EIP-712（型付き構造化データの署名）: 型付きの構造化データをドメインセパレーターとともにハッシュして署名する Ethereum の標準で、ウォレットはフィールドをユーザーに表示でき、署名を別のコントラクトやチェーンでリプレイすることはできません。
EIP-7702（EOA へのコード設定）: 2025年5月7日の Pectra ハードフォークから有効になっている Ethereum のアップグレードで、外部所有アカウントが、タイプ 0x04 のトランザクションに含めた署名付きの認可によって、自身のコードをコントラクトに委任できるようにします。
ERC-1271（コントラクトの署名検証）: スマートコントラクトのアカウントが署名を検証するための Ethereum の標準で、検証者は isValidSignature(bytes32 hash, bytes signature) を呼び出し、戻り値 0x1626ba7e を有効として扱います。
ES256: P-256 曲線の ECDSA と SHA-256 による JWS アルゴリズム（RFC 7518 §3.4、COSE のアルゴリズム −7）で、署名は DER ではなく、ちょうど 64 バイトの生の r‖s です。
Ethereum アドレス: 20 バイトのアカウント識別子です。外部所有アカウントでは、0x04 プレフィックスを除いた 64 バイトの非圧縮形式の secp256k1 公開鍵について Keccak-256 ハッシュ値を計算し、その末尾 20 バイトを 0x に続く 40 桁の 16 進数で表記したものです。
EUDI ウォレット（欧州デジタル ID ウォレット）: 規則（EU）2024/1183（eIDAS 2）により、すべての EU 加盟国が市民に提供しなければならない ID ウォレットで、本人識別データと属性のアテステーションを SD-JWT VC 形式と mdoc 形式で保持します。
EV 認証（Extended Validation）: CA/Browser Forum の EV ガイドラインで定められた、TLS 証明書で最も厳格な認証レベルで、CA は組織の法的・物理的・運営上の実在性を確認し、登録の詳細を証明書に記録します。
exp（有効期限クレーム）: Unix エポックからの秒数で時刻を示す JWT の登録済みクレーム（RFC 7519 §4.1.4）で、その時刻以降はトークンを受け入れてはいけません。

F

Falcon（FN-DSA）: NTRU 格子上のコンパクトな格子署名方式で、2022年に NIST に選定され、FIPS 206 で FN-DSA として標準化が進められています（FIPS 206 は 2026年10月時点でまだドラフトでした）。
FIDO メタデータサービス（MDS）: FIDO Alliance が提供する、認定済み認証器のメタデータステートメント（AAGUID、アテステーションのルート証明書、機能、認定ステータス）の署名付きフィードで、アテステーションの検証に使われます。
FIDO2: W3C の WebAuthn API と、FIDO のクライアントと認証器の間のプロトコル（CTAP 2.x）で構成される、公開鍵によるパスワードレス認証を指す FIDO Alliance の総称です。
FIPS 140-3: 暗号モジュールに関する米国とカナダの規格（2019年、ISO/IEC 19790 に準拠）で、CMVP はこの規格に基づいて、ハードウェアとソフトウェアのモジュールをセキュリティレベル 1〜4 で検証します。

G

Git コミット署名: Git のコミットとタグに OpenPGP、SSH（Git 2.34 以降）、X.509 の鍵で署名し、ホスティングプラットフォームやレビュアーが作成者を検証できるようにすることで、gpg.format と user.signingkey で設定します。

H

Harvest now, decrypt later（今収集し、後で解読）: 量子コンピューターが鍵交換を破れるようになった時点で解読するために、暗号化された通信を今のうちに記録しておく戦略です。量子コンピューターが実現する前からポスト量子鍵交換の導入が進められているのは、このためです。
HKDF: RFC 5869 で規定された HMAC ベースの抽出・拡張型の鍵導出関数で、ECDH の出力などの共有秘密を、コンテキスト文字列に結び付いた一様にランダムな 1 つ以上の鍵に変換します。
HMAC: RFC 2104 と FIPS 198-1 で規定された鍵付きハッシュのメッセージ認証コードで、H((K ⊕ opad) ‖ H((K ⊕ ipad) ‖ m)) として計算され、共通鍵を共有するすべての相手に対して完全性と送信元を証明します。
HQC（Hamming Quasi-Cyclic）: NIST が 2025年3月11日に ML-KEM のバックアップとして選定した符号ベースの鍵カプセル化メカニズムで、FIPS 207 として標準化される予定です。2026年10月の時点で、標準のドラフトはまだ公開されていません。
HS256: SHA-256 による HMAC を使う JWS アルゴリズム（RFC 7518 §3.2）で、発行者と検証者が 256 ビット以上の共通鍵を 1 つ共有するため、トークンを検証できる者は誰でもトークンを発行できます。
HSM（ハードウェアセキュリティモジュール）: 鍵の生成と保管、および暗号演算をその境界の内部で行う耐タンパー性のデバイスまたはクラウドサービスで、秘密鍵を平文でエクスポートすることはできません。
HSTS（HTTP Strict Transport Security）: RFC 6797 で規定された HTTP レスポンスヘッダーで、一定期間そのホストには HTTPS だけを使い、証明書エラーを無視して先へ進む操作を拒否し、http:// のリンクを自動的にアップグレードするようブラウザーに指示します。
HTTP メッセージ署名: HTTP リクエストやレスポンスの選択したコンポーネントに署名するための IETF 標準（RFC 9421、2024年2月）で、署名は Signature-Input と Signature のヘッダーフィールドで伝送されます。

I

ID トークン: ユーザーが認証されたことを示すために OpenID Connect プロバイダーがクライアントに発行する JWT で、少なくとも iss、sub、aud、exp、iat の各クレームを含み、プロバイダーによって署名されています。
in-toto: 署名付きのサプライチェーンのステートメントを扱う、CNCF の卒業プロジェクトであるフレームワークで、そのアテステーション形式（アーティファクトのダイジェストを型付きの述語に結び付ける Statement）が SLSA の来歴や SBOM のアテステーションを運びます。
iss（発行者クレーム）: トークンの発行者を示す登録済みの JWT クレーム（RFC 7519 §4.1.1）で、検証者は、署名の検証に使った鍵の発行者とこの値が完全に一致することを確認しなければなりません。

J

JA4（TLS クライアントフィンガープリント）: ClientHello に含まれるプロトコル、バージョン、SNI、暗号スイートと拡張の数とソート済みのハッシュ値から TLS クライアントのフィンガープリントを作る、FoxIO が 2023年に発表した手法で、ブラウザーが拡張の順序をランダム化しても値が変わらないよう設計されています。
JOSE（JSON オブジェクトの署名と暗号化）: 署名、暗号化、鍵の表現のための JSON ベースの形式からなる IETF の仕様群（RFC 7515〜7519 の JWS、JWE、JWK、JWA、JWT）と、それらを維持管理するワーキンググループです。
JWA（JSON Web Algorithms）: JWS、JWE、JWK で使うアルゴリズム識別子とパラメーターを定義する RFC 7518 で、HS256、RS256、ES256、PS256、RSA-OAEP、ECDH-ES、A256GCM などが含まれます。
JWE（JSON Web Encryption）: 暗号化されたコンテンツのための RFC 7516 の JOSE 形式で、コンパクト形式はヘッダー、暗号化された鍵、IV、暗号文、タグの 5 つの部分からなり、鍵管理（alg）とコンテンツ暗号化（enc）を分離しています。
JWK サムプリント: JWK の必須メンバーを正規形の JSON にしてハッシュした値（RFC 7638）で、通常は SHA-256 を base64url でエンコードしたものです。kid の値、DPoP の紐付け、ACME で、安定した鍵識別子として使われます。
JWK（JSON Web Key）: RFC 7517 で定義された暗号鍵の JSON 表現で、公開鍵には kty、crv、x、y、n、e などのメンバーがあり、秘密鍵の部分は d に入ります。
JWKS（JSON Web Key Set）: 公開鍵の JWK を keys 配列に持つ JSON オブジェクトで、通常は発行者の jwks_uri で配信され、リライングパーティがトークン検証と鍵ローテーションへの追従に使います。
JWS（JSON Web Signature）: JSON で記述したパラメーターを使って署名または MAC を付けたコンテンツのための RFC 7515 の JOSE 形式で、ヘッダー、ペイロード、署名をドットで連結したコンパクトな形式（header.payload.signature）か、複数の署名を持てる JSON 形式でシリアライズされます。
JWT（JSON Web Token）: クレームを表す JSON オブジェクトを運ぶ、コンパクトで URL セーフなトークン（RFC 7519）で、JWS として署名されるか JWE として暗号化され、ID トークン、アクセストークン、多くの API セッションに使われます。

K

Keccak-256: 標準化前のパディングを使う、出力 256 ビットのオリジナルの Keccak ハッシュで、Ethereum がアドレス、関数セレクター、署名用ハッシュに使っています。FIPS 202 の SHA3-256 とは別の関数です。
KEM（鍵カプセル化メカニズム）: Encaps が公開鍵からランダムな共有秘密と暗号文を生成し、Decaps が秘密鍵でその秘密を復元する公開鍵プリミティブで、ポスト量子鍵交換では Diffie–Hellman に代わって使われます。
key_share 拡張: クライアントが 1 つ以上のグループについて一時的な公開値を送り、サーバーが単一の応答を返す TLS 1.3 の拡張（51）で、これにより鍵交換が最初のラウンドトリップで完了します。
kid（鍵 ID）: トークンの署名や暗号化に使った鍵を示す JOSE ヘッダーのパラメーター兼 JWK のメンバーで、検証者は鍵のローテーション中でも JWKS から一致する鍵を選べます。
Kyber（CRYSTALS-Kyber）: NIST 第 3 ラウンドに提出された ML-KEM の前身で、ハイブリッド TLS（X25519Kyber768Draft00）で先行導入されましたが、標準化された ML-KEM とは相互運用できません。

L

LibrePGP: GnuPG の作者が管理する OpenPGP 仕様（draft-koch-librepgp）で、v5 鍵と独自の Kyber 複合暗号化によって RFC 4880bis の系譜を引き継いでおり、RFC 9580 の v6 鍵とは互換性がありません。
LMS と HSS（Leighton–Micali 署名）: RFC 8554 と NIST SP 800-208 で規定されたステートフルハッシュベース署名方式で、Winternitz ワンタイム鍵のマークルツリーで決まった数のメッセージに署名し、HSS はツリーを積み重ねてその数を増やします。
low-S 正規化: ECDSA 署名の s の値が範囲の下半分（s ≤ n/2）になければならないとする規則で、ECDSA に本来備わっている署名の展性をなくすために Bitcoin と Ethereum が採用しました。

M

MD5: Ron Rivest が 1991年に設計した 128 ビットのハッシュ関数（RFC 1321）で、2004年に衝突耐性が、2007年に選択プレフィックス衝突耐性が破られており、攻撃者が入力に影響を与えられるあらゆるセキュリティ用途で安全ではありません。
mDL（モバイル運転免許証）: ISO/IEC 18013-5 の mdoc としてスマートフォンに保持される運転免許証や州発行の身分証明書で、対面では NFC や Bluetooth で、あるいはオンラインで提示し、発行機関が署名した各データ要素を個別に開示できます。
mdoc（ISO/IEC 18013-5 モバイルドキュメント）: モバイル運転免許証のために作られた ISO/IEC 18013-5 の CBOR ベースの認証情報形式で、発行者がモバイルセキュリティオブジェクト内の要素ごとのダイジェストに署名し、デバイスは自身の鍵で所持を証明します。
ML-DSA（FIPS 204）: CRYSTALS-Dilithium から派生した FIPS 204（2024年8月）のモジュール格子ベースのデジタル署名アルゴリズムで、ML-DSA-44、ML-DSA-65、ML-DSA-87 のパラメーターセットを持つ NIST の主要なポスト量子署名です。
ML-KEM（FIPS 203）: CRYSTALS-Kyber から派生した FIPS 203（2024年8月）のモジュール格子ベースの鍵カプセル化メカニズムで、ML-KEM-512、ML-KEM-768、ML-KEM-1024 のパラメーターセットを持つ、標準のポスト量子鍵交換方式です。
mlkem768x25519-sha256: ML-KEM-768 と X25519、SHA-256 を組み合わせた SSH のハイブリッド鍵交換で、RFC 10042 で標準化され、バージョン 10.0（2025年4月）以降 OpenSSH のデフォルトです。
MTA-STS（SMTP MTA Strict Transport Security）: RFC 8461 で規定された仕組みで、メールドメインが HTTPS でポリシーを公開し、記載された MX ホストへは有効な証明書を使った TLS でのみ配信するよう送信者に求めます。
mTLS（相互 TLS）: クライアントも証明書と CertificateVerify の署名で認証する TLS で、両端がそれぞれ秘密鍵の所有を証明します。サービス間の通信、デバイス、OAuth の送信者制約付きトークンで広く使われています。
MuSig2: BIP-327 で定められた 2 ラウンドのマルチシグ方式で、n 人の署名者が共同で、1 つの集約公開鍵に対して有効な BIP-340 Schnorr 署名を 1 つ作成します。チェーン上では、単一の署名者による使用と見分けがつきません。

N

NIST IR 8547: NIST の『ポスト量子暗号標準への移行（Transition to Post-Quantum Cryptography Standards）』で、2024年11月の初期公開ドラフトです。量子コンピューターに対して脆弱な 112 ビット強度のアルゴリズムを 2030年より後に非推奨とし、2035年より後は量子コンピューターに対して脆弱なアルゴリズムをすべて使用禁止とすることを提案しています。
NIST のポスト量子セキュリティカテゴリ: NIST がポスト量子暗号のパラメーターセットについて、AES や SHA-2/SHA-3 を破る難しさと比較して定めた 5 段階の強度レベルの 1 つです。カテゴリ 1 は AES-128 の鍵探索、3 は AES-192、5 は AES-256 に相当し、2 と 4 は SHA-256 と SHA3-384 の衝突探索を基準にしています。
nonce（ECDSA の k）: 一度だけ使われる数です。ECDSA、DSA、Schnorr 署名では署名ごとの秘密値 k を指し、秘密にするだけでなく、予測不可能で一様に分布していなければなりません。
Nostr: 分散型のソーシャル・メッセージングプロトコルで、ユーザーは secp256k1 の鍵ペアであり、すべてのイベントは SHA-256 ハッシュで識別され、BIP-340 Schnorr 署名で署名された JSON オブジェクトです。
npm の来歴（provenance）: 対応する CI から公開された npm パッケージに付与される署名付きの SLSA 来歴（2023年9月26日に一般提供開始）で、パッケージの各バージョンを、そのソースリポジトリ、コミット、ビルドワークフローに結び付けます。

O

OAuth 2.0: RFC 6749（2012年）で定められた認可フレームワークで、認可サーバーがクライアントにアクセストークンを発行し、クライアントはユーザーのパスワードの代わりに、委任されスコープで限定された権限で API を呼び出します。
OCSP ステープリング: サーバーが自身の証明書について最新の OCSP レスポンスを取得し、ハンドシェイクの中で送信する TLS の機能で、クライアントはプライバシーを漏らす CA への問い合わせをせずに済みます。
OCSP（オンライン証明書ステータスプロトコル）: RFC 6960 で定められたプロトコルで、クライアントが CA のレスポンダーに特定の証明書が失効しているかを問い合わせ、有効期間付きで署名された good、revoked、unknown のいずれかの応答を受け取ります。
OID（オブジェクト識別子）: 1.2.840.10045.2.1 のようにドットで区切った、世界で一意の整数の並びで、委任された登録ツリーを通じて割り当てられ、ASN.1 でアルゴリズム、曲線、拡張、ポリシーを命名するために使われます。
OIDC（OpenID Connect）: OAuth 2.0 の上に構築されたアイデンティティレイヤー（OpenID Connect Core 1.0、2014年）で、クライアントは署名付きの ID トークンによってユーザーが誰であるかを検証し、UserInfo エンドポイントからプロフィールのクレームを取得できます。
OpenID4VP（OpenID for Verifiable Presentations）: 検証者がウォレットにクレデンシャルを要求し、提示（プレゼンテーション）を受け取るための OpenID Foundation のプロトコル（1.0 最終版、2025年7月）で、OAuth 2.0 を基盤とし、EU デジタル ID ウォレットで使われています。
OpenPGP: ユーザーが管理する鍵を使って、メッセージやファイルを公開鍵暗号で暗号化・署名するための IETF 標準（RFC 9580、2024年7月）で、GnuPG、Sequoia、OpenPGP.js などが実装しています。
OpenPGP v6 鍵: RFC 9580 で導入された鍵形式で、32 バイトの SHA-256 フィンガープリント、Ed25519/X25519/Ed448/X448 アルゴリズムのネイティブ対応、ソルト付きの v6 署名を備え、RFC 4880 の SHA-1 ベースの v4 鍵に代わるものです。
OpenSSH の秘密鍵形式: OpenSSH 7.8（2018年）以降、ssh-keygen がデフォルトで書き出す openssh-key-v1 コンテナで、-----BEGIN OPENSSH PRIVATE KEY----- として保存され、パスフレーズを設定すると bcrypt ベースの KDF で暗号化されます。

P

P-256（secp256r1）: 256 ビットの素体上で定義された NIST の楕円曲線で、secp256r1 や prime256v1 とも呼ばれ、約 128 ビットのセキュリティを持ち、ECDSA と ECDH で最も広く使われている曲線です。
P-384（secp384r1）: 位数が 384 ビットの、素体上で定義された NIST の楕円曲線で、約 192 ビットのセキュリティを持ち、NSA の CNSA 1.0 スイートで必須とされ、政府や CA の証明書階層で広く使われています。
P-521（secp521r1）: NIST の素体上の曲線で最大のもので、メルセンヌ素数 2⁵²¹ − 1 上で定義され、約 256 ビットのセキュリティを持ちます。JOSE の ES512 は P-521 上で SHA-512 を使う ECDSA を意味し、512 ビットの曲線ではありません。
PAdES: eIDAS の先進電子署名のための、PDF 署名の ETSI プロファイル（EN 319 142）で、ベースラインレベルとして B-B、B-T（タイムスタンプ付き）、B-LT（検証データを埋め込み）、B-LTA（アーカイブタイムスタンプ）があります。
PASETO（Platform-Agnostic Security Tokens）: JOSE よりシンプルな代替として設計されたトークン形式で、ネゴシエーション可能なアルゴリズムではなくバージョン付きのプロトコルを使い、v4.public トークンは Ed25519 で署名され、v4.local トークンは XChaCha20 で暗号化されて鍵付き BLAKE2b で認証されます。
PDF 署名: PDF ファイル（ISO 32000-2）に埋め込まれたデジタル署名で、その /ByteRange は署名値以外のすべてを対象とし、通常は証明書チェーンとタイムスタンプを含む分離形式の CMS または CAdES 署名です。
PEM: DER データを base64 にして -----BEGIN label----- 行と -----END label----- 行で挟んだテキスト形式で、PKIX オブジェクト向けに RFC 7468 で標準化されており、ほとんどのツールが証明書や鍵の保存に使っています。
permit（EIP-2612 と Permit2）: 署名によるトークンの承認です。オフチェーンの EIP-712 署名が spender にトークンの移動を許可し、オンチェーンの approve トランザクションの代わりになります。トークンごと（EIP-2612）に行う方法と、Uniswap の共有 Permit2 コントラクトを介する方法があります。
personal_sign: EIP-191 のバージョン 0x45 のプレフィックスを付けてメッセージに署名し、65 バイトの r‖s‖v 署名を返す Ethereum の JSON-RPC のウォレットメソッドで、ログインや単純なメッセージ署名のデフォルトです。
PIV（Personal Identity Verification）: 米国連邦政府のスマートカード標準（FIPS 201-3、2022年）とそのカードインターフェース（SP 800-73）で、鍵スロット 9A、9C、9D、9E にはそれぞれ認証、署名、鍵管理、カード認証の鍵が格納されます。YubiKey などのトークンが実装しています。
PKCE（Proof Key for Code Exchange）: RFC 7636 の OAuth 拡張で、クライアントは認可リクエストでランダムな code_verifier のハッシュ値を送り、トークンリクエストで code_verifier そのものを送ります。そのため、傍受された認可コードは役に立ちません。
PKCS #1 鍵形式: RFC 8017 付録 A で定義された RSA 専用の ASN.1 構造 RSAPublicKey と RSAPrivateKey で、PEM では -----BEGIN RSA PUBLIC KEY----- と -----BEGIN RSA PRIVATE KEY----- として保存されます。
PKCS #8: アルゴリズムに依存しない秘密鍵のコンテナ（RFC 5208 の PrivateKeyInfo、RFC 5958 の OneAsymmetricKey）で、PEM では -----BEGIN PRIVATE KEY-----、パスワードで保護されている場合は -----BEGIN ENCRYPTED PRIVATE KEY----- として保存されます。
PKCS #12（PFX）: 秘密鍵とその証明書チェーンをまとめて、ブラウザー、Windows、macOS、Java、Android にインポートできるようにする、RFC 7292 のパスワード保護されたアーカイブ形式で、通常は .p12 または .pfx として保存されます。
PS256: SHA-256 と MGF1-SHA-256 を使う RSASSA-PSS の JWS アルゴリズム（RFC 7518 §3.5）で、RS256 と同じ RSA 鍵を、ランダム化された、安全性が証明可能な PSS パディングで使います。
PSBT（部分署名済み Bitcoin トランザクション）: BIP-174（バージョン 0）と BIP-370（バージョン 2）で定められた交換形式で、未署名のトランザクションと、署名者が必要とするすべてのデータを運ぶため、ウォレット、ハードウェアデバイス、コーディネーターが別々のステップで署名できます。

Q

QUIC: RFC 9000 の UDP ベースのトランスポートプロトコルで、TLS 1.3 のハンドシェイクを統合し（RFC 9001）、通信のメタデータをほぼすべて暗号化し、HTTP/3 を運びます。

R

RFC 6979（決定的 ECDSA）: Thomas Pornin による 2013年の仕様で、DSA または ECDSA の nonce k を秘密鍵とメッセージのハッシュ値から HMAC-DRBG で導出するため、署名に乱数生成器が不要になります。
RS256: SHA-256 を使う RSASSA-PKCS1-v1_5 の JWS アルゴリズム（RFC 7518 §3.3）で、OpenID Connect プロバイダーで長らくデフォルトとされてきました。署名の長さは RSA のモジュラスと同じです（2048 ビット鍵では 256 バイト）。
RSA: Rivest、Shamir、Adleman による公開鍵暗号方式（1977年）で、安全性は大きなモジュラス n = p·q の素因数分解の困難さに基づいています。署名に使われるほか、かつては鍵輸送にも使われていました。
RSA-OAEP: OAEP（最適非対称暗号化パディング）を使う RSA 暗号化（RFC 8017 §7.1）で、JWE では RSA-OAEP（SHA-1）と RSA-OAEP-256（SHA-256）としてコンテンツ暗号化鍵のラップに使われ、攻撃の余地がある PKCS #1 v1.5 暗号化に代わるものです。
RSASSA-PKCS1-v1_5: ハッシュ値を ASN.1 の DigestInfo に包んで 0xFF バイトでパディングする、PKCS #1 v1.5 の決定的な RSA 署名パディング（RFC 8017 §8.2）で、JWT の RS256 にあたり、X.509 で最も一般的な RSA 署名です。
RSASSA-PSS: PKCS #1 v2.1 以降のランダム化された RSA 署名方式（RFC 8017 §8.1）で、ランダムなソルトと MGF1 マスク関数を使ってハッシュ値をエンコードし、PKCS #1 v1.5 にはないタイトな安全性証明を持ちます。

S

S/MIME: X.509 証明書と CMS を使ってメールに署名し暗号化するための標準（RFC 8551、S/MIME 4.0）で、Outlook、Apple Mail、Thunderbird に組み込まれています。公的に信頼される証明書には、CA/Browser Forum の S/MIME ベースライン要件が適用されます。
Safe マルチシグ（Safe スマートアカウント）: 最も広く使われている Ethereum のスマートコントラクトウォレットで、しきい値以上のオーナーが EIP-712 の SafeTx ハッシュに署名した場合にのみトランザクションを実行します。署名には ECDSA、コントラクト署名（ERC-1271）、オンチェーンでの承認を使えます。
SAML 2.0: ID プロバイダーとサービスプロバイダーの間で、署名付きの認証アサーションと属性アサーションをやり取りするための OASIS の XML 標準（2005年3月）で、現在も企業のシングルサインオンの基盤です。
SBOM（ソフトウェア部品表）: ソフトウェアに含まれるコンポーネント、バージョン、ライセンス、依存関係を機械可読な形でまとめた一覧で、主に SPDX または CycloneDX で記述され、脆弱性管理とコンプライアンスに使われます。
Schnorr 署名: 離散対数問題に基づく署名方式（Claus Schnorr、1989年）で、応答 s = r + e·x が鍵に対して線形であるため、簡潔な安全性証明、バッチ検証、ネイティブな多重署名が可能です。
SCT（署名付き証明書タイムスタンプ）: CT ログが、証明書またはプレ証明書を自身の公開ログに登録することを署名付きで約束するもので、証明書への埋め込み、TLS 拡張、ステープルされた OCSP レスポンスのいずれかでクライアントに届けられます。
SD-JWT VC: SD-JWT を検証可能なデジタルクレデンシャル向けにプロファイルした IETF のインターネットドラフトで、typ dc+sd-jwt、クレデンシャルの型を示すクレーム vct、ステータス、発行者の鍵ディスカバリを定めています。EU のウォレットの 2 つのクレデンシャル形式の 1 つです。
SD-JWT（JWT の選択的開示）: RFC 9901（2025年11月）の形式で、発行者はクレームのソルト付きダイジェストに署名し、保有者は対応するディスクロージャーを送ることで、選んだクレームだけを開示します。キーバインディング JWT を添えることもできます。
SEC 1 ECPrivateKey: SEC 1 と RFC 5915 で定められた楕円曲線の秘密鍵の構造で、OpenSSL は -----BEGIN EC PRIVATE KEY----- として書き出します。スカラーを、任意の曲線パラメーターと公開点とともに格納します。
secp256k1: SEC 2 で定められた 256 ビットの Koblitz 楕円曲線 y² = x³ + 7 で、Bitcoin が採用し、Ethereum と Nostr でも使われています。セキュリティレベルは約 128 ビットです。
Secure Enclave: iPhone、iPad、Mac、Apple Watch のチップに搭載された、Apple の隔離されたセキュリティコプロセッサーで、エクスポートできない鍵を生成し、チップ内で署名や復号を行います。Face ID、Touch ID、パスコードによる保護を任意で設定できます。
security.txt: /.well-known/security.txt で公開されるテキストファイル（RFC 9116）です。サイトの所有者に脆弱性を報告する方法を、セキュリティ研究者に伝えます。
SHA-1: FIPS 180-1（1995年）で規定された 160 ビットのハッシュ関数です。現在では衝突耐性が実際に破られており、NIST は 2030年12月31日までに、あらゆる暗号的保護の用途から廃止する予定です。
SHA-2: FIPS 180-4 で規定されたハッシュ関数のファミリー（SHA-224、SHA-256、SHA-384、SHA-512、SHA-512/224、SHA-512/256）で、NSA が設計し、2001年に公開されました。現在ではほぼあらゆる場面でデフォルトのハッシュです。
SHA-3: FIPS 202（2015年）で標準化された Keccak ベースのハッシュ関数ファミリー（SHA3-224、SHA3-256、SHA3-384、SHA3-512 と、拡張出力関数 SHAKE128、SHAKE256）で、Merkle–Damgård 構造ではなくスポンジ構造に基づいています。
SHA-256: SHA-2 ファミリー（FIPS 180-4）の 256 ビット版で、TLS、JWT、X.509、Bitcoin、ほとんどのファイル完全性チェックツールでデフォルトのハッシュです。衝突耐性は 128 ビット、原像耐性は 256 ビットです。
SHAKE128 と SHAKE256: Keccak スポンジから要求された任意の長さの出力を生成する、FIPS 202 の拡張出力関数（XOF）です。出力が十分に長ければ、安全性はそれぞれ 128 ビットと 256 ビットです。
SIGHASH フラグ: Bitcoin の署名の末尾に付加され、署名がトランザクションのどの部分を対象とするかを選ぶバイトです。ALL（0x01）、NONE（0x02）、SINGLE（0x03）があり、必要に応じて ANYONECANPAY（0x80）と組み合わせます。このほか、Taproot のデフォルトである 0x00 があります。
signature_algorithms 拡張: クライアントまたはサーバーが受け入れる署名方式（ecdsa_secp256r1_sha256、rsa_pss_rsae_sha256、ed25519 など）を列挙する TLS 拡張（13）です。証明書の署名については、signature_algorithms_cert（50）が別に扱います。
Sigstore: OIDC の ID に一時鍵を結び付ける証明書を発行し（Fulcio）、署名を公開ログに記録する（Rekor）オープンソースの署名サービスです。長期鍵なしでアーティファクトに署名し、検証できます。
SIWE（Sign-In with Ethereum）: Ethereum アカウントでログインするための ERC-4361 のメッセージ形式です。ドメイン、アドレス、URI、バージョン、チェーン ID、nonce、発行日時を含む人間が読めるテキストで、personal_sign で署名します。
SLH-DSA（FIPS 205）: SPHINCS+ から派生した FIPS 205（2024年8月）のステートレスなハッシュベースのデジタル署名アルゴリズムで、安全性はハッシュ関数だけに依存しますが、その代わりに署名が 7.8〜50 KB と大きく、署名処理も低速です。
SLSA（Supply-chain Levels for Software Artifacts）: ビルドとソースの完全性を段階的なレベルで定める OpenSSF のフレームワークで、現行の仕様は v1.2（2025年11月）です。たとえば Build L3 は、堅牢化され隔離されたビルドプラットフォームによって来歴が生成されることを意味します。
SNI（Server Name Indication）: クライアントが接続したいホストの名前を伝える TLS の拡張（RFC 6066 §3、拡張番号 0）で、これにより 1 つの IP アドレスで多数の証明書を使い分けられます。Encrypted Client Hello を使わない限り、平文で送信されます。
sntrup761x25519-sha512: Streamlined NTRU Prime の sntrup761 と X25519 を組み合わせ、SHA-512 でハッシュする SSH の鍵交換で、バージョン 9.0（2022年）から、10.0 で mlkem768x25519-sha256 に置き換えられるまで OpenSSH のデフォルトでした。
SPF の 10 回ルックアップ制限: SPF レコードの評価で発生させてよい DNS クエリを伴うメカニズムとモディファイア（include、a、mx、ptr、exists、redirect）を最大 10 個とする RFC 7208 の規則で、これを超えると結果は permerror になります。
SPF（Sender Policy Framework）: SMTP のエンベロープ（MAIL FROM または HELO）でドメインを使ってメールを送信してよいホストを列挙した、DNS で公開される RFC 7208 のポリシーで、受信者が接続元の IP アドレスと照合します。
SSH ホスト鍵: SSH サーバーが鍵交換のたびに署名に使う長期的な鍵ペアで、その公開鍵を known_hosts に記録したクライアントや、それを証明した CA を信頼するクライアントに対して、サーバーの身元を証明します。
SSH 証明書: OpenSSH 独自の署名付きステートメント（X.509 ではありません）で、認証局の鍵がユーザーまたはホストの公開鍵をプリンシパル、有効期間、オプションに結び付けます。これにより、個々の鍵を配布する必要がなくなります。
SSH（Secure Shell）: 認証され暗号化されたリモートログイン、コマンド実行、ファイル転送、ポートフォワーディングのための RFC 4251〜4254 のプロトコルで、サーバーはホスト鍵で自身を証明し、ユーザーは鍵、証明書、パスワードのいずれかで認証します。
SSHSIG（SSH 署名）: SSH 鍵で任意のデータに署名するための OpenSSH の形式（ssh-keygen -Y sign）で、署名ごとに名前空間を結び付けます。SSH で署名された Git コミットや、許可された署名者のリスト（allowed signers）による検証の基盤です。
STARTTLS: 既存の平文の接続を TLS に切り替えるプロトコルコマンドで、SMTP（RFC 3207）、IMAP、POP3、LDAP、XMPP で使われます。ポリシーで TLS を必須にしない限り、ダウングレードされるおそれがあります。
SubjectPublicKeyInfo（SPKI）: アルゴリズム識別子と公開鍵のビット列を組み合わせた RFC 5280 の ASN.1 構造で、すべての X.509 証明書の内部で使われるほか、公開鍵ファイルの標準形式（-----BEGIN PUBLIC KEY-----）でもあります。

T

Taproot: BIP-340、BIP-341、BIP-342 による Bitcoin のソフトフォークで、2021年11月14日にブロック 709,632 で有効化され、Schnorr 署名と、鍵と省略可能なスクリプトツリーにコミットする P2TR 出力を追加しました。
TLS 1.2: 2008年に策定された TLS のバージョン（RFC 5246）で、現在も広くサポートされています。AEAD 暗号スイートと SHA-256 を導入しましたが、2 往復を必要とし、TLS 1.3 で削除された脆弱なオプションも許容します。
TLS 1.3: TLS の現行バージョンで、2018年に RFC 8446 として公開され、2026年に RFC 9846 として改訂されました。1 往復のハンドシェイク、必須の前方秘匿性、AEAD のみの暗号スイート、暗号化されたハンドシェイクを備えています。
TLS セッション再開: 以前の接続のシークレットから TLS セッションを再確立することです。証明書による認証を省略して計算量を節約でき、TLS 1.3 では 0-RTT データを送ることもできます。
TLS ハンドシェイク: TLS 接続の最初に行われるやり取りで、クライアントとサーバーはパラメーターについて合意し、鍵交換を行い、認証（通常は証明書によるサーバーの認証）を行って、トラフィック鍵を導出します。
TLS 証明書圧縮: サーバーが証明書チェーンを zlib、brotli、zstd で圧縮できるようにする RFC 8879 の TLS 1.3 拡張（compress_certificate、27）で、通常はチェーンが 3 分の 1 以上小さくなります。
TLS（Transport Layer Security）: サーバー（および任意でクライアント）を認証し、両者の間のバイトストリームを暗号化する IETF のプロトコルで、HTTPS、メール、API をはじめ、その他ほとんどのインターネットプロトコルで使われています。現行バージョンは 1.3 です。
Trusted Publishing（信頼された公開）: 長期間有効な API トークンの代わりに、有効期間の短い OIDC ベースの認証情報を使って CI からレジストリにパッケージを公開する方式で、2023年4月に PyPI が導入し、npm（2025年7月に一般提供開始）、RubyGems、crates.io なども提供しています。
TUF（The Update Framework）: 2019年に CNCF の卒業プロジェクトとなった、安全なソフトウェア更新のための仕様で、署名をルート、ターゲット、スナップショット、タイムスタンプの各ロールに分け、しきい値と有効期限を設けることで、鍵が危殆化しても耐えられるようにしています。
typ（JOSE タイプヘッダー）: トークン全体のメディアタイプ（JWT、at+jwt、dpop+jwt、kb+jwt など）を宣言する JOSE ヘッダーのパラメーターで、明示的な型付けに使われ、ある種類のトークンを別の種類のトークンにすり替えられないようにします。

V

VMC（認証マーク証明書）: BIMI のためにドメインを登録商標のロゴに結び付ける X.509 証明書で、商標と身元の確認を経て発行され、SVG のロゴをロゴタイプ拡張に格納しています。

W

Web Bot Auth（署名によるボット認証）: HTTP メッセージ署名に基づく IETF の取り組みで、クローラーや AI エージェントなどの自動化されたクライアントが公開済みの鍵でリクエストに署名し、Web サイトが User-Agent 文字列や IP アドレスの範囲を信用する代わりに、それらを確実に識別できるようにします。
WebAuthn（Web 認証）: Web サイトが認証器上の公開鍵認証情報を登録して使用するための W3C のブラウザー API（publicKey オプションを指定した navigator.credentials.create と get）で、Level 3 は 2026年8月25日に W3C 勧告となりました。
WKD（Web Key Directory）: 自身のドメインの /.well-known/openpgpkey/ 以下で OpenPGP 鍵を公開する方式で、メールクライアントは HTTPS 経由でメールアドレスに対応する鍵を取得できます（draft-koch-openpgp-webkey-service）。

X

X.509: ITU-T が定めた証明書の形式で、インターネット向けには RFC 5280 でプロファイルされており、発行元の認証局の署名のもとで、公開鍵をサブジェクト名と拡張に結び付けます。
x5c（X.509 証明書チェーンヘッダー）: X.509 証明書チェーンを、base64 でエンコードした（base64url ではない）DER 証明書の配列として運ぶ JOSE ヘッダー兼 JWK のメンバーで、先頭の証明書が署名鍵を含みます。
X25519: RFC 7748 で定義された Curve25519 上のディフィー・ヘルマン関数で、鍵と共有秘密はいずれも 32 バイトです。TLS 1.3、SSH、WireGuard、Signal、age の鍵交換に使われています。
X25519MLKEM768: ML-KEM-768 と X25519 を組み合わせた TLS 1.3 のハイブリッド鍵交換グループ 0x11EC（RFC 10024）で、現在のブラウザー、OpenSSL、Go が既定で使うポスト量子方式です。
XAdES: XML に対する先進電子署名のための ETSI の形式（EN 319 132）で、XML-DSig を、署名時刻や証明書のダイジェストなどの署名付きプロパティと、B-T、B-LT、B-LTA の長期保存レベルで拡張しています。
XML 署名（XML-DSig）: XML に署名するための W3C 標準（XML Signature Syntax and Processing 1.1、2013年）で、ds:Signature 要素が署名対象のデータを URI で参照して正規化し、ダイジェストをまとめた SignedInfo ブロックに署名します。
XML 署名ラッピング（XSW）: XML 署名されたメッセージに対する攻撃の一種で、攻撃者が署名済みの要素を移動して偽造した要素を挿入します。その結果、署名は元の要素に対して検証に成功する一方、アプリケーションは偽造された要素を処理してしまいます。
XMSS と XMSS^MT: RFC 8391 と NIST SP 800-208 で規定された eXtended Merkle Signature Scheme は、WOTS+ のワンタイム鍵に基づくステートフルハッシュベース署名方式で、署名できる数を増やすマルチツリー版もあります。
xpub（拡張公開鍵）: 公開鍵とチェーンコードからなる BIP-32 の拡張公開鍵で、その下にある強化されていない子公開鍵とアドレスをすべて導出でき、ウォッチオンリーウォレットや決済サーバーで使われます。

ア

アクセストークン: OAuth クライアントがユーザーの代理として、またはクライアント自身として API を呼び出すときにリソースサーバーへ提示する認証情報で、イントロスペクションで確認する不透明な文字列か、自己完結型の JWT のいずれかです。
アテステーション（WebAuthn）: 登録時に認証器のアテステーション鍵で署名されるステートメントで、どの種類の認証器が認証情報を作成したかをリライングパーティに伝え、デバイスのポリシーを適用できるようにします。
アルゴリズム混同（鍵の混同）: ライブラリがトークンの alg ヘッダーにアルゴリズムを選ばせてしまうために、あるアルゴリズム用の鍵が別のアルゴリズムで使われる検証上の欠陥で、典型的には RSA 公開鍵が HS256 のシークレットとして使われます。

キ

キーバインディング（保有者バインディング）: クレデンシャルを提示する当事者が、そのクレデンシャルに記載された秘密鍵を管理していることの証明で、コピーされたクレデンシャルを他人がリプレイできないようにするものです。SD-JWT のキーバインディング JWT や mdoc のデバイス認証で実装されています。
キーレス署名: 署名者が OIDC の ID で認証して一時鍵用に数分間だけ有効な証明書を受け取り、長期間使う秘密鍵を保護する代わりに透明性ログに依拠する、Sigstore の署名モデルです。

ク

クリプトアジリティ: システムを再設計することなく、ネゴシエーション、設定、インベントリを通じて暗号アルゴリズム、鍵長、パラメーターを変更できる能力で、ポスト量子暗号への移行によって、ベストプラクティスから必須の要件になります。

グ

グローバーのアルゴリズム: Lov Grover が 1996年に発表した量子探索アルゴリズムで、N 個の中から目印の付いた要素を約 √N ステップで見つけます。そのため、共通鍵とハッシュの原像に対する実効的なビットセキュリティを下げる効果は、最大でも半分です。

コ

コード署名: 実行ファイル、パッケージ、スクリプト、ファームウェアに X.509 証明書、プラットフォームの鍵、OpenPGP、Sigstore を使って署名し、オペレーティングシステム、ストア、ユーザーが発行元を検証して改ざんを検出できるようにすることです。
コファクター: 楕円曲線上の点の個数と、暗号に使う部分群の素数位数 n との比 h = #E / n で、NIST の P 曲線と secp256k1 では 1、Curve25519 では 8、Curve448 では 4 です。

サ

サイドチャネル攻撃: 計算の入力や出力ではなく、物理的・時間的なふるまい（処理時間、キャッシュアクセス、消費電力、電磁放射、意図的に引き起こしたフォールトへの反応）から秘密情報を得る攻撃です。
サブジェクト代替名（SAN）: 証明書が有効な DNS 名、IP アドレス、メールアドレス、URI を列挙する X.509 の拡張（OID 2.5.29.17）で、ブラウザーがサーバーのホスト名を照合するときに使う唯一のフィールドです。

し

しきい値署名: 秘密鍵を n 者に分割し、そのうち任意の t 者が共同で、通常の署名と見分けのつかない 1 つの署名を作成でき、それより少ないグループは鍵について何の情報も得られない方式です。

シ

シャミアの秘密分散: Adi Shamir が 1979年に考案した方式で、ランダムな多項式で秘密を n 個のシェアに分割します。任意の k 個で秘密を復元でき、k − 1 個からは何の情報も得られません。
ショアのアルゴリズム: Peter Shor が 1994年に発表した量子アルゴリズムで、整数の素因数分解と離散対数の計算を多項式時間で行います。大規模な誤り耐性量子コンピューターがあれば、RSA、ディフィー・ヘルマン、ECDSA、EdDSA、ECDH を破ることができます。

セ

セキュリティレベル（ビットセキュリティ）: 暗号の強度を表す尺度で、s ビットとは、知られている最良の攻撃に約 2ˢ 回の演算が必要であることを意味します。AES-128、P-256、RSA-3072 のように、アルゴリズムをまたいで鍵長を比較するのに使われます。

ダ

ダイジェスト（メッセージダイジェスト）: データに暗号学的ハッシュ関数を適用して得られる固定長の出力で、そのデータのコンパクトで衝突耐性のある識別子として使われるほか、ほとんどの署名方式が実際に署名する入力でもあります。
ダウングレード保護: 強いプロトコルバージョンやアルゴリズムに対応している二者を、攻撃者がより弱いものへ切り替えさせることを防ぐ仕組みで、ServerHello.random に入る TLS 1.3 のセンチネル値などがあります。

デ

デジタル署名: メッセージから秘密鍵を使って計算される値で、対応する公開鍵を持つ人なら誰でも検証できます。メッセージが改ざんされていないことと、鍵の保有者が署名したことを証明します。

ド

ドメイン認証（DV）: 証明書の認証レベルの 1 つで、CA は DNS、HTTP、TLS-ALPN のチャレンジによって、申請者が証明書内のドメイン名を管理していることだけを確認し、組織については何も確認しません。

ト

トラステッドタイムスタンプ（RFC 3161）: データのハッシュを信頼できる時刻に結び付ける署名付きトークンをタイムスタンプ局（TSA）から取得し、署名が証明書の期限切れや失効より前に作成されたことを示せるようにすることです。

ハ

ハードウェアウォレット: ウォレットの鍵をセキュアエレメントや隔離されたマイクロコントローラーに保管し、トランザクションの詳細を自身の画面に表示して、物理的な確認を経てから初めて署名する専用デバイスです。
ハイブリッド鍵交換: X25519 などの古典的なアルゴリズムと ML-KEM などのポスト量子 KEM を組み合わせた鍵交換で、どちらか一方の構成要素が破られていない限り、セッションの秘密が保たれます。
ハッシュベース署名: 安全性がハッシュ関数の性質だけに依存する署名方式で、ワンタイム署名とマークルツリーから構成されます。ステートフルな LMS と XMSS（SP 800-208）、ステートレスな SLH-DSA（FIPS 205）があります。

パ

パスキー: 1 つの Web サイトまたはアプリに結び付けられ、デバイスの生体認証、PIN、またはパスワードでロックを解除する鍵ペアである FIDO2/WebAuthn の検出可能な認証情報で、パスワードをフィッシング耐性のある署名に置き換えます。
パスワード: ユーザーが記憶し、サーバーが確認する秘密の文字列で、最も一般的かつ最もフィッシングに弱い認証器です。NIST SP 800-63B-4 は、複雑さではなく、長さ、ブロックリスト、保存方法の規則によってこれを規定しています。
パスワードのハッシュ化: 意図的に低速で、ソルトを付けた、できればメモリハードな関数（Argon2id、scrypt、bcrypt、PBKDF2 など）の出力としてパスワードを保存する方法で、データベースが盗まれてもオフラインでの推測に耐えられるようにします。

ビ

ビルドの来歴（build provenance）: アーティファクトがどのように作られたか（ソースリポジトリとコミット、ビルドプラットフォーム、ワークフロー、入力）を示す、署名付きで検証可能な記録で、利用者はこれによって、パッケージが想定どおりのソースとパイプラインから作られたことを確認できます。

フ

フィッシング耐性: 認証方式の特性の 1 つで、本物に似せたサイトが認証情報を取得してリプレイできないことを指します。WebAuthn やクライアント証明書による TLS のように、認証器が自身のレスポンスを暗号的に本物のオリジンに結び付けることで実現されます。

ブ

ブラインド署名（blind signing）: 署名デバイスが意味を表示できない（通常はハッシュや生の calldata しか示されない）トランザクションやメッセージを承認することで、署名者はそれを用意したコンピューターを、乗っ取られているおそれがあっても信頼するしかありません。

ベ

ベアラートークン: 鍵の所有証明なしに、提示した者であれば誰にでもアクセスを許可するアクセストークン（RFC 6750）で、通常は Authorization: Bearer の後にトークンを続けて送信します。
ベースライン要件（Baseline Requirements、BR）: 公的に信頼される TLS サーバー証明書の発行と管理について CA/Browser Forum が定めた規則で、検証方法、証明書プロファイル、有効期間、失効、CA の運用を対象とします。

ヘ

ヘッジ付き署名（hedged signatures）: 署名ごとの nonce を、秘密鍵とメッセージに新しい乱数を加えて導出する署名方法で、乱数生成器と決定的な導出のどちらか一方が攻撃されても方式の安全性が保たれます。

ポ

ポスト量子暗号（PQC）: 大規模な量子コンピューターに対しても安全性を保つよう設計された公開鍵アルゴリズムで、ML-KEM、ML-DSA、SLH-DSA（FIPS 203〜205、2024年）などがあり、RSA、Diffie–Hellman、楕円曲線の方式を置き換えます。

マ

マークルツリー: 各内部ノードが 2 つの子のハッシュを計算する二分ハッシュ木で、1 つのルートハッシュがすべてのリーフに対するコミットメントになるため、要素が含まれていることや追記のみで成長していることを対数サイズの証明で示せます。
マークルツリー証明書（MTC）: IETF で標準化が進められている証明書の設計で、CA が発行のたびにマークルツリーに記録し、クライアントは大きなポスト量子署名の代わりに短い包含証明を確認します。

ユ

ユーザー検証（UV）: 許可されたユーザーがその場にいて本人であることを、認証器が生体認証、PIN、デバイスのパスワードのいずれかでローカルに確認する仕組みで、結果は WebAuthn の認証器データの UV フラグで示されます。

ル

ルート CA（ルート証明書）: 検証者のルートストアに収録されているため直接信頼される自己署名の CA 証明書で、すべての証明書パスが最終的に行き着かなければならないアンカーとなります。
ルートストア（トラストストア）: オペレーティングシステム、ブラウザー、ランタイムが証明書パス検証のアンカーとして信頼するルート CA 証明書の集合で、独自のポリシーを持つルートプログラムによって管理されます。

ワ

ワイルドカード証明書: *.example.com のようなサブジェクト代替名を持つ証明書で、その位置にある任意の 1 つのラベルに一致します。たとえば www.example.com には一致しますが、example.com や a.b.example.com には一致しません。

暗

暗号スイート: TLS 接続で使う暗号アルゴリズムの組み合わせに名前を付けたものです。TLS 1.3 の名前が示すのは AEAD とハンドシェイクのハッシュだけ（例：TLS_AES_128_GCM_SHA256）ですが、TLS 1.2 の名前は鍵交換と認証の方式も固定していました。
暗号学的ハッシュ関数: 任意の長さの入力を固定長のダイジェストに写像する関数で、原像、第二原像、衝突のいずれを見つけることも計算量的に困難なものです。

一

一括送信者の要件（Gmail、Yahoo、Microsoft）: Gmail と Yahoo（2024年2月から）、Microsoft（2025年5月から）が、1 日に約 5,000 通を超えるメールを送る送信者に課している規則で、SPF、DKIM、アライメントの取れた DMARC レコード、ワンクリックでの配信停止が求められます。

隠

隠れ数問題: 秘密値の数ビットを明かすノイズを含んだ多数の線形関係から、その秘密値を復元する格子の問題で、ECDSA や DSA の nonce のわずかな偏りや漏洩を、秘密鍵の完全な復元に結び付けます。

拡

拡張鍵用途（EKU）: 証明書の鍵を使用できるアプリケーション上の用途を列挙する X.509 拡張（OID 2.5.29.37）で、id-kp-serverAuth、id-kp-clientAuth、id-kp-codeSigning、id-kp-emailProtection などがあります。

格

格子暗号: LWE（Learning With Errors）問題や SIS（Short Integer Solution）問題など、高次元の格子上の困難な問題に基づく暗号で、ML-KEM、ML-DSA、FN-DSA の基盤です。

基

基本制約（basicConstraints）: 証明書が他の証明書への署名を許された CA のものかどうかを cA フラグで示す X.509 の証明書拡張（OID 2.5.29.19）で、任意の pathLenConstraint によって、その下に続けられる CA の数を制限できます。

検

検出可能な認証情報（レジデントキー）: 秘密鍵とユーザーハンドルが認証器に保存される WebAuthn の認証情報で、サーバーが先に認証情報 ID を送らなくても見つけられるため、ユーザー名を入力しないパスキーのログインが可能になります。
検証可能なクレデンシャル: 発行者が署名し、サブジェクトがウォレットに保持する、改ざんを検知できるサブジェクトについてのクレームの集合で、検証者は発行者に問い合わせることなく確認できます。複数の形式（W3C VC、SD-JWT VC、mdoc）で標準化されています。

鍵

鍵のローテーション: 定期的に、またはインシデントの後に、暗号鍵を新しい鍵に置き換えることです。切り替えの間も検証が機能し続けるよう、通常は新旧の鍵を並べて公開します。
鍵ペア: 単一の非対称アルゴリズム用にまとめて生成される、数学的に結び付いた秘密鍵と公開鍵の組で、理想的には署名や鍵共有など単一の用途に使います。
鍵または証明書のフィンガープリント: 公開鍵や証明書の短いハッシュ値で、目視や設定の中でそれを識別・比較するために使われます。SSH 鍵の SHA256:… や、証明書の DER バイト列の SHA-256 などがあります。
鍵交換（鍵確立）: 2 者が安全でない通信路を介して共有秘密を得るプロトコル上の手順で、Diffie–Hellman 鍵共有または鍵カプセル化によって行い、得られた共有秘密からセッション鍵を導出します。
鍵用途（keyUsage）拡張: 証明書の鍵で行える操作をビットで制限する X.509 拡張（OID 2.5.29.15）で、digitalSignature、contentCommitment、keyEncipherment、keyAgreement、keyCertSign、cRLSign などのビットがあります。

公

公開鍵: 非対称鍵ペアのうち自由に共有できる側の鍵で、署名の検証、対応する秘密鍵の保有者に向けた暗号化、またはその保有者との鍵共有に使われます。

事

事前ハッシュ署名（HashEdDSA、HashML-DSA）: メッセージそのものではなくそのダイジェストに署名する方式で、暗黙的に行うもの（ECDSA、RSA）と、Ed25519ph や HashML-DSA のように明示的に分離され、ドメイン分離されたバリアントで行うものがあります。

自

自己署名証明書: 発行者とサブジェクトが同一で、自身の秘密鍵で署名された証明書です。そのため、トラストアンカーとしてインストールされた環境でのみ信頼されます。

識

識別名（DN）: 証明書のサブジェクトと発行者を表す X.500 の階層的な名前で、CN、O、OU、L、ST、C などの属性と値の組で構成され、発行者とサブジェクトの照合でチェーンをつなぎます。

弱

弱い鍵: 欠陥のある鍵生成器、不十分なエントロピー、構造上の欠陥、複数のデバイスでの使い回しのいずれかが原因で、公称の鍵長から想定されるより容易に破られる鍵です。

署

署名の展性: 署名方式またはそのエンコーディングが持つ性質で、秘密鍵を知らなくても、誰でも有効な署名を、同じメッセージと鍵に対する別の有効な署名に変換できるというものです。
署名検証: 検証者があらかじめ選んだアルゴリズムを使い、署名がまさにこのメッセージに対して、与えられた公開鍵に対応する秘密鍵で生成されたことを公開鍵で確認する処理です。

証

証明書（公開鍵証明書）: 特定の公開鍵が、名前で示されたサブジェクトに属することを発行者が署名して示す宣言で、限られた期間と明記された用途に対してのみ有効であり、多くは X.509 形式です。
証明書チェーン: エンドエンティティ証明書（リーフ証明書）から 1 つ以上の中間 CA 証明書を経て信頼されたルートに至る、順序付けられた証明書の並びで、各証明書は次の証明書によって署名されています。
証明書のシリアル番号: 証明書のシリアル番号は、発行者ごとに一意で最大 20 オクテットの正の整数です。CRL、OCSP リクエスト、インシデント報告で、個々の証明書を識別するために使われます。
証明書の有効期間: 証明書の notBefore から notAfter までの期間（両端を含む）です。公的に信頼される TLS 証明書の上限は 2026年3月15日以降 200 日で、2027年に 100 日、2029年に 47 日へと短縮されます。
証明書パス検証: トラストアンカーからエンドエンティティ証明書までのチェーンが有効かどうかを判定する RFC 5280 §6 のアルゴリズムで、署名、有効期間、名前、制約、ポリシー、失効を確認します。
証明書または公開鍵のピンニング: 通常のチェーン検証に加えて、CA の鍵、中間証明書、またはサーバー自身の鍵のハッシュ値を照合することで、クライアントがホストに対して受け入れる証明書や公開鍵を固定のセットに限定することです。

伸

伸長攻撃（length-extension attack）: MD5、SHA-1、SHA-256、SHA-512 などの Merkle–Damgård 構造のハッシュに対する攻撃で、秘密を知らなくても、H(秘密 ‖ m) と「秘密 ‖ m」の長さから H(秘密 ‖ m ‖ パディング ‖ m′) を計算します。

信

信頼の輪（Web of Trust）: 認証局に頼る代わりに、ユーザー同士が互いの鍵を証明し、各ユーザーが証明者をどこまで信頼するかを自ら決める、OpenPGP の分散型の信頼モデルです。

正

正規化（canonicalization）: ハッシュ化や署名の前に、データを取り決めた 1 つのバイト表現に変換する処理で、意味が同じ入力（空白、キーの順序、名前空間プレフィックス、ヘッダーの折り返しだけが異なるもの）から同じ署名入力が得られるようにします。

生

生の r‖s 署名形式（IEEE P1363）: ECDSA または DSA の署名を、r と s をそれぞれ群の位数のバイト長まで先頭側をパディングして連結した固定長のエンコーディングで、JOSE、COSE、WebCrypto、多くの HSM の API で使われています。

前

前方秘匿性: サーバーの証明書の鍵などの長期鍵が危殆化しても過去のセッションが暴露されないという性質で、各セッションの鍵を、使用後に破棄される一時的な鍵交換の値から導出することで実現します。

組

組織認証（OV）: 証明書の認証レベルの 1 つで、CA はドメインの管理に加えて、申請組織の法的な実在性、名称、所在地を確認し、それらを証明書のサブジェクトに記載します。

楕

楕円曲線: 有限体上で y² = x³ + ax + b のような三次方程式を満たす点の集合で、点の加算則によって、ECDSA、EdDSA、ECDH が使う群を構成します。

短

短期証明書（short-lived certificate）: 有効期間が非常に短いため、失効確認に頼らずにそのまま期限切れになる証明書です。公的な TLS 証明書の場合、2026年3月15日以降に発行されたものでは有効期間が最長 7 日のものを指します。

中

中間 CA（中間認証局）: ルートや別の中間 CA が署名した CA 証明書で、その鍵がエンドエンティティ証明書を発行するため、ルートの鍵をオフラインに保てます。

点

点圧縮（point compression）: 楕円曲線上の点を、両方の座標ではなく x 座標と y の 1 ビットで表すエンコード方法で、デコード時に平方根の計算が必要になる代わりに、公開鍵のサイズをほぼ半分にできます。

認

認証器（FIDO/WebAuthn）: WebAuthn の認証情報を保持して署名を生成するコンポーネントで、デバイスに組み込まれたプラットフォーム認証器、持ち運べるローミング型のセキュリティキー、パスキーを同期する認証情報マネージャーがあります。
認証器データ: すべての WebAuthn レスポンスに含まれるバイナリ構造で、RP ID の 32 バイトの SHA-256 ハッシュ、1 バイトのフラグ、4 バイトの署名カウンターに加え、任意でアテステーション済み認証情報データと CBOR の拡張出力を含みます。

秘

秘密鍵: 非対称鍵ペアのうち秘密にしておく側の鍵で、署名、復号、鍵共有に使われ、これを保持する者は誰でもその所有者として振る舞えるため、保護されていない状態で信頼境界の外に出してはいけません。

複

複合署名: ポスト量子アルゴリズムと従来型のアルゴリズムを 1 つの鍵と 1 つのアルゴリズム識別子のもとで組み合わせた署名（例：ML-DSA-65 と ECDSA P-256）で、両方の構成要素の検証が成功した場合にのみ署名の検証が成功します。

分

分離署名（detached signature）: 署名対象のデータとは別に保存される署名で（OpenPGP の .sig や .asc ファイル、SSHSIG ファイル、カプセル化されたコンテンツを含まない CMS 署名など）、元のファイルは変更されないまま残ります。

無

無効曲線攻撃: 合意した曲線上にない点を通信相手が送る攻撃で、点の検証を省いた実装はより弱い曲線上で計算を行い、秘密鍵を少しずつ漏洩させてしまいます。

名

名前制約（nameConstraints）: CA 証明書にのみ使用が認められる X.509 拡張（OID 2.5.29.30）で、DNS 名、IP アドレスの範囲、メールドメイン、ディレクトリ名の許可サブツリーと除外サブツリーによって、下位の証明書に含められる名前を制限します。

#

0-RTT（TLS 早期データ）: セッションを再開するクライアントが、以前のセッションの鍵で暗号化したアプリケーションデータを最初のフライトで送れるようにする TLS 1.3 の機能です。その代わり、そのデータについてはリプレイ保護と前方秘匿性が失われます。