要約

  • RFC 9864は、追加情報なしで暗号処理を決定できる「完全指定」と、曲線などを別に必要とする「多態的」識別子を分け、Ed25519、Ed448、曲線込みのCOSE ECDSA名を登録する。
  • 完全な名前は発見と許可リストを改善する。しかし、レジストリ、広告、鍵、実行設定、検証方針、結果は別々の証拠である。

WebAuthnが足した一行

OAuthメタデータ、OpenID Connect Discovery、WebAuthn、CTAPは、アルゴリズム一覧を能力交渉に使う。ところが EdDSA は曲線を含まず、COSE ES256 はSHA-256を示しても曲線を示さなかった。同じ文字列が双方にあっても、共通処理があるとは断定できない。

WebAuthnはCOSE値 -8 を曲線 6 のEd25519に限定した。この一行で交渉は決定的になったが、一般レジストリより狭い意味をローカルに作り、Ed448を同じ値から外した。運用できた理由は、元の名前に情報が十分だったからではなく、不足分をプロファイルが補ったからである。

選択を識別子へ戻す

RFC 9864はJOSE/COSEに Ed25519 と Ed448 を置き、COSE値を -19 と -53 にする。COSE ECDSAでは ESP256 がP-256/SHA-256、ESP384 がP-384/SHA-384、ESP512 がP-521/SHA-512を指す。Brainpoolの組合せも分離される。

鍵表現は基本的に変わらない。RFC 8037のEd25519鍵はそのまま使え、alg があれば EdDSA ではなく Ed25519 と書ける。能力広告、鍵の意図、検証器の許可表が一つの完全な操作名で結ばれる。今後のJOSE/COSE登録も完全指定だけを認め、多態的な新規名を認めない。

非推奨と禁止の間

RFCはJOSEの EdDSA、COSEの ES256、ES384、ES512、EdDSA を非推奨にする。ただし非推奨は、代替があり新規導入では原則そちらを使うという意味で、文書化された運用・規制上の事情があれば移行できない場合を残す。禁止は使用そのものを認めない。

古い署名を読む必要、更新の遅い認証器、保存義務はレジストリ更新だけでは消えない。早すぎる削除は障害になり、期限のない旧形式発行は曖昧さを固定する。発行停止と読取り停止は別の日付、別の責任者、別の証拠を必要とする。

残された多態性

RSAは鍵長別の新識別子を得ない。ECDHは曲線とKDFを含む将来形が説明されるだけで、置換登録はない。COSE HSS-LMSもハッシュを名前に含まないまま残る。代替のない多態的暗号方式もこのRFCでは非推奨にされない。

従って「JOSE/COSE移行済み」という一括判定はできない。置換済み、元から完全、未解決、プロトコル限定、期限付き例外を分けなければ、新しい表示が古い推測を覆い隠す。

名前の証明範囲

完全指定名は、一つの曲線・ハッシュ操作を指すことを証明できる。RFCは同じ鍵を原則一つのアルゴリズムにだけ使い、別の拘束手段がなければJWK/COSE Keyにアルゴリズムを持たせることも勧める。

しかし、コードが存在して有効か、HSMが許可するか、鍵が正しいか、検証器が受け入れるか、アプリが処理を承認するかは別である。登録、広告、鍵拘束、実行設定、観測された交渉、暗号結果、業務判断を一つの「対応」に圧縮してはならない。

情報源