ネットワーク WG
Request for Comments: 2560
分類: スタンダードトラック
 

M. Myers
 VeriSign
R. Ankney
CertCo
A. Malpani
ValiCert
S. Galperin
My CFO
C. Adams
Entrust Technologies 
1999年 6月

English

X.509インターネット PKIオンライン証明書状態プロトコル(OCSP)
( X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP )

このメモの位置付け

この文書は、インターネットコミュニティに対してインターネットスタンダードトラックのプロトコルを定義するとともに、それを改良するための議論や提言を求めるものです。このプロトコルの標準化状態およびステータスについては、「Internet Official Protocol Standards」 (STD 1) の最新版を参照してください。このメモの配布に制限はありません。

著作権表記

Copyright (C) The Internet Society (1999). All Rights Reserved.

 

1. 要旨 English

このドキュメントは、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 に記述されているように解釈されるべきものです。

 

2. プロトコル概要 English

周期発行CRL(periodic CRL) による確認方法の補助やその代わりとして、証明書の失効状態 ([RFC2459] の 3.3章参照)に関する情報を適時(タイムリー)に取得することが必要な場合があります。例 えば、高額な送金あるいは大口の証券取引などが挙げられます。

オンライン証明書状態プロトコル (OCSP) は、アプリケーションに証明書の(失効)状態を明確にすることができます。OCSP の使用は、適時(タイムリー)に失効情報の提供を要求するような運用条件に対して CRL の使用よりも適合し、さらにほかの追加状態情報も取得することができます。OCSP クライアントは、OCSP レスポンダへ状態確認要求(リクエスト)を発行し、レスポンダから証明書の状態の問い合わせを返してくるまで、受け入れ (acceptance) を保留します。

本プロトコルは、証明書の状態を確認するアプリケーションと、その状態情報を提供するサーバーとの間で交換する必要のあるデータについて規定します。

2.1 リクエスト English

OCSPリクエストには、次の情報が含まれます。:

OCSPレスポンダは、リクエストを受け取り、下記の項目について確認します。:

  1. メッセージは正常な形式になっているか
     
  2. 要求されたサービスを提供できるようにレスポンダが設定されているか
     
  3. リクエストにレスポンダが必要とする情報を含んでいるが、上記の条件のいずれをも満たさない場合、OCSP レスポンダは、エラー・メッセージを生成します。それ以外の場合は OCSP レスポンダが完全なレスポンス(definitive response)を返します。

2.2 レスポンス English

OCSP レスポンスには、様々な型(type)があります。1つの OCSP レスポンスは、レスポンスの型とレスポンスの実バイト数から構成されます。あらゆるOCSP サーバーおよびクライアントがサポートしなければならない(MUST) OCSPレスポンスの基本型が存在します。この節は、このレスポンスの基本型のみを対象に説明します。

すべての完全なレスポンスメッセージには、ディジタル署名が付与されるようにします(SHALL)。レスポンスの署名に使用される鍵は、下記のいずれかに属さなければなりません(MUST)。 :

完全なレスポンス・メッセージは以下のように構成されます。:

リクエストに含まれる各々の証明書に対応したレスポンスは、下記の構成となります。:

この仕様は、証明書状態値に対して以下の最終的なレスポンス識別子を定義します。:

「有効(good)」状態は、状態問い合わせに対して肯定的(明確)な応答を知らせます。この肯定的(明確)な応答は少なくとも、証明書が失効していないことを示しますが、証明書がいつ発行されたかということや、レスポンスが生成された時間が証明書の有効期間内であることを必ずしも意味しません。レスポンスの拡張領域は発行、有効性などについて、明確に提示された証明書の状態に関連して、レスポンダが主張する追加情報を伝送するために使用されます。

「失効(revoked)」状態は、証明書が失効されたことを示します(恒久的もしくは一時的に(保留による))。

「不明(unknown)」状態は、レスポンダが要求されている証明書について知らないことを示します。

2.3 例外ケース English

エラーが発生した場合は、OCSP レスポンダはエラーメッセージを返します。それらのメッセージには署名は付与されていません。エラーは以下の種類があります。:

サーバーは、受信したリクエストが OCSP 構文に一致しない場合は「malformedRequest」レスポンスを生成します。

「internalError」レスポンスは、OCSP レスポンダが一貫性のない内部的な状態に陥ったことを示します。この場合の問い合わせは、可能性のある別のレスポンダに対して、再試行(リトライ)してみる必要があります。

