OCSP ステープリングの導入
A 社の Web サイトでは，利用者のブラウザがサーバ証明書の失効状態を OCSP レスポンダに直接問い合わせている。これに対し，利用者がどのサイトにアクセスしたかが OCSP レスポンダに知られること，及びハンドシェイク中に問合せの待ち時間が生じることが指摘された。失効確認の信頼性を損なわずに両方の指摘に対応する方法として，最も適切なものはどれか。
- アブラウザから OCSP レスポンダへの問合せを TLS で暗号化し，問合せの内容を通信経路上で盗聴されないようにする。
- イOCSP 応答が得られない場合は失効していないものとみなすようにブラウザを設定し，待ち時間を短く打ち切る。
- ウWeb サーバが自らの秘密鍵で，証明書が失効していないことを示すデータに署名し，ハンドシェイク中にブラウザに提示する。
- エWeb サーバが OCSP レスポンダから署名付きの OCSP 応答を取得しておき，TLS ハンドシェイクの中でブラウザに送る。
正解と解説を見る
正解 エ
この問題の基礎知識
- 証明書の失効確認には，CA が失効した証明書の一覧に署名して公開する CRL と，個々の証明書の状態をオンラインで問い合わせる OCSP がある。
- OCSP 応答には OCSP レスポンダの署名が付いているので，誰が中継しても，受け取った側は署名を検証して改ざんを検知できる。
- OCSP ステープリングは，Web サーバが事前に取得した OCSP 応答を TLS ハンドシェイクで証明書とともに送る方式であり，クライアントからレスポンダへの問合せが不要になる。
- 通信路の暗号化は経路上の第三者による盗聴を防ぐが，通信相手（問合せ先）に問合せの内容が知られることは防がない。
アブラウザから OCSP レスポンダへの問合せを TLS で暗号化し，問合せの内容を通信経路上で盗聴されないようにする。
経路の暗号化は第三者による盗聴を防ぐだけであり，問合せを受ける OCSP レスポンダには，どの証明書を確認したかが引き続き分かる。ブラウザが問い合わせる構成のままなので，待ち時間も解消しない。
イOCSP 応答が得られない場合は失効していないものとみなすようにブラウザを設定し，待ち時間を短く打ち切る。
応答が得られないときに接続を続ける設定は，待ち時間を短くするだけで，問合せ自体は続くのでアクセス先は OCSP レスポンダに知られる。失効状態を確認できないまま接続することになり，失効確認の信頼性を損なう。
ウWeb サーバが自らの秘密鍵で，証明書が失効していないことを示すデータに署名し，ハンドシェイク中にブラウザに提示する。
失効確認は，秘密鍵の漏えいなどでサーバを信頼できなくなった場合に備えるものである。サーバ自身の署名による主張は，秘密鍵を入手した攻撃者も作れるので失効確認にならない。OCSP 応答は OCSP レスポンダが署名する。
エWeb サーバが OCSP レスポンダから署名付きの OCSP 応答を取得しておき，TLS ハンドシェイクの中でブラウザに送る。正解
OCSP ステープリングでは，サーバが事前に取得した OCSP 応答を TLS の status_request 拡張によって送る。ブラウザはレスポンダに問い合わせずに済み，応答はレスポンダの署名で検証できるので，サーバによる改ざんも検知できる。
検証用の出典出典照合済み
RFC 6066 Transport Layer Security (TLS) Extensions: Extension Definitions ／ RFC 6960 X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP照合の根拠（6 件）
- エ（正解）: ステープリング（in-band 提供）でプライバシーと性能の問題が解消される。ア・イは第三者（レスポンダ）への接続が残るので解消しない
When this information is provided in-band, the privacy, performance, and reliability concerns arising from the need to make a third-party connection during the TLS handshake are eliminated.
RFC 7633 · Section 1（新しいタブで開きます） - エ（正解）: サーバが status_request 拡張を受けて証明書とともに OCSP 応答を返す
Servers that receive a client hello containing the "status_request" extension MAY return a suitable certificate status response to the client along with their certificate.
RFC 6066 · Section 8（新しいタブで開きます） - エ（正解）: クライアントはステープルされた OCSP 応答を検証する
Clients requesting an OCSP response and receiving an OCSP response in a "CertificateStatus" message MUST check the OCSP response and abort
RFC 6066 · Section 8（新しいタブで開きます） - ウ（誤り）・エ（正解）: OCSP 応答の署名鍵は発行 CA，信頼されたレスポンダ又は CA が指定したレスポンダのもので，サーバ自身の鍵は含まれない
All definitive response messages SHALL be digitally signed. The key used to sign the response MUST belong to one of the following:
RFC 6960 · Section 2.2（新しいタブで開きます） - イ（誤り）: 失効確認は状態提供者に接続できてはじめて有効であり，応答が得られないときに失効なしとみなすと確認の意味が失われる
For this service to be effective, certificate-using systems must connect to the certificate status service provider.
RFC 6960 · Section 5（新しいタブで開きます） - イ（誤り）: 失効状態の情報が得られないことから「失効していない」と結論することはできない
However, a client cannot draw any conclusion from the absence of in-band status information unless it knows that the legitimate server would have provided it.
RFC 7633 · Section 1（新しいタブで開きます）
ア: TLS で経路を暗号化しても問合せ先の OCSP レスポンダにはどの証明書を確認したかが分かり，第三者への接続も残る（RFC 7633 が挙げる privacy / performance の懸念はそのまま）。