要約

  • 11月2日の第07版は、9月30日の第06版になかった条件を追加した。信頼できるルートにつながっていても、別の理由で退けた経路に結びつくアンカーIDは、再試行で選ぶべきではない（SHOULD NOT）。
  • 例として期限切れ、失効、名前の不一致、クライアントがそのアンカーに課した制約を挙げる。
  • 別の適格なIDまで排除する規則ではない。接続試行ごとの再試行は最大一回とされる。

誰が署名したかと、通してよいか

サーバーが複数の証明書経路を持つ場合、クライアントの知る信頼アンカーに合わせて経路を選びたい。選択が外れたときは、サーバーがEncryptedExtensionsで示したIDから一つを選び、同じ接続先へ新たな接続を張る。第07版の第5.6節はこの回復手順に新しい歯止めを置いた。第06版には再試行と一回の上限があったが、この歯止めはなかった。

信頼されたルートまで経路が続いても、証明書そのものの有効期限、失効状態、対象名は別に判定される。最初の経路がそこではねられたのに、その経路のアンカーIDを再び要求すれば、回復手順が拒否理由を忘れたことになる。第07版はそのIDを選ぶべきではないと明記する。サーバーが別のIDを示し、クライアントにとって適格なら、サーバーの優先順位とローカルの判断で選べる。候補がなければエラーをアプリケーションへ返す。

IETFの記録では、これはまだ作業部会のInternet-Draftで、状態はI-D Existsだ。確認した原文は実運用で不正な証明書を受け入れた事例を示していない。争点は設計上の権限だ。ルートを知っていることは、その経路で提示された身分証を合格にする決定ではない。