RFC 3161 補足解説

internet(1) security(5) mechanisms(5) pkix(7) ad (48) timestamping (3)}

このSIA拡張のaccessLocationフィールドの値は、TSAへのアクセスに使われ る転送プロトコルを定義し、各転送プロトコルに依存した情報を含むかも知れな い(may)。

なお、その後公開されたRFC 3280では、以下のように記述されている。

RFC 3280より:

証明書主体者がタイムスタンプ・サービスを提供する場合、accessMethodフィ ールドにはid-ad-timeStamping OIDが使われる。

タイムスタンプ・サービスの提供方法によって、accessLocationフィールドは 以下のように定義される。

サービス提供方法 accessLocationのタイプ httpまたはftp URI(MUST)

e-mail rfc822Name(MUST) TCP/IP(ソケットベース) iPAddressまたはdNSName(may)

なお、他のPKIX仕様において追加のアクセス記述子が定義されるかも知れな い(may)。

TSAは、タイムスタンプ・サービスを提供するために、タイムスタンプ要求者 から送られてきたmessageImprintに対して(アルゴリズムおよびハッシュ長を除 き)無条件に署名行為を行なう。この署名鍵が、タイムスタンプ署名以外について も機械的な署名行為を行なわないことを保証するためには、(拡張)鍵用途を制限す ることによって明示すべきである。(拡張)鍵用途を制限しない場合、論理的には TSAのプライベート鍵はタイムスタンプ・サービス以外についても機械的な署名 行為が可能であり、利用者はそのような運用を実施している第三者を信頼すべき ではない。

3.1.6.2 certReqおよびorderingのエンコーディング

RFC 3161における転送プロトコルでは、いずれもタイムスタンプ・メッセー

ジをDERエンコードして処理することになっている。

この時に注意しなければならない点として、タイムスタンプ・リクエストにお けるcertReqおよびタイムスタンプ・レスポンスにおけるorderingがある。

両者は、いずれもデフォルト値をFALSEとするBOOLEAN型であり、その DERエンコードについては[X.690]の11.5節によると、「デフォルト値と等価なコ ンポーネントはエンコード対象には含めない」とされている。

つまりcertReqやorderingがFALSEである場合、バイナリ変換された後のデ ータには、certReqやorderingは含まれてはならない、ということになる。これ は変換されたバイナリデータの一意性を保つためである。

このため、RFC 3161に示される既知の4プロトコルにおいては、certReqは TRUEの場合のみバイナリデータ上に存在し、TRUEでない場合には実装上含ま れてはならない。

3.1.6.3 TSA証明書の失効検証

前述(3.1.4.1)でリストアップされたreasonCodeおよびkeyCompromiseが明示 されている場合についてトークンに対する処理方法が検討されているが、その他 のreasonCodeについて、十分な検討がなされていない。しかし、reasonCodeの 種類に関係なく、トークンに対する処理方法としては「署名されたあらゆるトー クンを無効とみなす」または「失効前に署名されたトークンのみ有効とする」の いずれかになるはずである。このため、RFC 3161で検討されていないreasonCode について、いずれの処理方法とすべきか明記する必要がある。

3.1.6.4 TSA証明書の失効検証とOCSPレスポンダ

RFC 3161ではCRLによる失効検証について考察しているが、TSA証明書の失 効検証にOCSPレスポンダを必要とする場合にも、同様にOCSPレスポンスにお いてもRevokedInfoを含めるべき(SHALL)である。

OCSPレスポンスにRevokedInfoが含まれない場合、そのTSAが生成した全て のトークンが無効とみなされるべき(SHALL)である。