要約

  • RFC 9598 は、非 ASCII 文字を含むローカル部を X.509 otherName の SmtpUTF8Mailbox に格納する。ローカル部が ASCII だけなら、国際化ドメインであっても rfc822Name を使う。
  • ドメインは IDNA2008 に従って小文字の A-label に変換するが、UTF-8 ローカル部にはケースフォールドも Unicode 正規化も行わない。ドメイン準備後はメールボックス全体をオクテット単位で比較する。
  • 名前の一致は限定された比較の記録にすぎない。経路検証、名前制約、用途、メールボックス支配、SMTPUTF8 到達性、ローカル認可、実際の結果には別々の証拠が要る。

運用センターに「証明書メールアドレス：一致」という表示があるとする。緑なら入場、赤なら拒否。障害対応者が見られるのはその一色だけだ。証明書がどの GeneralName を含んだのか、入力ドメインがどう変換されたのか、ローカル部のバイトが保存されたのか、どの信頼経路が選ばれたのかは見えない。

この単純化は、国際化メールアドレスでは特に危険になる。画面上では同じローカル部でも、UTF-8 のバイト列が異なることがある。一方、ドメインには Unicode 表示から DNS 用の形式へ変換する明示的な契約がある。両者を一つの「文字列正規化」に渡せば、依存側アプリケーションが署名済み主体を書き換えることになる。

RFC 9598 が採用したのは、便利な統一ではなく、権限に沿った非対称性である。@ の右側だけを規定どおりに準備し、左側には触れない。比較器がどこまで処理できるかより、どこで処理を止めなければならないかが中心となる。

表示は一つでも、証明書表現は二つある

RFC Editor の記録と IETF Datatrackerによれば、RFC 9598 は 2024 年 5 月の Proposed Standard である。RFC 5280を更新し、先行する RFC 8398を廃止した。

従来の rfc822Name が格納できるメールボックスは ASCII 形式に限られる。そこで RFC 9598 は、X.509 GeneralName の拡張可能な otherName を使い、SmtpUTF8Mailbox を定義する。その OID は 1.3.6.1.5.5.7.8.9 で、IANA SMI Numbers レジストリにも登録されている。

表現の選択を決めるのはドメインではなく、ローカル部である。非 ASCII 文字が一つでもあれば SmtpUTF8Mailbox、ASCII だけなら rfc822Name を使う。後者はドメインが国際化されていても変わらない。つまり、一つのメールボックス名前空間を、ローカル部の性質に応じた二つの相互排他的な形式が担う。

この区分は移行時の細部ではない。rfc822Name だけを検索する資産台帳は国際化ローカル部を見落とす。ASCII ローカル部を SmtpUTF8Mailbox に入れる発行系は相互運用契約から外れる。読み取り後に二つの形式を共通オブジェクトへ潰し、元のタグを捨てる検証基盤は、証明書が実際に示した証拠を失う。

値は表示名付きアドレスではなく、エンベロープ・メールボックスである。フレーズ、コメント、山括弧は含まれない。SmtpUTF8Mailbox は空でない ASN.1 UTF8String であり、UTF-8 表現に BOM を含めてはならない。文字エンコーディングの境界は RFC 3629、国際化メッセージヘッダーの文脈は RFC 6532にある。

ドメイン変換には、割り当てられた権限がある

ドメイン側は IDNA2008 に従う。RFC 5890が A-label、U-label、LDH の語彙を定め、RFC 5891がプロトコル変換を定める。RFC 9598 は、X.509 メールアドレス内のすべてのドメインに IDNA2008 適合を求め、枠組みで議論された追加マッピングに依存しない。

SmtpUTF8Mailbox の非 ASCII ドメインラベルは U-label ではなく A-label として格納する。ASCII ラベルは NR-LDH 制約を満たし、A-label と NR-LDH の文字はすべて小文字となる。証明書側が一つの比較形を持つため、経路検証器がいったん Unicode 表示へ戻し、別の推測をする必要はない。

外部入力を証明書値と比べる場合、準備は限定的である。表示用フレーズ、コメント、山括弧を除き、ドメインの U-label を A-label に変換し、該当するドメイン文字を小文字にする。そして止める。この処理はメールボックス全体を美しく整える一般許可ではなく、ドメインについて明記された比較手続きである。

