要約

  • RFC 9688 では digest、ECDSA、HMAC、HKDF の parameters は不在、RSA PKCS#1 v1.5-with-SHA3 は NULL 必須、KMAC は customization の有無と exact byte によって形が変わる。
  • parser の受理、正しい OID、署名成功は、それぞれ受信 byte の保存、正しい branch の実行、certificate policy、権限、application outcome とは別の receipt である。

移行テストで ECDSA の object は通り、RSA の object だけが落ちたとする。両方の dashboard は SHA3-256 と表示する。原因は hash でも key size でもない。新しい serializer がすべての NULL を削除したため、ECDSA は正しいまま、RSA は RFC 9688 の必須形を失った。

これは named product の実事故を主張する話ではない。重要なのは、family 名から wire contract を推定できないことだ。証拠は CMS field、OID、parameter state、nested identifier、受信 encoding、key、実装、policy、そして downstream decision を別々に保持しなければならない。

不在は空値ではない

SHA3-224、256、384、512 を digest として使うとき、parameters field は不在でなければならない。ASN.1 NULL を置くことは「何も指定していない」の別表現ではない。

ECDSA-with-SHA3、HMAC-with-SHA3、HKDF-with-SHA3 も不在を要求する。古い互換性規則を流用し、すべての AlgorithmIdentifier に NULL を補う encoder は、correct OID のまま wrong object を作る。

RSA PKCS#1 v1.5-with-SHA3 は逆である。該当する signature identifier と rsaEncryption では NULL が必要だ。見た目を統一するために削除する処理は、意味のない装飾を消すのではなく、要求された state を消す。

KMAC128-KDF と KMAC256-KDF は第三の規則を持つ。customization S がなければ parameters は不在、S があれば OCTET STRING として exact value を載せる。不在と present empty string を一つの default に畳む UI は provenance を消す。

OID だけでは KDF を再現できない

KMAC の input は K, X, L, S である。K は KEM Decap の output になりうる。RFC 9629 と組み合わせる X には CMSORIforKEMOtherInfo の DER が入る。L は output bit length、S は domain separation の customization である。

id-kmac128 という log だけでは derived key を再計算できない。parameter を保存しても X と L がなければ不十分だ。両 endpoint が同じ OID を支持していても、context byte が違えば同じ key にはならない。

KDF2/KDF3 は parameters 内に digest identifier を入れる。その inner identifier が SHA3 なら、そこでも parameters 不在という規則が適用される。outer OID の検査だけでは nested contract を確認していない。

decode と preserve を分ける

parser は複数の encoding を同じ内部 object に写像できる。その後に再 encode すれば、receiver の好む形が sender の形を上書きする。したがって parse success は fidelity receipt ではない。

必要なのは、受信 CMS byte の hash、field path、OID、parameter state と byte hash、nested identifier、parser version、normalization の有無、crypto provider、key reference、operation result を保持することだ。certificate path、key purpose、authorization、application result はさらに別の receipt にする。

signature success は selected byte と signature と public key の関係を証明する。しかし signer が当該判断をする権限、object の freshness、content の business meaning、処理の完了までは証明しない。

registry と running code

IANA assignment は独立実装に共通の座標を与える。それは installed implementation の conformance report ではない。registry entry は unique name を証明し、captured byte と vector は implementation behavior を証明し、application が outcome を証明する。

この separation は bureaucracy を増やすためではない。symbolic support が operational proof に昇格するのを防ぐためである。

出典