OCSP レスポンダが使用可能であるが、要求された証明書の状態を返すことができない場合、「tryLater」レンポンスは、サービスが存在するが一時的に

応答できないことを示すために使われます。

「sigRequired」レスポンスは、レスポンスを生成するためにサーバーがクライアントに対して、リクエストに署名を付与することを要求するときに返されます。

「unauthrized」レスポンスは、クライアントからこのサーバーへの問い合わせが認可されないときに返されます。

2.4 thisUpdate、nextUpdate と producedAt の意味 English

レスポンスには、3つの時間を格納することができます。それは、「thisUpdate」、「nextUpdate」および「producedAt」です。それぞれのフィールドの意味は 、次の通りです 。:

- thisUpdate: 示される状態が正常( correct) であると確認された時間
- nextUpdate: 次に証明書の状態に関する最新情報が提供可能な時間 (その時点もしくはその時点までに)
- produceAt: OCSPレスポンダがこのリクエストに署名を付与した時間

「nextUpdate」が設定されていない場合、レスポンダはいつでも最新の失効情報が提供可能であることを示します。

2.5 レスポンスの事前生成 English

OCSP レスポンダは、ある特定の時点における証明書の状態を示すために署名されたレスポンスを事前に生成することができます(MAY)。証明書の状態が正常 (correct) と判断できた時間は、レスポンスの 「thisUpdate」フィールドに反映されます(SHALL)。次に最新情報が提供できる時間(その時点もしくは、その時点までに)は、「nextUpdate」フィールド内に反映され、レスポンスが生成された時間はレスポンスの 「produceAt」フィールドに示されます。

2.6 OCSP 署名機関権限委任 English

(注: OCSP Signature Authority は、OCSP 署名機関とでもいうものであり、上位の CA から権限を委任(認証)されてた OCSP レスポンダを指します。)

証明書の状態情報に署名する鍵は、証明書に署名した鍵と同じ鍵である必要はありません。証明書の発行者は OCSP 署名者の証明書でextendedKeyUsageに一意な値を格納した証明書を発行することにより、明確に OCSP 署名機関に権限を委任します。この証明書は公認の CA によって、直接にレスポンダに対して発行されなければなりません(MUST)

2.7 CA 鍵の危殆化 English

OCSP レスポンダが、特定の CA の秘密鍵が危殆化されていることを知っている場合、その CA によって発行されたすべての証明書に対して失効状態を返 すことができます(MAY)

 

3. 機能要件 English

3.1 証明書内容 English

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)も含むこともあります。

3.2 署名済レスポンス受諾要件 English

署名済レスポンスを有効なものとして受諾することに先立って、OCSP クライアントは以下の内容を確認することになります(SHALL)。:

  1. 受信レスポンスで識別された証明書は、対応するリクエストで識別された証明書と一致していること
  2. レスポンスの署名が有効であること
  3. 署名者の身元は、このリクエストの本来意図した受取人と一致すること
  4. 署名者は現状でレスポンスに署名することが認可されていること
  5. 示されている状態が正確であると (thisUpdate) 知られている時間が、十分に新しいこと
  6. 利用可能の場合、時間または新しい情報で、あるいは次に証明書 (nextUpdate) は、現在の時間より先であること

 

4. 詳細プロトコル English

ASN.1 構文は、[RFC2459] で定義されているターム(OID) をインポートしています。署名計算のために、署名されるデータは、ASN.1 の識別符号化規則(DER) [X.690] にしたがって、符号化(エンコード)されます。

他で指定されていない限り、タグを付けている ASN.1 EXPLICT は、デフォルトとして使用されます。

他の所からインポートされた用語は以下のとおりです。それは、 Extensions,CertificateSerialNumber, SubjectPublicKeyInfo, Name,AlgorithmIdentifier, CRLReason です。

4.1 要求 English

この節では、確認要求についての ASN.1 仕様を定義します。メッセージを実際にフォーマットすることは、使用する伝送機構 (HTTP、SMTP、LDAP、その他)に依存し、それぞれ異なります。

4.1.1 リクエスト構文 English

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 は 、状態情報が要求されている証明書のシリアル番号です。

4.1.2 リクエスト構文の注意 English

発行者を明確にするために、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 レスポンダが、要求者の署名を確認できるように、支援する証明書を含む場合があります。

4.2 レスポンス構文 English