RFC 8398 からの主要な修正も、この一貫性にある。旧仕様は条件により A-label と U-label を使い分けた。RFC 9598 は証明書内を常に A-label にする。発行者や依存側が直ちに更新されたことまでは証明しないが、生成物をテスト可能にし、画面の見た目から推論する必要を減らす。

ローカル部を変換しないことが、比較の仕様である

ローカル部は RFC 6530の国際化メール枠組みと、RFC 6531の SMTP 拡張に由来する。UTF-8 で表現されるが、UTF-8 は符号化方式であって、すべてのメール事業者に共通するメールボックス等価性規則ではない。

RFC 9598 はローカル部の変換を禁じる。ケースフォールドをしない。Unicode 正規化をしない。互換文字へのマッピングもしない。ドメインだけを準備した後、メールボックス全体をオクテット単位で比較する。すでに符号化済みの二つの SmtpUTF8Mailbox なら準備さえ不要で、完全なバイト一致だけが等価性を示す。

SmtpUTF8Mailbox と rfc822Name は常に不一致になる。前者には非 ASCII ローカル部が必要で、後者にはそれを格納できないからである。検証器が一方を他方へ変換して「意味は同じ」と判断すれば、仕様にない同一性を新たに作る。

人間に同じ文字列と見える二つの値を拒否することは、使い勝手上の摩擦を生む。しかし、ローカル Unicode ライブラリが発行後の証明書主体を再定義するより安全である。検索用の正規化、表示用の合成、サポート用の近似候補は有用でも、署名済み同一性の関数にはならない。発行系とメールボックス台帳のバイトが違えば、修復すべきは発行または台帳であり、比較器が両者を融合してはならない。

名前制約は CA を縛るが、メールボックスを支配しない

rfc822Name と SmtpUTF8Mailbox は同じメールアドレス名前空間を表す。既存の下位 CA が rfc822Name の名前制約によって一つのドメインへ限定されているなら、新しい otherName を抜け道にはできない。

RFC 9549は PKIX の国際化規則を更新し、rfc822Name 制約が両形式を覆うようにした。CA 証明書は IDNA2008 に適合する A-label 形式の rfc822Name でメール制約を表す。主体側のドメインを準備し、ローカル部を外して、完全ホストまたはドメイン接尾辞を比較する。特定の一メールボックスを対象にした制約は使うべきではない。

この成功が示すのは、下位 CA の発行可能な名前空間に対象ドメインが入るということだけだ。メールボックスが存在すること、主体が現在も支配すること、鍵が要求操作に適すること、アプリケーションがアクセスを許可すべきことは示さない。

したがって監査記録では、少なくとも四つの命題を別々にする必要がある。証明書は期待する GeneralName 形式と正確なバイトを含んだ。メールボックス比較は RFC 9598 に従って成功した。証明書経路と名前制約は採用した信頼方針に従って成功した。アプリケーションはこの用途に証明書を受け入れた。四つが成立しても、SMTPUTF8 経路でメッセージが届くとは限らない。

緑色ランプの外側に、実際の制御面がある

SMTPUTF8 は別の運用面である。RFC 6531 により SMTP ノードは国際化エンベロープアドレスを通告し、利用できる。証明書名が一致しても次のリレーが SMTPUTF8 に対応しないことがある。一方、対応経路で配送が成功しても RFC 9598 証明書が提示されたとは限らない。

認可も別である。依存側には信頼アンカー、構築された経路、ポリシー、鍵用途または拡張鍵用途、失効状態、アプリケーション結合、現在の権限規則が要る。署名が正しくても操作は禁止され得る。メールが受理されても読まれたとは限らない。ログインが成功しても、その後の変更が成功したとは限らない。

Lu Heng の動くコードを第一に置く議論を当てはめれば、「RFC 9598 対応」は実績ではない。実績とは、証明書のバイト、パーサー出力、外部ドメインの準備、保存されたローカル部、比較、経路、制約、方針判断、操作、効果を結べるトレースである。

最小の初期仕様という視点は、この RFC の狭さを長所として読む。共通化するのは名前形式、ドメイン表現、比較手続きであり、メールボックス発行、CA の証拠、アプリケーション権限、輸送運用まで中央集権化しない。現実の層という視点では、表現された名前、照合された名前、有効な証明書、支配されたメールボックス、許可された操作、観測された結果は結合可能な別レコードである。

リーダーが求めるべきなのは、緑色の数を増やすことではない。各ランプが何を証明し、何について沈黙しているかを残すことである。

出典