ルート鍵を含まない、あるいは、いくらか、もしくは、すべてを含む可能性があること」に注意。複数の鍵ペアをもつ場合)」にも注意。用法に従う場合である」と想定する。ルート鍵の保持を示すことができるようにするために含められる。受け取るサーバは、そのクライアント宛に返す適切な証明書チェーンの選択をガイドするために、その拡張中に納められた情報を使う可能性がある(MAY)。拡張を含むものとする(SHALL)。フィールドは、空であるものとする(SHALL)。レコード層の通信を認証する(authenticate)ためにを使う。切り詰めることによって、帯域を節約することが渇望される可能性がある。拡張を含む可能性がある(MAY)。フィールドは、空であるものとする(SHALL)。使うことに合意する可能性がある(MAY)。使わない新しいサイファースィートが追加され、そのセッションがこれらのサイファースィートのひとつと交渉する場合、この拡張は影響を与えないこと」に注意。長を、そのサイファースィート定義の不可欠(integral)な部分と見なすこと」が強く推奨される。使わなければならない(MUST)。転送されて、チェックされる。function)の計算に影響を与えないこと」に注意。切り詰め(truncation)長(size)は、セッション回復(resumption)を含むセッションの継続(duration)に適用する。ような証明書状態プロトコルを使うことを望む可能性がある。ハンドシェイクにおいて、このような情報が通信遅延(roundtrip)や資源を節約して送られうるようにする。拡張を含む可能性がある(MAY)。含むものとする(SHALL)。ここでは、下記の処理が行われる。事前の調整(arrangement)によって)」という特別な意味をもつ。符号化したものである。[RFC5280]から導入された。逆に)拡張は無いこと」を意味する。その符号化について不明確である。クライアントに基づく実装は、この要件への準拠性についてチェックされる必要があること」に注意)。受け取るサーバは、適切な証明書状態レスポンスを、それらの証明書と共にクライアント宛に返す可能性がある(MAY)。リクエスト中に含む必要がある(SHOULD)。メッセージの前)に送ることによって、サーバ証明書と共に証明書レスポンスを返す。拡張を含めていなければならない(MUST)。使って運ばれる(2章も参照)。OCSPレスポンスを使って)納める。レスポンスのみが送られる可能性がある。メッセージを送らないことも選択する可能性もある(MAY)こと」に注意。レスポンスが十分なもの(satisfactory)でない場合、そのハンドシェイクを中止しなければならない(MUST)。拡張についての用法のために定義されている。これらのエラー警告は、下記の構文(syntax)を使って運ばれる。番号と同じ行上のコメントによって示されているように、最後の4つである。経緯上の理由で定義されていない。5章に記述されている。3章に記述されている。8章に記述されている。5章に記述されている。12章に網羅されいる。本書を参照するように更新されている。証明書パスを表現するために使われる。このシーケンス内において、証明書の順序は、「最初の証明書のサブジェクトは、2番目の証明書の発行者となり...」というようなものとなる。中に公表されている定義と同一のものである。「これは、[X509-4th]」中のものとは異なること」に注意。準拠しなければならない(MUST)。準拠証明書のみを符号化するための要件として解釈される必要がある。party)によって棄却されなければならないこと」までは要求しない。使われなければならない(MUST)。TLS)を使うあらゆるプロトコルについてのものと共に適用される。設定に関する妥当性(validity)について関連付けられうる証明書チェーンのみを規定すること」、「これは、その設定に対するいかなる変更を規定するためにも使われることを意図されていないこと」に注意。