この節は、確認応答の ASN.1 仕様を定義します。メッセージの実際のフォーマットは、使用される伝送機構(HTTP、SMTP、LDAP 等)に依存し、それぞれ異なります。

4.2.1 OCSP レスポンスの ASN.1 仕様 English

最小の 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

4.2.2 OCSPレスポンスの注意点 English

4.2.2.1 時間 English

thisUpdateフィールドとnextUpdateフィールドは推奨された有効期間を定義します。この期間は、CRL 内の{thisUpdate,nextUpdate}期間に対応します。その nextUpdate 値がローカルのシステム時間の値よりも古いレスポンスは、信頼性が低いと考えられることになります(SHALL)。thisUndate値がローカルのシステム時間値よりも以降の場合もレスポンスの信頼性が低い(ない)と考えられることになります(SHALL)。 nextUpdate 値が設定されていないレスポンスは nextUpdate に時間設定のない CRL に相当します 。(2.4 節参照。)

produceAt 時間はこのレスポンスに署名が付与された時間です。

4.2.2.2 認定レスポンダ(Authorized Responders) English

証明書の状態情報に署名する鍵は、証明書に署名した鍵と同じである必要はありません。しかしながら、この情報に署名するエンティティが認可されていることを確認する必要があります。したがって、証明書の発行者は 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つの基準でも満たさない場合は、システムやアプリケーションはそのレスポンスを拒否しなければなりません。:

  1. 問い合わせ証明書に対する OCSP 署名機関のローカルの設定と一致すること;または
  2. 問い合わせ証明書を発行した CA の証明書であること;または
  3. ExtendedKeyUsage 拡張に id-ad-ocspSigning の値を含み、問い合わせ証明書の発行元 CA によって発行されていること。

追加の受付あるいは拒否についての基準は、レスポンス自身か、レスポンス上で署名を有効なものとするために用いる証明書のどちらかに適用されます。

4.2.2.2.1 認定レスポンダの失効確認 English

認定されたOCSPレスポンダ(Authorized OCSP responder)は、1つもしくはそれ以上の CA に状態情報を提供します。OCSP クライアントは認定されたレスポンダの証明書が失効されていないかをチェックする方法を知る必要があります。CA は、3つの方法のいずれかでこの問題に対処することが可能です。:

- CA は、OCSP クライアントがレスポンダの証明書の有効期間(ライフタイム)にレスポンダを信頼できることを規定することができます。CA は、 id-pkix-ocsp-nocheck 拡張を含めることで実現します。これは非重要 (non-critical) 拡張である必要があります(SHOULD)。拡張の値は NULL であるべきです。レスポンダの鍵の危殆化は少なくともこの証明書の有効期間の間に、CRL 署名用のCA鍵の危殆化と同様に重要なことであり、この証明書を発行する CA はその点を認識すべきです。CA は非常に短い有効期間でこのタイプの証明書の発行を設定し、頻繁に更新することがあります。

id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }

- CA は、レスポンダの証明書の失効がどのように確認されるのかを指定できます。これは、CRL か CRL 配布点 (CRL Distribution Points) を使うべきところでは、CRL 配布点 (CRL Distribution Points) を使い、あるいはほかの方法でチェックする必要がある場合、認証機関情報アクセス (Authority Information Access)を使用します。これらの 2つの機構のどちらかを指定するための詳細説明は [RFC2459] で利用できます。

- CA は、レスポンダの証明書の失効をチェックする方法を指定しないことを選ぶこともできます。指定しない場合は、その証明書の失効をチェックするべきかの決定は、OCSP クライアントのローカル・セキュリティポリシー次第となります。

4.3 必須暗号アルゴリズムとオプション暗号アルゴリズム English

OCSPサービスをリクエストするクライアントは、[RFC2459] の 7.2.2節に指定された DSA sig-alg-oid によって、明示された DSA 鍵を使って署名されたレスポンスを処理できる必要があります(SHALL)。クライアントはさらに、 [RFC2459] の 7.2.1節で指定された RSA 署名を処理することができることも必要です(SHALL)。OCSPレスポンダは 、SHA1 ハッシュ・アルゴリズムに対応します(SHALL)

4.4 拡張 English

この節は X.509 v3 証明書( [RFC2459] 参照)中で使用された拡張モデルに基づいて、いくつかの標準拡張を定義します。クライアントおよびレスポンダのどちらも、全ての拡張をサポートすることは任意です。各拡張については、その構文(シンタックス)、OCSP レスポンダによって実行される処理および対応するレスポンスに含まれているすべての拡張を定義します。

