OCSP Must-Staple と OCSP Multi-Stapling、及び OneCRL

OCSP Must-Staple

2016 年 3 月 8 日にリリース予定の FireFox 45 では、"OCSP Must-Staple" がサポートされるようです。
"OCSP Must-Staple" は、2015 年 11 月 23 日の Mozilla Security Blog "Improving Revocation: OCSP Must-Staple and Short-lived Certificates" にも記載があるように、RFC7633 "X.509v3 Transport Layer Security (TLS) Feature Extension" を利用しています。ちなみに、RFC7633 中には、"Must-Staple" という単語は全く出てきません。Draft 時には、"muststaple"　という記載もあったようですが、より汎用的に利用できるよう "TLS Feature Extension" として規定されたようです（更にですが、"OCSP Stapling" は -ing がついていますが、"Must-Stale" は、-ing がつかない記載が一般的なようです）。

さて、その "OCSP Must-Staple" ですが、名称からは、"OCSP Stapling" が "must" になった印象を受けます。

大本の "OCSP Stapling" ("must" 無し)は、RFC6066 "Transport Layer Security (TLS) Extensions: Extension Definitions" で規定されています。
Web サーバーの SSL/TLS 証明書の状態（失効情報）を"ブラウザ"から認証局にオンラインで個別に問合せて取得するのが OCSP （オンライン証明書状態プロトコル）ですが、"OCSP Stapling" では、ブラウザの代わりに、"Webサーバー" が、認証局に問合せて OCSP レスポンス（SSL/TLS 証明書の有効・無効等の状態）を取得・保持しておき、ブラウザが Web サーバーに TLS 接続してきた際に、その接続のやり取り（TLS ハンドシェイク）の中に、OCSP レスポンスの情報も "stapling"（ホチキス止め）して、一緒に渡します。これによりブラウザは、Webサーバーと、認証局の OCSP の 2 か所ではなく、Webサーバー 1 か所にアクセスするだけで、失効情報も含めて、全情報が効率的に取得でき、TLS 接続がスピードアップする、というものです。なお、"OCSP Stapling" は、一般的な SSL/TLS 証明書と、Web サーバーの OCSP Stapling の設定で実現できます。

ようやく、"OCSP Must-Staple" について、としたいところですが、もう 1 点。
実はブラウザは、失効情報が確認できなかった時の挙動として、多くが "soft-fail" を採用しています。ブラウザが CRL や OCSP レスポンダから失効情報を取得するのに時間を要し、またはタイムアウトした際、ブラウザは、その証明書が、「有効」であるとも「失効されている」とも判別がつかない状態になります。この時、積極的に Web サーバーにアクセスさせないような挙動（表示）を行うか（"hard-fail"）、Web サーバーへのアクセスを許容するか（"soft-fail"）、2 つの挙動を取り得ますが、多くのブラウザは後者（"soft-fail"）を採用している、というものです。"soft-fail" 採用の理由については、例えば Wi-Fi ログイン時に TLS 接続が利用されるけれども、その時 Wi-Fi 接続の先の OCSP には接続できない（失効情報を確認できない）や、OCSP に対して DDoS 攻撃が発生した際の影響の緩和等、Imperial Violet "No, don't enable revocation checking (19 Apr 2014)" に記載されているいくつかの例が分かり易いと思います。

利便性等とのバランスから "soft-fail" が採用され、接続が許容されているわけですが、逆に悪用されるケースも存在し得ることになります。あるwebサーバーが悪意ある攻撃者に乗っ取られる等したとして、認証局が仮にその Web サーバーの証明書を失効したとしても、攻撃者が何らかの方法で（中間者攻撃や、DDoS 攻撃など）ブラウザから失効情報が確認できないような状態にすれば、ブラウザからのその Web サーバーへの TLS 接続が許容されてしまう可能性があります。

