|
ネットワーク WG Request for Comments： 2560 分類： スタンダードトラック |
M. Myers VeriSign R. Ankney CertCo A. Malpani ValiCert S. Galperin My CFO C. Adams Entrust Technologies 1999年6月 |
この文書は、 インターネットコミュニティに対してインターネットスタンダードトラックのプロトコルを定義するとともに、 それを改良するための議論や提言を求めるものです。 このプロトコルの標準化状態およびステータスについては、 「Internet Official Protocol Standards」(STD 1)の最新版を参照してください。 このメモの配布に制限はありません。
Copyright (C) The Internet Society (1999). All Rights Reserved.
このドキュメントは、 CRLを使わずにディジタル証明書の現在の状態を判断できるプロトコルを定義します。 PKIXの運用条件に合致するほかの機構(Mechanism)については、 別個のドキュメントで記述します。
2章で本プロトコルの概要を説明します。 4章で機能要件について記述します。 5章で本プロトコルの詳細を解説します。 6章では、本プロトコルのセキュリティ問題を取り上げます。 付録Aは、OCSP over HTTPを定義します。 付録Bは、ASN.1構文要素についてまとめています。 また、付録Cは、メッセージのMIMEタイプを述べます。
本書中のキーワード、"しなければならない(MUST)"、 "してはならない(MUST NOT)"、"要求される(REQUIRED)"、 "することになる(SHALL)"、"することはない(SHALL NOT)"、 "する必要がある(SHOULD)"、"しないほうがよい(SHOULD NOT)"、 "推奨される(RECOMMENDED)"、"してもよい(MAY)"、 "選択できる(OPTIONAL)" は、 RFC 2119に記述されているように解釈されるべきものです。
周期発行CRL (periodic CRL)による確認方法の補助やその代わりとして、 証明書の失効状態([RFC2459] の3.3章参照)に関する情報を適時(タイムリー)に取得することが必要な場合があります。 例えば、高額な送金あるいは大口の証券取引などが挙げられます。
オンライン証明書状態プロトコル(OCSP)は、 アプリケーションに証明書の(失効)状態を明確にすることができます。 OCSPの使用は、 適時(タイムリー)に失効情報の提供を要求するような運用条件に対してCRLの使用よりも適合し、 さらにほかの追加状態情報も取得することができます。 OCSPクライアントは、OCSPレスポンダへ状態確認要求(リクエスト)を発行し、 レスポンダから証明書の状態の問い合わせを返してくるまで、 受け入れ(acceptance)を保留します。
本プロトコルは、証明書の状態を確認するアプリケーションと、 その状態情報を提供するサーバーとの間で交換する必要のあるデータについて規定します。
OCSPリクエストには、次の情報が含まれます。：
OCSPレスポンダは、リクエストを受け取り、 下記の項目について確認します。：
OCSPレスポンスには、様々な型(type)があります。 1つのOCSPレスポンスは、 レスポンスの型とレスポンスの実バイト数から構成されます。 あらゆるOCSPサーバーおよびクライアントがサポートしなければならない(MUST)OCSPレスポンスの基本型が存在します。 この節は、このレスポンスの基本型のみを対象に説明します。
すべての完全なレスポンスメッセージには、 ディジタル署名が付与されるようにします(SHALL)。 レスポンスの署名に使用される鍵は、 下記のいずれかに属さなければなりません(MUST)。：
完全なレスポンス・メッセージは以下のように構成されます。：
リクエストに含まれる各々の証明書に対応したレスポンスは、 下記の構成となります。：
この仕様は、 証明書状態値に対して以下の最終的なレスポンス識別子を定義します。：
「有効(good)」状態は、 状態問い合わせに対して肯定的(明確)な応答を知らせます。 この肯定的(明確)な応答は少なくとも、 証明書が失効していないことを示しますが、 証明書がいつ発行されたかということや、 レスポンスが生成された時間が証明書の有効期間内であることを必ずしも意味しません。 レスポンスの拡張領域は発行、有効性などについて、 明確に提示された証明書の状態に関連して、 レスポンダが主張する追加情報を伝送するために使用されます。
「失効(revoked)」状態は、 証明書が失効されたことを示します(恒久的もしくは一時的に(保留による))。
「不明(unknown)」状態は、 レスポンダが要求されている証明書について知らないことを示します。
エラーが発生した場合は、OCSPレスポンダはエラーメッセージを返します。 それらのメッセージには署名は付与されていません。 エラーは以下の種類があります。：
サーバーは、 受信したリクエストがOCSP構文に一致しない場合は「malformedRequest」レスポンスを生成します。
「internalError」レスポンスは、 OCSPレスポンダが一貫性のない内部的な状態に陥ったことを示します。 この場合の問い合わせは、可能性のある別のレスポンダに対して、 再試行(リトライ)してみる必要があります。
OCSPレスポンダが使用可能であるが、 要求された証明書の状態を返すことができない場合、 「tryLater」レンポンスは、 サービスが存在するが一時的に応答できないことを示すために使われます。
「sigRequired」レスポンスは、 レスポンスを生成するためにサーバーがクライアントに対して、 リクエストに署名を付与することを要求するときに返されます。
「unauthrized」レスポンスは、 クライアントからこのサーバーへの問い合わせが認可されないときに返されます。
レスポンスには、3つの時間を格納することができます。 それは、「thisUpdate」、「nextUpdate」および「producedAt」です。 それぞれのフィールドの意味は、次の通りです 。：
| - thisUpdate: | 示される状態が正常(correct)であると確認された時間 |
| - nextUpdate: | 次に証明書の状態に関する最新情報が提供可能な時間(その時点もしくはその時点までに) |
| - produceAt: | OCSPレスポンダがこのリクエストに署名を付与した時間 |
「nextUpdate」が設定されていない場合、 レスポンダはいつでも最新の失効情報が提供可能であることを示します。
OCSPレスポンダは、 ある特定の時点における証明書の状態を示すために署名されたレスポンスを事前に生成することができます(MAY)。 証明書の状態が正常(correct)と判断できた時間は、 レスポンスの「thisUpdate」フィールドに反映されます(SHALL)。 次に最新情報が提供できる時間(その時点もしくは、その時点までに)は、 「nextUpdate」フィールド内に反映され、 レスポンスが生成された時間はレスポンスの「produceAt」フィールドに示されます。
(注：OCSP Signature Authorityは、OCSP署名機関とでもいうものであり、 上位のCAから権限を委任(認証)されてたOCSPレスポンダを指します。)
証明書の状態情報に署名する鍵は、 証明書に署名した鍵と同じ鍵である必要はありません。 証明書の発行者はOCSP署名者の証明書でextendedKeyUsageに一意な値を格納した証明書を発行することにより、 明確にOCSP署名機関に権限を委任します。 この証明書は公認のCAによって、 直接にレスポンダに対して発行されなければなりません(MUST)。
OCSPレスポンダが、 特定のCAの秘密鍵が危殆化されていることを知っている場合、 そのCAによって発行されたすべての証明書に対して失効状態を返すことができます(MAY)。
OCSPクライアントに対して、 情報アクセスする周知のポイントを伝えるために、 CAは証明書にAuthorityInfoAccess拡張領域([RFC2459]の4.2.2.1で定義されている)を設定し、 OCSPで確認できるようにします(SHALL)。 あるいは、OCSP提供者のためのaccessLocationをOCSPクライアント側のローカルで構成することもできます。
OCSPサービスをサポートするCAは、ローカルで提供するのか、 または認定レスポンダ(Authorized Responder)で提供するのかにかかわらず、 uniformResourceIndicator (URI) accessLocationの値、 およびAccessDescription SEQUENCEにあるaccessMethodのid-ad-ocsp OID値を含んだものを提供しなければなりません(MUST)。
主体者証明書(subject certificate)のaccessLocationフィールドの値は、 OCSPレスポンダにアクセスするための伝送方法(例えばHTTP)を定義しますが、 その他の伝送に依存する情報(例えばURL)も含むこともあります。
署名済レスポンスを有効なものとして受諾することに先立って、 OCSPクライアントは以下の内容を確認することになります(SHALL)。：
ASN.1構文は、 [RFC2459]で定義されているターム(OID)をインポートしています。 署名計算のために、署名されるデータは、 ASN.1の識別符号化規則(DER) [X.690]にしたがって、 符号化(エンコード)されます。
他で指定されていない限り、タグを付けているASN.1 EXPLICTは、 デフォルトとして使用されます。
他の所からインポートされた用語は以下のとおりです。 それは、Extensions, CertificateSerialNumber, SubjectPublicKeyInfo, Name, AlgorithmIdentifier, CRLReasonです。
この節では、確認要求についてのASN.1仕様を定義します。 メッセージを実際にフォーマットすることは、 使用する伝送機構(HTTP、SMTP、LDAP、その他)に依存し、 それぞれ異なります。
OCSPRequest ::= SEQUENCE {
tbsRequestTBSRequest,
optionalSignature[0] EXPLICIT Signature OPTIONAL }
TBSRequest::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
requestorName [1] EXPLICIT GeneralName OPTIONAL,
requestList SEQUENCE OF Request,
requestExtensions[2] EXPLICIT Extensions OPTIONAL }
Signature ::= SEQUENCE {
signatureAlgorithmAlgorithmIdentifier,
signatureBIT STRING,
certs[0] EXPLICIT SEQUENCE OF Certificate
OPTIONAL}
Version::= INTEGER { v1(0) }
Request::= SEQUENCE {
reqCertCertID,
singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL }
CertID ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
issuerNameHashOCTET STRING, -- Hash of Issuer's DN
issuerKeyHash OCTET STRING, -- Hash of Issuers public key
serialNumber CertificateSerialNumber }
issuerNameHashは、発行者の識別名のハッシュです。 このハッシュは、 調べるための証明書の発行者名フィールドをDERエンコードし、 計算されるものです。 issuerKeyHashは、発行者の公開鍵のハッシュです。 このハッシュは、 発行者の証明書で主体者公開鍵フィールドの値(タグと長さを除外)を基に計算されます。 ハッシュアルゴリズムは、両方のハッシュに使用され、 hashAlgorithmで明示されます。 serialNumberは、状態情報が要求されている証明書のシリアル番号です。
発行者を明確にするために、 CAの名前のハッシュに加えてCAの公開鍵のハッシュを使う主要な理由は、 2つのCAが同じ名前を使う可能性があるからです (名前の一意性は推薦されますが、強制されるものではありません)。 1つのCAの一方が、それらの秘密鍵を共有することに明示的にしているCA、 もしくは鍵が危殆化された場合を除いて、 2つのCAは同じ秘密鍵を持つことはありません。
特定の拡張の対応は選択が可能です(OPTIONAL)。 重要フラグ(critical flag)は、 それらの任意のものに設定してはいけません(SHOULD NOT)。 4.4節では、いくつかの有用な拡張を薦めています。 追加的な拡張は別途のRFCに定義される可能性があります(MAY)。 未承認の拡張は(もしそれらが重要フラグ付きで理解されなければ)無視しなければなりません(MUST)。
リクエスタ(requestor)はOCSPリクエストに署名する可能性があります(MAY)。 その場合は、署名がtbsRequest構造をもとに計算されます。 もし、リクエストが署名された場合、リクエスタは、 requestorNameフィールドに自分の名前を明記することにします(SHALL)。 また、署名された要求のために、リクエスタのcertsフィールドで、 OCSPレスポンダが、要求者の署名を確認できるように、 支援する証明書を含む場合があります。
この節は、確認応答のASN.1仕様を定義します。 メッセージの実際のフォーマットは、 使用される伝送機構(HTTP、SMTP、LDAP等)に依存し、それぞれ異なります。
最小のOCSPレスポンスは、responseStatusフィールドを持ち、 直前のリクエストの処理状態を示します。 もし、responseStatusの値がエラー条件のいずれかに当てはまる場合、 responseBytesは設定されません。
OCSPResponse ::= SEQUENCE {
responseStatusOCSPResponseStatus,
responseBytes [0] EXPLICIT ResponseBytes OPTIONAL }
OCSPResponseStatus ::= ENUMERATED {
successful(0), --Response has valid confirmations
malformedRequest(1), --Illegal confirmation request
internalError(2), --Internal error in issuer
tryLater (3), --Try again later
--(4) is not used
sigRequired (5), --Must sign the request
unauthorized (6)--Request unauthorized
}
responseBytesの値は、そのOIDで明確にされた構文がOBJECT STRINGとして、 符号化したOCTET IDENTIFIERおよびレスポンスから構成されます。
ResponseBytes ::= SEQUENCE {
responseTypeOBJECT IDENTIFIER,
response OCTET STRING }
基本的なOCSPレスポンダにおいてresponseTypeはid-pkix-ocsp-basicになるでしょう。
id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp }
id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 }
OCSPレスポンダは、 id-pkix-ocsp-basicのレスポンス型のレスポンスを作成することができることになります(SHALL)。 それに対応して、 OCSPクライアントはid-pkix-ocsp-basicレスポンス型の応答を受取、 処理することになります(SHALL)。
レスポンスの値はBasicOCSPResponseをDERエンコード(符号化)したものになります(SHALL)。
BasicOCSPResponse ::= SEQUENCE {
tbsResponseDataResponseData,
signatureAlgorithmAlgorithmIdentifier,
signatureBIT STRING,
certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }
署名の値はResponseDataをDERエンコード(符号化)したハッシュに基づいて計算されることになります(SHALL)。
ResponseData ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
responderID ResponderID,
producedAtGeneralizedTime,
responses SEQUENCE OF SingleResponse,
responseExtensions[1] EXPLICIT Extensions OPTIONAL }
ResponderID ::= CHOICE {
byName[1] Name,
byKey [2] KeyHash }
KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key
(excluding the tag and length fields)
SingleResponse ::= SEQUENCE {
certID CertID,
certStatus CertStatus,
thisUpdate GeneralizedTime,
nextUpdate[0] EXPLICIT GeneralizedTime OPTIONAL,
singleExtensions[1] EXPLICIT Extensions OPTIONAL }
CertStatus ::= CHOICE {
good [0] IMPLICIT NULL,
revoked [1] IMPLICIT RevokedInfo,
unknown [2] IMPLICIT UnknownInfo }
RevokedInfo ::= SEQUENCE {
revocationTime GeneralizedTime,
revocationReason [0] EXPLICIT CRLReason OPTIONAL }
UnknownInfo ::= NULL -- this can be replaced with an enumeration
thisUpdateフィールドとnextUpdateフィールドは推奨された有効期間を定義します。 この期間は、CRL内の{thisUpdate,nextUpdate}期間に対応します。 そのnextUpdate値がローカルのシステム時間の値よりも古いレスポンスは、 信頼性が低いと考えられることになります(SHALL)。 thisUndate値がローカルのシステム時間値よりも以降の場合もレスポンスの信頼性が低い(ない)と考えられることになります(SHALL)。 nextUpdate値が設定されていないレスポンスはnextUpdateに時間設定のないCRLに相当します。 (2.4 節参照。)
produceAt時間はこのレスポンスに署名が付与された時間です。
証明書の状態情報に署名する鍵は、 証明書に署名した鍵と同じである必要はありません。 しかしながら、 この情報に署名するエンティティが認可されていることを確認する必要があります。 したがって、 証明書の発行者はOCSPレスポンスそれ自体に署名しなければならないか(MUST)、 または、別のエンティティへのこの署名機関(authority)を明確に明示にしなければなりません(MUST)。 OCSP署名委任は、 OCSPレスポンス署名者の証明書内のextendedKeyUsage証明書拡張でid-kp-OCSPSingningを含めることで明示します(SHALL)。 この証明書は、直接、 問い合わせをした証明書を発行したCAによって発行されなければなりません(MUST)。
id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}
OCSPレスポンスを信頼するシステムあるいはアプリケーションは、 上記のid-ad-ocspSigning値の使用を検知し、 強制する機能がなければなりません(MUST)。 それらのシステム、アプリケーションは、 ローカルで1つもしくは1つ以上のOCSP署名機関を設定し、 それぞれの署名機関に信頼されたCAを定義することができます(MAY)。 もしも、レスポンスの署名の有効を検証するために要求された証明書が、 次の最低1つの基準でも満たさない場合は、 システムやアプリケーションはそのレスポンスを拒否しなければなりません。：
追加の受付あるいは拒否についての基準は、レスポンス自身か、 レスポンス上で署名を有効なものとするために用いる証明書のどちらかに適用されます。
認定されたOCSPレスポンダ(Authorized OCSP responder)は、 1つもしくはそれ以上のCAに状態情報を提供します。 OCSPクライアントは認定されたレスポンダの証明書が失効されていないかをチェックする方法を知る必要があります。 CAは、3つの方法のいずれかでこの問題に対処することが可能です。：
id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }
OCSPサービスをリクエストするクライアントは、 [RFC2459]の7.2.2節に指定されたDSA sig-alg-oidによって、 明示されたDSA鍵を使って署名されたレスポンスを処理できる必要があります(SHALL)。 クライアントはさらに、 [RFC2459] の7.2.1節で指定されたRSA署名を処理することができることも必要です(SHALL)。 OCSPレスポンダは、SHA1ハッシュ・アルゴリズムに対応します(SHALL)。
この節はX.509 v3証明書([RFC2459] 参照)中で使用された拡張モデルに基づいて、 いくつかの標準拡張を定義します。 クライアントおよびレスポンダのどちらも、 全ての拡張をサポートすることは任意です。 各拡張については、その構文(シンタックス)、 OCSPレスポンダによって実行される処理および対応するレスポンスに含まれているすべての拡張を定義します。
ノンス(Nonce)は、 リプレイ攻撃を防ぐためにリクエストとレスポンスの間を暗号的に結び付け(bind)ます。 ノンス(Nonce)は、リクエストで、requestExtensionsの1つとして含まれ、 一方、レスポンスの中でresponseExtensionsの1つとして含まれています。 リクエストおよびレスポンスの両方で、 ノンス(Nonce)はオブジェクト識別子id-pkix-ocsp-nonceによって明示され、 extnValueはその値です。
id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }
OCSPレスポンダが、 失効化あるいはonHold証明書が見つけられるCRLを示すことは望ましいかもしれません。 これは、OCSPがリポジトリ(格納庫)間で設定され、 そして監査機構として使用される場合に有用になります。 CRLは、URL (CRLが利用可能なURL)、 番号(CRL番号)あるいは時間(適切なCRLが作成された時間)によって特定することができます。 これらの拡張はsingleExtensionsとして指定されるでしょう。 この拡張の識別子はid-pkix-ocsp-crlであり、値はCrlIDになります。
id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 }
CrlID ::= SEQUENCE {
crlUrl[0] EXPLICIT IA5String OPTIONAL,
crlNum[1] EXPLICIT INTEGER OPTIONAL,
crlTime [2] EXPLICIT GeneralizedTime OPTIONAL }
crlUrlについて、IA5StringはCRLが利用可能なURLを指定します。 crlNumについては、INTEGERが、適切なCRLのCRL番号拡張の値を指定します。 crlTimeについては、GeneralizedTimeが、 適切なCRLが発行された時間を示します。
OCSPクライアントは、 受け入れできるレスポンス型の種類を指定することができます(MAY)。 そのために、 id-pkix-ocsp-responseのOIDを備えた拡張およびAcceptableResponses値を使用する必要があります(SHOULD)。 この拡張は、 リクエストにおいてrequestExtensionsの1つとして含まれています。 AcceptableResponsesに含まれているOIDは、 このクライアントが受け入れできる様々なレスポンス型のOID(例： id-pkix-ocsp-basic)を意味します。
id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 }
AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER
4.2.1節で言及したように、 OCSPレスポンダは、 id-pkix-ocsp-basicレスポンス型のレスポンスで応答できることになっています(SHALL)。 相応して、 OCSPクライアントはid-pkix-ocsp-basicレスポンス型の受け入れおよび処理もできることになります(SHALL)。
OCSPレスポンダは、 証明書の有効期間を過ぎても失効情報を保持することができます(MAY)。 レスポンスの中のproducedAt時間からこの保持期間値を差し引くことによって得られた期日は、 証明書の「記録終止」日として定義されます。
OCSPが使用可能なアプリケーションは、 署名を検証するため必要な証明書が既に有効期間切れしていても、 そのディジタル署名が署名された当日に有効であったか(あるいは、 そうでなかったか)を証明するために、OCSP記録終止日を使います。
このような履歴参照機能を提供するOCSPサーバーは、 記録終止日拡張(archive cutoff date extension)をレスポンスに含める必要があります(SHOULD)。 含まれている場合、この値はOCSP singleExtensions拡張として、 id-pkix-ocsp-archive-cutoffおよびGeneralizedTime構文で明示されることになります(SHALL)。
id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 }
ArchiveCutoff ::= GeneralizedTime
説明すると、もし、サーバーが7年の保有期間ポリシーで運用、 および状態は時間でt1生成され、 レスポンスのArchiveCutoffの値は(t1-7年)になります。
全ての拡張は、 CRLエントリ拡張(CRL Entry Extensions)([RFC2459] の5.3節参照)として指定され、 singleExtensionsとしてもサポートされています。
OCSPサーバーは、サーバーリクエストおよびルートを受け取り、 それを識別される証明書に権威のあるOCSPサーバーに転送する形態で運用することができます。 serviceLocatorリクエスト拡張は、この目的のために定義されます。 この拡張は、 リクエストの中でsingleRequestExtensionsのうちの1つとして含まれています。
id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 }
ServiceLocator ::= SEQUENCE {
issuer Name,
locatorAuthorityInfoAccessSyntax OPTIONAL }
これらのフィールドの値は、 主体者証明書で対応するフィールドから取得します。
このサービスを効果的にするためには、 証明書を利用するシステムが、 証明書状態サービスプロバイダに接続しなければなりません。 もしも、このような接続が不可能な場合には、 証明書を利用のシステムは、代替策(fall-back position)として、 CRL処理ロジックを実装することができます。
サービス妨害攻撃(DoS攻撃)に対する脆弱性は、 問い合わせ(Query)の殺到と密接に関連しています。 暗号署名の作成は、レスポンスの生成間隔時間に著しく影響を及ぼし、 状況をさらに悪化させます。 また、未署名のエラーレスポンスは、 このプロトコルを新たなサービス妨害攻撃(DoS攻撃)に開放してしまうことになり、 攻撃者は偽のエラーレスポンスを送り出すことができることになります。
事前規定レスポンスの使用は、たとえ証明書が失効された後でも、 レスポンスの有効期限内に古い(有効)レスポンスをリプレイすることにより、 リプレイ攻撃を許してしまいます。 OCSP設置の際に、 事前設計レスポンスの利点とリプレイ攻撃の可能性および成功的な導入に必要の費用を比較し、 慎重に評価する必要があります。
リクエストには、要求先のレスポンダ(情報)を含んでいません。 これは、攻撃者に対して、 かなり多くのOCSPレスポンダにリクエストを再送することを許すことになります。
一部の展開シナリオ(deployment scenarios)でキャッシングするHTTPの信頼は、 中間サーバーの誤った構成やキャッシュ管理の欠陥などの原因により、 予期せぬ結果に帰着するかもしれません。 導入する側が、OCSP over HTTPを展開する際に、 当事者はHTTPキャッシュ機構の信頼性を考慮に入れることを勧めます。
| [RFC2459] |
Housley, R., Ford, W., Polk, W. and D. Solo, 「インターネットX.509公開鍵インフラストラクチャ(Internet X.509 Public Key Infrastructure Certificate and CRL Profile)」, RFC 2459, 1999年1月. |
| [HTTP] |
Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. Berners-Lee,
"Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, 1997年1月. |
| [RFC2119] |
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, 1997年3月. |
| [URL] |
Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, 1994年12月. |
| [X.690] | ITU-T Recommendation X.690 (1994) | ISO/IEC 8825-1:1995, Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER). |
Michael Myers
VeriSign, Inc.
1350 Charleston Road
Mountain View, CA 94043
EMail： mmyers＠verisign.com
Rich Ankney
CertCo, LLC
13506 King Charles Dr.
Chantilly, VA 20151
EMail： rankney＠erols.com
Ambarish Malpani
ValiCert, Inc.
1215 Terra Bella Ave.
Mountain View, CA 94043
電話：650.567.5457
EMail： ambarish＠valicert.com
Slava Galperin
My CFO, Inc.
1945 Charleston Road
Mountain View, CA
EMail： galperin＠mycfo.com
Carlisle Adams
Entrust Technologies
750 Heron Road, Suite E08
Ottawa, Ontario
K1V 1A7
Canada
EMail： cadams＠entrust.com
この節は、 HTTPをサポートするリクエストおよびレスポンスのフォーマットについて記述します。
HTTPベースのOCSPリクエストは、 GETあるいはPOST方式を使って要求を提示することができます。 HTTPキャッシングを有効にするために、 サイズの小さいリクエスト(符号化の後255バイト未満のもの)は、 GET方式を使って要求の提示を行うことができます(MAY)。 HTTPキャッシングが重要でない場合、 もしくはリクエストが255バイト以上の場合、 リクエストはPOST方式を使って、 要求を提示する必要があります(SHOULD)。 プライバシー保護が要件となっていれば、 HTTPベースのOCSPトランザクションの交換は、 TLS/SSLまたはそれより下層のほかのプロトコルを使用し、 保護することが可能です(MAY)。
GET方式を使用するOCSPリクエストは以下のように構成されます:
GET {url}/{url-encoding of base-64 encoding of the DER encoding of the OCSPRequest}
ここで{url}は、 AuthorityInfoAccessの値あるいはOCSPクライアントの他のローカル設定から抽出することができます。
POST方式を使用するOCSPリクエストは以下のように構築されます: Content-Typeヘッダーの値は「application/ocsp-request」で、 メッセージの本体(Body)がDERエンコード(符号化)されたOCSPRequestのバイナリ値となります。
HTTPベースのOCSPレスポンスは、適切なHTTPヘッダーと、 その後ろに続くDERエンコード(符号化)されたOCSPResponseのバイナリ値で構成されます。 Content-Typeヘッダーの値は「application/ocsp-response」となっています。 Content-Lengthヘッダーはレスポンスの長さを指定する必要があります(SHOULD)。 他のHTTPヘッダーは存在する可能性がありますが(MAY)、 リクエスタが理解不能であれば、無視される可能性があります(MAY)。
OCSP DEFINITIONS EXPLICIT TAGS::=
BEGIN
IMPORTS
-- Directory Authentication Framework (X.509)
Certificate, AlgorithmIdentifier, CRLReason
FROM AuthenticationFramework { joint-iso-itu-t ds(5)
module(1) authenticationFramework(7) 3 }
-- PKIX Certificate Extensions
AuthorityInfoAccessSyntax
FROM PKIX1Implicit88 {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-implicit-88(2)}
Name, GeneralName, CertificateSerialNumber, Extensions,
id-kp, id-ad-ocsp
FROM PKIX1Explicit88 {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit-88(1)};
OCSPRequest ::= SEQUENCE {
tbsRequestTBSRequest,
optionalSignature[0] EXPLICIT Signature OPTIONAL }
TBSRequest::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
requestorName [1] EXPLICIT GeneralName OPTIONAL,
requestList SEQUENCE OF Request,
requestExtensions[2] EXPLICIT Extensions OPTIONAL }
Signature ::= SEQUENCE {
signatureAlgorithmAlgorithmIdentifier,
signatureBIT STRING,
certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }
Version ::= INTEGER { v1(0) }
Request ::= SEQUENCE {
reqCert CertID,
singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL }
CertID ::= SEQUENCE {
hashAlgorithmAlgorithmIdentifier,
issuerNameHash OCTET STRING, -- Hash of Issuer's DN
issuerKeyHashOCTET STRING, -- Hash of Issuers public key
serialNumber CertificateSerialNumber }
OCSPResponse ::= SEQUENCE {
responseStatusOCSPResponseStatus,
responseBytes [0] EXPLICIT ResponseBytes OPTIONAL }
OCSPResponseStatus ::= ENUMERATED {
successful(0),--Response has valid confirmations
malformedRequest(1),--Illegal confirmation request
internalError(2),--Internal error in issuer
tryLater (3),--Try again later --(4) is not used
sigRequired (5),--Must sign the request
unauthorized (6) --Request unauthorized
}
ResponseBytes ::= SEQUENCE {
responseTypeOBJECT IDENTIFIER,
response OCTET STRING }
BasicOCSPResponse ::= SEQUENCE {
tbsResponseDataResponseData,
signatureAlgorithmAlgorithmIdentifier,
signatureBIT STRING,
certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }
ResponseData ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
responderID ResponderID,
producedAtGeneralizedTime,
responses SEQUENCE OF SingleResponse,
responseExtensions[1] EXPLICIT Extensions OPTIONAL }
ResponderID ::= CHOICE {
byName[1] Name,
byKey [2] KeyHash }
KeyHash ::= OCTET STRING --SHA-1 hash of responder's public key
--(excluding the tag and length fields)
SingleResponse ::= SEQUENCE {
certID CertID,
certStatus CertStatus,
thisUpdate GeneralizedTime,
nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL,
singleExtensions [1] EXPLICIT Extensions OPTIONAL }
CertStatus ::= CHOICE {
good [0] IMPLICIT NULL,
revoked [1] IMPLICIT RevokedInfo,
unknown [2] IMPLICIT UnknownInfo }
RevokedInfo ::= SEQUENCE {
revocationTime GeneralizedTime,
revocationReason [0] EXPLICIT CRLReason OPTIONAL }
UnknownInfo ::= NULL -- this can be replaced with an enumeration
ArchiveCutoff ::= GeneralizedTime
AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER
ServiceLocator ::= SEQUENCE {
issuer Name,
locatorAuthorityInfoAccessSyntax }
-- Object Identifiers
id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 }
id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp }
id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 }
id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }
id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 }
id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 }
id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }
id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 }
id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 }
END
To: ietf-types@iana.org
Subject: Registration of MIME media type application/ocsp-request
MIME media type name: application
MIME subtype name: ocsp-request
Required parameters: None
Optional parameters: None
Encoding considerations: binary
Security considerations: Carries a request for information. This
request may optionally be cryptographically signed.
Interoperability considerations: None
Published specification: IETF PKIX Working Group Draft on Online
Certificate Status Protocol - OCSP
Applications which use this media type: OCSP clients
Additional information:
Magic number(s): None
File extension(s): .ORQ
Macintosh File Type Code(s): none
Person & email address to contact for further information:
Ambarish Malpani <ambarish@valicert.com>
Intended usage: COMMON
Author/Change controller:
Ambarish Malpani <ambarish@valicert.com>
To: ietf-types@iana.org
Subject: Registration of MIME media type application/ocsp-response
MIME media type name: application
MIME subtype name: ocsp-response
Required parameters: None
Optional parameters: None
Encoding considerations: binary
Security considerations: Carries a cryptographically signed response
Interoperability considerations: None
Published specification: IETF PKIX Working Group Draft on Online
Certificate Status Protocol - OCSP
Applications which use this media type: OCSP servers
Additional information:
Magic number(s): None
File extension(s): .ORS
Macintosh File Type Code(s): none
Person & email address to contact for further information:
Ambarish Malpani <ambarish@valicert.com>
Intended usage: COMMON
Author/Change controller:
Ambarish Malpani <ambarish@valicert.com>
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
現在、RFCエディターのための資金は、 インターネットソサエティーによって提供されています。