4.4.1 ノンス(Nonce) English

ノンス (Nonce) は、リプレイ攻撃を防ぐためにリクエストとレスポンスの間を暗号的に結び付け(bind)ます。ノンス(Nonce)は、リクエストで、 requestExtensions の1つとして含まれ、一方、レスポンスの中で responseExtensionsの 1つとして含まれています。リクエストおよびレスポンスの両方で、ノンス(Nonce)はオブジェクト識別子 id-pkix-ocsp-nonce によって明示され、extnValue はその値です。

id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }

4.4.2 CRL参照(リファレンス) English

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 が発行された時間を示します。

4.4.3 受け入れ可能なレスポンス型 English

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)

4.4.4 記録終止 (Archive Cutoff) English

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年)になります。

4.4.5 CRL エントリ拡張 English

全ての拡張は、CRLエントリ拡張(CRL Entry Extensions)( [RFC2459] の 5.3 節参照)として指定され、singleExtensions としてもサポートされています。

4.4.6 サービスロケータ English

OCSP サーバーは、サーバーリクエストおよびルートを受け取り、それを識別される証明書に権威のある OCSP サーバーに転送する形態で運用することができます。serviceLocator リクエスト拡張は、この目的のために定義されます。この拡張は 、リクエストの中で singleRequestExtensions のうちの 1つとして含まれています。

id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 }

ServiceLocator ::= SEQUENCE {

issuer Name,
locatorAuthorityInfoAccessSyntax OPTIONAL }

これらのフィールドの値は、主体者証明書で対応するフィールドから取得します。

 

5.セキュリティについての考慮事項 English

このサービスを効果的にするためには、証明書を利用するシステムが、証明書状態サービスプロバイダに接続しなければなりません。もしも、このような接続が不可能な場合には、証明書を利用のシステムは、代替策 (fall-back position) として、CRL 処理ロジックを実装することができます。

サービス妨害攻撃(DoS 攻撃)に対する脆弱性は、問い合わせ (Query) の殺到と密接に関連しています。暗号署名の作成は、レスポンスの生成間隔時間に著しく影響を及ぼし、状況をさらに悪化させます。また、未署名のエラーレスポンスは、このプロトコルを新たな サービス妨害攻撃(DoS攻撃)に開放してしまうことになり、攻撃者は偽のエラーレスポンスを送り出すことができることになります。

事前規定レスポンスの使用は、たとえ証明書が失効された後でも、レスポンスの有効期限内に古い(有効)レスポンスをリプレイすることにより、リプレイ攻撃を許してしまいます。OCSP 設置の際に、事前設計レスポンスの利点とリプレイ攻撃の可能性および成功的な導入に必要の費用を比較し、慎重に評価する必要があります。

リクエストには、要求先のレスポンダ(情報)を含んでいません。これは、攻撃者に対して、かなり多くの OCSP レスポンダにリクエストを再送することを許すことになります。

一部の展開シナリオ (deployment scenarios) でキャッシングする HTTP の信頼は、中間サーバーの誤った構成やキャッシュ管理の欠陥などの原因により、予期せぬ結果に帰着するかもしれません。導入する側が、OCSP over HTTP を展開する際に、当事者は HTTP キャッシュ機構の信頼性を考慮に入れる ことを勧めます。

 

6.参考文献

[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).

 

7.著者のアドレス

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


付録A English

A.1 OCSP over HTTP English

この節は、HTTP をサポートするリクエストおよびレスポンスのフォーマットについて記述します。

A.1.1 リクエスト English

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のバイナリ値となります。

A.1.2 レスポンス English

HTTP ベースの OCSP レスポンスは、適切な HTTP ヘッダーと、その後ろに続く DER エンコード(符号化)された OCSPResponse のバイナリ値で構成されます。 Content-Type ヘッダーの値は「application/ocsp-response」となっています。 Content-Length ヘッダーはレスポンスの長さを指定する必要があります (SHOULD)。他の HTTP ヘッダーは存在する可能性がありますが(MAY)、リクエスタが理解不能であれば、無視される可能性があります(MAY)


付録B. OCSP in ASN.1 English

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


付録C. MIME登録 English

C.1 application/ocsp-request English

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>

C.2 application/ocsp-response English

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エディターのための資金は、インターネットソサエティーによって提供されています。