本節では、署名の長期利用を実現するための技術であるETSI TSの署名トーク ンについて分析を行う。ETSI TSは10種類の署名トークンを規定しており、これ らのうち6つの署名トークンが、署名を長期利用する際の署名トークンとして推 奨されている。前節で紹介したように、ETSI TSはIETFやW3C等の技術仕様と して規定されているほか、いくつかの商用サービスにも実装されているという実 績をもつ。しかし、署名トークンの実装手法についてはいくつかの研究成果が発 表されているものの（伊藤ほか[2004]、ECOM[2002]）、想定環境においてどのよ うな条件が満足されていれば各署名トークンが期待どおりの効果を発揮するか否 かに関しては、ETSI TSに記載されていない。
そこで、以下では、各署名トークンについて説明した後、ETSI TSにおいて想 定されているトラブルが実際に発生した状況のもとで、どのような条件が満足さ れるならばETSI TSの署名トークンが効果を発揮し、原理的に署名再検証が可能 となるのかを検討する。
(1) 想定環境
イ. エンティティ
ETSI TS
が想定する環境は、認証機関、利用者、検証者に加え、調停者（arbi-trator）、タイムスタンプ発行者（time-stamping authority）によって構成される。
調停者とタイムスタンプ発行者の役割は次のとおりである。
• 調停者: 利用者や検証者から中立的な立場にあり、利用者と検証者の間で署名の 有効性に関して主張の相違が発生した場合、第三者の立場から署名の再検証 を行うエンティティ。
• タイムスタンプ発行者: 署名トークンを構成するタイムスタンプを発行し、署名 トークン内のデータが特定の日時に存在したことを証明するエンティティ。
ロ．タイムスタンプに関する想定
ETSI TSの署名トークンに利用されるタイムスタンプとしては、デジタル署名
ベースのRFC3161（Adams, Cain et al.[2001]）に準拠したものが想定されている ほか、以下の想定が置かれている。
1. タイムスタンプ生成用のデジタル署名方式には、利用者が用いる署名生成鍵
よりも長い鍵長の署名生成鍵が用いられる、あるいは、相対的に安全なアル ゴリズムが採用される。
2. タイムスタンプ生成鍵は、厳重なセキュリティ管理のもとに置かれる。
3. 署名トークンに複数のタイムスタンプが含まれる場合、新しいタイムスタン プは古いタイムスタンプよりも高い安全性を有する、あるいは、異なるアル ゴリズムを採用する。
4. タイムスタンプ検証用の証明書の有効期限が切れる前に、あるいは、タイム スタンプの安全性が低下する前に、より安全な新しいタイムスタンプを署名 トークンに付与する。
このように、ETSI TSでは、タイムスタンプ生成鍵の管理が利用者の署名生成 鍵よりも厳重に管理されるケースを想定しているものの、後述するように、CA署 名生成鍵と同様にタイムスタンプ生成鍵も漏洩するという可能性を否定している わけではない。ただし、CA署名生成鍵とタイムスタンプ生成鍵が同時に漏洩する ケースは想定されていないため、以下では、認証機関の署名生成鍵が漏洩するタ イミングにおいて、タイムスタンプ生成鍵も同時に漏洩することはないと想定し て議論を進めることとする。
(2) 10 種類の署名トークン
イ．BES
BES（basic electronic signature）は、RFC3852（cryptographic message syntax、
Housley[2004]）の署名付きデータ（SignedData）に準拠した構成となっており、最 も基本的な署名トークンである（図9参照）。本署名トークンはETSI TSにおいて
「取扱いを可能とすることが必須」とされており、ETSI TS準拠の署名生成・検証 システムにおいてはBESを利用可能であることが求められている。
本署名トークンの「署名生成者情報」に含まれる「署名データ（signature）」は、
「署名の対象となる属性」から構成されるデータに対する利用者の署名である。ま た、「署名の対象となる属性」に含まれる「電子証明書識別子」は、利用者証明書 を特定するデータであり、利用者証明書を発行した認証機関を表わすデータ、利 用者証明書のシリアル番号、利用者証明書のハッシュ値から構成される。このた め、利用者証明書のハッシュ値も「署名データ（signature）」の対象となっている。
「ハッシュ関数識別子」については、「署名生成者情報」の外側と内側に組み込まれ ており、「署名生成者情報」の外側にある「ハッシュ関数識別子」には、当該PKI
において利用が可能とされるハッシュ関数の識別子のリストが格納される。これ に対して、「署名生成者情報」の内部にある「ハッシュ関数識別子」には、当該署 名トークン生成に用いられるハッシュ関数（1つ）の識別子が格納される。
(signature)
!"#%$&' ( )*+
(signature)
!"#%$&' ( )*+
( ),*+
(-. #/10 )
)*+ 2354768
(-. #/10 )
9:;<=
,%
(eContent)
>
?@A
!"#%$&'
B
C
/10
< =
( ),*+
(-. #/10 )
)*+ 2354768
(-. #/10 )
9:;<=
,%
(eContent)
>
?@A
!"#%$&'
B
C
/10
< =
,EDF ( )*+
eContent !"G#%$IH J@ A
,EDF ( )*+
eContent !"G#%$IH J@ A K?L PKIMINJOJP?QR%STU
VWYX?Z[]\%^_a`ab>cedf
g>h
fjikml
MnR%O]oqpr
VaWYXIZ[s\%^_`ab
図 9: BESの構成
ロ. EPES
EPES（explicit policy electronic signature）は、署名ポリシーの識別子をBES に追加したものであり、当該署名がどの署名ポリシーに準拠したものかを明示す る署名トークンである。署名ポリシーの識別子は、BESの「署名の対象となる属 性」に追加される（図10参照）。
! !
図 10: EPESの構成
ハ. ES-T
ES-T（electronic signature with time）は、BESあるいはEPESにタイムスタ ンプ（以下、TS-ESTと記す）を追加する署名トークンである。TS-ESTは「署名 データ（signature）」に対するタイムスタンプであり、署名データ（signature）は 電子証明書識別子に対して生成されるため、利用者証明書のハッシュ値に対して間 接的にタイムスタンプが付与されるかたちとなっている。TS-ESTには、RFC3161 に規定されるタイムスタンプ・トークン（TimeStampToken）が採用され、BESの
「署名の対象とならない属性」の部分に格納される（図11参照）。
TS-ESTは署名生成時点を推定するために署名トークンに付与されるものであ
り、ETSI TS には、利用者が署名生成直後にタイムスタンプ発行者から取得する ことが望ましいと記述されている。TS-ESTはデジタル署名によって実現されるこ とから、TS-ESTを検証する、すなわち、TS-ESTに含まれるタイムスタンプ発行 者のデジタル署名を検証する際には、タイムスタンプ発行者の電子証明書の有効 性等を検証する必要が出てくる。こうした検証に必要となるCA証明書やCRL等 のデータも、タイムスタンプ発行者のデジタル署名と同様にTS-ESTに格納され ることとなっている。
(signature)
(signature)
TS-EST TS-EST
! #"#$
(signature)%
&('()*$,+.-#/0$2143
図 11: ES-Tの構成
ニ. ES-C
ES-C（electronic signature with complete validation data references）は「認証 パス上に位置する電子証明書の参照データ」と「失効情報の参照データ」をES-T の「署名の対象とならない属性」に追加したものである（図12参照）。ただし、
「認証パス上に位置する電子証明書の参照データ」には、ルート認証機関（ETSI
TSにおいては“trusted CA”と記述されている）が発行する証明書の参照データも 含まれる扱いとなっているものの、「失効情報の参照データ」には、ルート認証機 関の証明書の失効情報は含まれないこととなっている点には留意が必要である。
「認証パス上に位置する電子証明書の参照データ」は、電子証明書のハッシュ値
（必須）と電子証明書の発行者を識別するデータ（オプション）から構成される。
「失効情報の参照データ」については、CRLの場合、CRLのハッシュ値（必須）、
CRL発行者の識別データ（以下、オプション）、発行日時、シリアル番号から構 成される。OCSPメッセージの場合、OCSPメッセージ生成者の識別データ（必 須）、生成日時（必須）、ハッシュ値（オプション）から構成される。また、CRL やOCSPメッセージ以外の形態で失効情報を格納することも可能となっている。
検証者は、ES-Cを用いることによって、認証機関のリポジトリに改めて問い合 わせすることなく「認証パス上に位置する電子証明書の参照データ」と「失効情 報の参照データ」を得ることができる。ただし、これらのデータが実際に保管さ れる具体的な場所や保管方法については記述されていない6。
失効情報については、ETSI TSでは、電子証明書の失効申請からCRLへの反映 までに一定のタイム・ラグが存在する可能性を考慮し、署名生成から一定時間が経 過した後にCRLを入手して署名トークンを形成することとされている。この「一 定期間」について具体的な記述はないが、CRLの場合では、署名生成後に新しく 更新されたCRLを入手するまでの期間に相当すると考えられる。
!"
#$%&(')+* ,-.
/0$12 !"
TS-EST
!"
#$%&(')+* ,-.
/0$12 !"
TS-EST
図 12: ES-Cの構成
6ETSI TSでは、“Storing the references allows the values of the certification path and the CRLs or OCSPs responses to be stored elsewhere, reducing the size of a stored electronic signature format”とのみ記述されている
ホ. ES-X Long
ES-X Long（extended long electronic signature）は、署名の長期利用の際に推 奨されている署名トークンの1つであり、認証パスを構成する電子証明書と失効 情報を署名トークンに組み込むことで、これらのデータを署名トークン以外から 入手困難なケースにも対応できるとされている。ES-X Longは、ES-Cの「署名の 対象とならない属性」の部分に、「認証パス上に位置する電子証明書」と「失効情 報」を組み込んだ形態となっている（図13参照）。
!#" $%&
'()+*
,+-,- +. / 0+12 !#" $%&
'()+*+. / 0+12
TS-EST
!#" $%&
'()+*
,+-,- +. / 0+12 !#" $%&
'()+*+. / 0+12
TS-EST
図 13: ES-X Longの構成
ヘ. ES-X Type1
ES-X Type1（extended electronic signature with time type1）も、署名の長期利 用の際に推奨されている署名トークンの1つであり、ES-Cにタイムスタンプ（以 下、TS-Type1と記す）を追加したものである（図14参照）。TS-Type1は、「署 名データ（signature）」、TS-EST、「認証パス上に位置する電子証明書の参照デー タ」、「失効情報の参照データ」に対して付与され、ES-Cの「署名の対象とならな い属性」に追加される。本署名トークンは、CA署名生成鍵が漏洩した場合、ある いは、漏洩したと疑われる場合に対応できるとされている。
ト. ES-X Type2
ES-X Type2（extended electronic signature with time type2）も、CA署名生成 鍵が漏洩した場合、あるいは、漏洩したと疑われる場合にも対応できるとされて いる署名トークンである。ES-X Type1との相違点はタイムスタンプの対象となる