ようやく、"OCSP Must-Staple" です。
ブラウザが今接続しようとしている Web サーバーとの TLS 接続の中（ハンドシェイクの中）で、失効情報（OCSP レスポンスの情報）が必ずホチキス止め（"Must-Staple"）されて、ブラウザに渡されるので、もし、失効情報が渡されなければ、ブラウザは、その Web サーバーには接続しないように（"hard-fail"）しなさい、とするのが "OCSP Must-Staple" です。
Web サーバーが、（今まで一般に販売されていた SSL/TLS 証明書には無かった）"OCSP Must-Staple" 用の extension が追加された SSL/TLS 証明書を使い、ブラウザがその extension が含まれる SSL/TLS 証明書を受け取った場合、（それを解釈できる）ブラウザは "OCSP Must-Staple" に沿った挙動をとることになります。

試しに、FireFox 45 の β 版で、"OCSP Must-Staple" 用の extension が追加された SSL/TLS 証明書を設定した Webサーバーで、かつ、失効情報（OCSP レスポンスの情報）がホチキス止め（"stapling"）されて「いない」サーバーに TLS 接続しようとすると、以下のような画面が表示されました。

「受信したデータの真正性を検証できなかったため、このページは表示できませんでした。」ということで、"hard-fail" の挙動となりました。当然のことながら、何度"再試行"しても、失効情報は渡されないので Web サーバーへは接続できません。多少見づらいかもしれませんが、図中に追加した赤丸の部分に、"A required TLS feature is missing" というエラーメッセージが見えます。

参考までに、証明書の中には、証明書 extension (OID 1.3.6.1.5.5.7.1.24 id-pe-tlsfeature)　が入り、その値 (value) には、前述のRFC6066 "Transport Layer Security (TLS) Extensions: Extension Definitions" の中で ExtensionType : status_request （証明書のステータス要求）として定義された番号： "5" が入っています（下図、"30 03 02 01 05" とある中の最後の "05" の値がそれです）。

同 extension （と value: 5 status_request）が入っているにも関わらず、TLS 接続において、OCSP レスポンダの情報が渡されなかったということで、"A required TLS feature is missing" というエラーメッセージになっているのでしょう。
"OCSP Must-Staple" については以上です。

OCSP Multi-Stapling

話しは変わり、"OCSP Must-Staple" と混同しやすい、似通った言葉に "OCSP Multi-Stapling" があります。
"OCSP Multi-Stapling" は、RFC6961 "The Transport Layer Security (TLS): Multiple Certificate Status Request Extension" で規定されています（ちなみに、こちらも、RFC6961 中には、"Multi-Stapling" という呼称は実際には出てきません）。
証明書には、一般に階層構造があり、Web サーバーが使っている SSL/TLS 証明書が有効か無効か（？）だけでなく、その証明書を発行した、上位の認証局（中間認証局）の証明書も有効か無効か（？）を確認する必要があります。"OCSP Stapling" で Web サーバーの証明書だけ確認して、上位の中間認証局の証明書については別途 CRL や OCSP で確認するより、TLS 接続の中（TLS ハンドシェイクの中）で、一度に複数の証明書の失効情報を確認できるようにしたほうが良いではないか、というのが "OCSP Multi-Stapling" です。
さて、FireFox は、"OCSP Multi-Stapling"　も使っているのでしょうか。

OneCRL

実は、FireFox には "OneCRL" という独自の機能が組み込まれており、これを使っています（"OneCRL" については、2015 年 3 月 3 日の Mozilla Security Blog "Revoking Intermediate Certificates: Introducing OneCRL" が参考になると思います）。
"OneCRL" は、昨年 2015 年 3 月末にリリースされた FireFox 37 から導入された機能で、ブロックすべき証明書（主に失効された中間証明書）のリストを Mozilla が管理し、FireFox ブラウザに受け渡します。従来は、ブロックすべき証明書が発生した際に、FireFox をバージョンアップして対応していたため、利用者が新たにリリースされた FireFox をインストールして、問題の証明書がブロックされるようになるまでに時間を要する場合がありましたが、この機能により、中間認証局の失効に関わる情報が速やかにブラウザに行き渡るようになりました。リスト更新のトリガとなる失効の発生についても、Mozilla は認証局に対し、速やかに（24 時間以内）届け出るように求めており、中間認証局の失効が生じた場合には、一両日中には、その中間認証局から発行された SSL/TLS 証明書が FireFox ではブロックされることになると想像されます。