>サイトトップへ >このカテゴリの一覧へ

X 5063-1

:2005(ISO/IEC 18014-1:2002)

(1) 

まえがき

この規格は,工業標準化法に基づいて,日本工業標準調査会の審議を経て,経済産業大臣が制定した日

本工業規格である。

制定に当たっては,日本工業規格と国際規格との対比,国際規格に一致した日本工業規格の作成及び日

本工業規格を基礎にした国際規格原案の提案を容易にするために,ISO/IEC 18014-1:2002,Information

technology

−Security techniques−Time-stamping services−Part1:Framework を基礎として用いた。

この規格の一部が,技術的性質をもつ特許権,出願公開後の特許出願,実用新案権,又は出願公開後の

実用新案登録出願に抵触する可能性があることに注意を喚起する。経済産業大臣及び日本工業標準調査会

は,このような技術的性質をもつ特許権,出願公開後の特許出願,実用新案権,又は出願公開後の実用新

案登録出願にかかわる確認について,責任はもたない。

JIS X 5063-1

には,次に示す附属書がある。

附属書 A(規定)タイムスタンピングのための ASN.1 モジュール

附属書 B(規定)暗号メッセージ構文抜粋

JIS X 5063

の原国際規格である ISO/IEC 18014 には,次に示す部編成がある。

ISO/IEC

18014-1

Information technology

−Security techniques−Time-stamping services−Part1:Framework

参考:この規格 JIS

X

5063-1

は,ISO/IEC

18014-1

の一致規格である。

ISO/IEC

18014-2 Information technology

−Security techniques−Time-stamping services−Part2:Mechanisms

producing independent tokens

ISO/IEC

18014-3 Information technology

−Security techniques−Time-stamping services−Part3:Mechanisms

producing linked tokens


X 5063-1

:2005(ISO/IEC 18014-1:2002)

(2) 

目  次

ページ

序文

1

1.

  適用範囲

1

2.

  引用規格

1

3.

  定義

3

3.1

  データ項目の表現(data items' representation

3

3.2

  タイムスタンピング機関,TSAtime-stamping authority, TSA

3

3.3

  タイムスタンピングサービス(time-stamping service

3

3.4

  タイムスタンプ要求者(time-stamp requester

3

3.5

  タイムスタンプトークン(time-stamp token

3

3.6

  タイムスタンプ検証者(time-stamp verifier

3

4.

    タイムスタンピングに関する一般的考察

4

4.1

  タイムスタンピング処理のエンティティ

5

4.2

  タイムスタンプ

5

4.3

  タイムスタンプの利用

6

4.4

  タイムスタンプトークンの検証

6

4.5

  タイムスタンピングに関連したサービス

6

5.

  関連するエンティティ間の通信

7

5.1

  タイムスタンプ要求処理

7

5.2

  タイムスタンプ検証処理

7

6.

  メッセージフォーマット

8

6.1

  タイムスタンプ要求

8

6.2

  タイムスタンプ応答

9

6.3

  タイムスタンプ検証

11

6.4

  拡張領域

11

附属書 A(規定)タイムスタンピングのための ASN.1 モジュール

13

附属書 B(規定)暗号メッセージ構文抜粋

19


     

日本工業規格

JIS

 X

5063-1

:2005

(ISO/IEC 18014-1

:2002

)

タイムスタンピングサービス−第 1 部:枠組み

Information technology

−Security techniques−Time-stamping

services

−Part1:Framework

序文  この規格は,2002 年に第 1 版として発行された ISO/IEC 18014-1:2002,Information technology−

Security techniques

−Time-stamping services−Part1:Framework を翻訳し,技術的内容及び規格票の様式を変

更することなく作成した日本工業規格である。

なお,この規格で点線の下線を施してある“参考”は,原国際規格にはない事項である。

1.

適用範囲  この規格は,次のことを規定する。

  1)タイムスタンピング機関の目的を明確にする。

  2)タイムスタンピングサービスが基礎とする一般モデルを記述する。

  3)タイムスタンピングサービスを定義する。

  4)タイムスタンピングの基本プロトコルを定義する。

  5)関連するエンティティ間のプロトコルを規定する。

備考  この規格の対応国際規格を,次に示す。

なお,対応の程度を表す記号は,ISO/IEC Guide 21 に基づき,IDT(一致している)

,MOD

(修正している)

,NEQ(同等でない)とする。

ISO/IEC 18014-1:2002

,Information technology−Security techniques−Time-stamping services−Part

1: Framework (IDT)

2.

  引用規格  次に掲げる規格は,この規格に引用されることによって,この規格の規定の一部を構成す

る。これらの引用規格は,発効年又は発行年を付記してあるものは,記載の年の版だけがこの規格の規定

を構成するものであって,その後の改正版・追補には適用しない。発効年又は発行年を付記していない引

用規格は,その最新版(追補を含む。

)を適用する。

JIS X 0301:2002

  情報交換のためのデータ要素及び交換形式−日付及び時刻の表記

備考  ISO 8601:2000, Data elements and interchange formats−Information interchange−Representation of

dates and times

からの引用事項は,この規格の該当事項と同等である。

JIS X 5056-1:2002

  セキュリティ技術−エンティティ認証−第 1 部:総論

備考  ISO/IEC 9798-1: 1997, Information technology−Security techniques−Entity authentication−Part 1:

General

が,この規格と一致している。

JIS X 5057-1:2003

  セキュリティ技術−ハッシュ関数−第 1 部:総論

備考  ISO/IEC 10118-1:2000, Information technology−Security techniques−Hash-functions−Part 1: General


2

X 5063-1

:2005 (ISO/IEC 18014-1:2002)

     

が,この規格と一致している。

JIS X 5057-2:2003

  セキュリティ技術−ハッシュ関数−第 2 部:n ビットブロック暗号を用いるハッシュ

関数

備 考   ISO/IEC 10118-2:2000, Information technology − Security techniques − Hash-functions − Part 2:

Hash-functions using an n-bit block cipher

  が,この規格と一致している。

JIS X 5057-4:2003

  セキュリティ技術−ハッシュ関数−第 4 部:剰余演算を用いるハッシュ関数

備 考   ISO/IEC 10118-4:1998, Information technology − Security techniques − Hash-functions − Part 4:

Hash-functions using modular arithmetic

  が,この規格と一致している。

JIS X 5058-1:1998

  セキュリティ技術−かぎ管理−第 1 部:枠組み

備考  ISO/IEC 11770-1: 1996, Information technology−Security techniques−Key management−Part 1:

Framework

が,この規格と一致している。

JIS X 5058-3:2000

  セキュリティ技術−かぎ管理−第 3 部:非対称暗号技術を用いるかぎ確立機構

備考  ISO/IEC 11770-3: 1999, Information technology−Security techniques−Key management−Part 3:

Mechanisms using asymmetric techniques

が,この規格と一致している。

JIS X 5061-2:2001

  セキュリティ技術−添付型ディジタル署名−第 2 部:識別情報に基づく機構

備考  ISO/IEC 14888-2: 1999, Information technology−Security techniques−Digital signatures with appendix

−Part 2: Identity-based mechanisms  が,この規格と一致している。

JIS X 5061-3:2001

  セキュリティ技術−添付型ディジタル署名−第 3 部:証明書に基づく機構

備考  ISO/IEC 14888-3: 1999, Information technology−Security techniques−Digital signatures with appendix

−Part 3: Certificate-based mechanisms  及び Corrigendum:1999 が,この規格と一致している。

ISO/IEC 8824-1:1998 | X.680: ITU-T Recommendation X. 680 (1997), Information technology

−Abstract Syntax

Notation One (ASN.1): Specification of basic notation

備考  JIS X 5605-1:1998  情報技術−抽象構文記法 1(ASN.1)仕様−第 1 部:基本記法の仕様は 1995

年版,追補 1:1996 及び正誤票 1:1996 と一致している。

ISO/IEC 8824-2:1998 | X.681: ITU-T Recommendation X. 681 (1997), Information technology

−Abstract Syntax

Notation One (ASN.1): Information object specification

備考  JIS X 5605-2:1998  情報技術−抽象構文記法 1(ASN.1)仕様−第 2 部:情報オブジェクト仕様は

1995

年版及び追補 1:1996 と一致している。

ISO/IEC 8824-3:1998 | X.682: ITU-T Recommendation X. 682 (1997), Information technology

−Abstract Syntax

Notation One (ASN.1): Constraint specification

備考  JIS X 5605-3:1998  情報技術−抽象構文記法 1(ASN.1)仕様−第 3 部:制約仕様は 1995 年版と一

致している。

ISO/IEC 8824-4:1998 | X.683: ITU-T Recommendation X. 683 (1997), Information technology

−Abstract Syntax

Notation One (ASN.1): Parameterization of ASN.1 specifications

備考  JIS X 5605-4:1998  情報技術−抽象構文記法 1(ASN.1)仕様−第 4 部:ASN.1 仕様のパラメータ

化は 1995 年版と一致している。

ISO/IEC 8825-1:1998 | X.690: ITU-T Recommendation X. 690 (1997), Information technology

−ASN.1 encoding

rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding

Rules (DER)

備考  JIS X 5606-1:1998  情報技術−ASN.1 符号化規則−第 1 部:基本符号化規則(BER),標準符号化


3

X 5063-1

:2005 (ISO/IEC 18014-1:2002)

     

規則(CER)及び識別符号化規則(DER)の仕様は 1995 年版及び正誤票:1996 と一致している。

ISO/IEC 10118-3:2004, Information technology

− Security techniques − Hash-functions − Part 3 :  Dedicated

hash-functions 

備考  JIS X 5057-3:2003  セキュリティ技術−ハッシュ関数−第 3 部:専用ハッシュ関数  は,1998 年版

と一致している。

ISO/IEC 15946-2, Information technology

−Security techniques−Cryptographic techniques based on elliptic

curves

−Part 2: Digital signatures

3.

定義  この規格で用いる主な用語の定義は,次による。

3.1

データ項目の表現(data items' representation)  暗号ハッシュ値のような,データ項目又はその表現。

3.2

タイムスタンピング機関,TSA(time-stamping authority,TSA)    タイムスタンピングサービスを提供

することを信託された信頼できる第三者機関。

3.3 

タイムスタンピングサービス(time-stamping service)  あるデータ項目が時間軸上のある点より前に

存在していた証拠を提供するサービス。

備考  データ項目の表現にタイムスタンプを追加し,その結果に署名することが,一つの例である。

3.4

タイムスタンプ要求者(time-stamp requester)  タイムスタンピングされることを求めるデータを所

有するエンティティ。

備考  要求者は,また,タイムスタンピング機関を含む信頼できる第三者機関であってもよい。

3.5

タイムスタンプトークン(time-stamp token)  データ項目の表現と時刻の値との間の,検証可能な暗

号化された結合を含むデータ構造。タイムスタンプトークンは,その結合の中に追加のデータ項目を含ん

でもよい。

3.6

タイムスタンプ検証者(time-stamp verifier)  データを所有し,そのデータに結合された有効なタイ

ムスタンプをもっていることの検証を要求するエンティティ。検証者自身又は信頼できる第三者機関が,

検証処理を行ってもよい。

  次の用語は,ISO/IEC 9798-1 で定義されたものを使用する。

エンティティ認証(entity authentication)  あるエンティティが主張されたエンティティであることを確認

すること。

参考  この定義は,ISO/IEC 9798-1 を要約して作成した JIS X 5056-1 の解説に記載している定義に一致

している。

  次の用語は,ISO/IEC 10118-1 で定義されたものを使用する。

衝突回避ハッシュ関数(collision-resistant hash-function)  次の特性を満足するハッシュ関数。同一の出力

を写像する二つの異なる入力を見付けることが計算量的に実行不可能である。

ハッシュ関数(hash-function)  あるビット列を,次の二つの重要な特性を満足する有限長のビット列に写

像する関数。第 1 の特性は,所定の出力のためにその出力に写像する入力を見付けることが計算量的に実

行不可能であること。第 2 の特性は,所定の出力のために同じ出力に写像する別の入力を見付けることが

計算量的に実行不可能であること。

ハッシュ値(hash value)  ハッシュ関数の出力であるビット列。

参考  これらの定義は,ISO/IEC 10118-1 を要約して作成した JIS X 5057-1 の解説に記載している定義


4

X 5063-1

:2005 (ISO/IEC 18014-1:2002)

     

に一致している。

  次の用語は,ISO/IEC 11770-1 で定義されたものを使用する。

証明機関(certification authority;CA)  公開かぎ証明書の作成及び割当てを信託されたセンタ。任意選択と

して,証明機関は,エンティティに対してかぎを作成し,割り当てることもできる。

プライベートかぎ(private key)  あるエンティティの非対称かぎの一対のうち,そのエンティティによっ

てだけ使用されるかぎ。

公開かぎ(public key)  あるエンティティの非対称かぎの一対のうち,公開されるかぎ。

公開かぎ証明書(public key certificate)  あるエンティティの公開かぎの情報で,証明機関によって署名さ

れ,それによって偽造できないようにしたもの。

シーケンス数(sequence number)  時間的に変化するパラメタで,その値は,特定の順序となっていて,

一定時間内に繰り返さないもの。

タイムスタンプ(time-stamp)  共通の参照時刻に関して,時間軸上の一点を示す,時間的に変化するパラ

メタ。

時間的に変化するパラメタ(time-variant parameter)  乱数,シーケンス数又はタイムスタンプのように,

メッセージが再使用攻撃(replay)ではないことを検証するために使用されるデータ。

参考  これらの定義は,ISO/IEC 11770-1 を要約して作成した JIS X 5058-1 の解説に記載している定義

に一致している。

  次の用語は,ISO/IEC 11770-3 で定義されたものを使用する。

ディジタル署名(digital signature)  データ単位に付加されるデータ又はデータ単位の暗号変換を施したデ

ータ。これによって,受信者に対してデータ単位の発信元及び完全性を保証し,送信者及び受信者に対し

て第三者による偽造からデータ単位を保護し,送信者に対して受信者による偽造から保護することができ

る。

信頼できる第三者機関,TTP (trusted third party,TTP)    セキュリティ関連の活動に関して,他のエンティテ

ィから信頼されるセキュリティ機関又はその代理者。

参考  これらの定義は,ISO/IEC 11770-3 を要約して作成した JIS X 5058-3 の解説に記載している定義

に一致している。

4.

タイムスタンピングに関する一般的考察  容易に変更可能な媒体で提供されるディジタルデータの使

用は,そのデータをいつ作成したか,又は最後にいつ変更したかといったことをどのように証明するかに

ついての問題を提起する。ディジタルタイムスタンピングは,時刻の正確さを証明するのに役立たなけれ

ばならない。ディジタルタイムスタンピングは,次の要求事項を満足しなければならない。

−  あるデータが時間軸上の特定の点より前に存在していた証拠を提供するためには,時間的に変化する

パラメタを,ねつ(捏)造不可能な方法でデータと結合させておかなければならない。

−  データは,それが開示されないような方法で提供されてもよい。

  現在使用されているタイムスタンピング方法は,データのハッシュ値にタイムスタンピングを施すこと

によって,これらの要求事項を満たす。これによって,完全性及び機密性を達成する。データそのものは

露呈しない。データのハッシュは,TSA によって暗号を使って現在の時刻の値と結合される。この結合は,

タイムスタンプの完全性及び真正性の証拠となる。これらの要素を提供するタイムスタンプトークンは,


5

X 5063-1

:2005 (ISO/IEC 18014-1:2002)

     

タイムスタンプの要求者へ送付される。

参考  機密性  アクセスを許可された(authorized)者だけが情報にアクセスできることを確実にするこ

と(JIS X 5080

完全性  情報及び処理方法が,正確であること及び完全であることを保護すること(JIS X 5080)。

真正性  対象又はリソースが要求されているものと同一であることを主張する特性。真正性は,

ユーザ,プロセス,システム,情報などのエンティティに対して適用する。

  タイムスタンプトークンは,また,以前に生成されたトークンに関連した情報を含んでもよい。ここで,

このタイムスタンプ要求以前のタイプスタンピングされたデータからのデータ表現及び追加情報は,この

タイムスタンピング処理に対する入力パラメタである。加えて,TSA は,その他のデータハッシュを含ん

だ後に,対象のデータが適時利用可能であった証拠として,タイムスタンピング処理に関する種々のデー

タ項目を公表してもよい。連続したハッシュの公表は,関連のデータが次に公表されたハッシュの前に存

在する証拠となる。このアプローチによって,検証者は他の機関に関与することなくタイムスタンプを検

証することができる。

4.1

タイムスタンピング処理のエンティティ  タイムスタンプが要求されたとき,次のエンティティを関

与させてもよい。

  例えば,あるエンティティは,時間軸上のある点における存在の証拠を示すような目的で,タイムスタ

ンピングされることを求めるデータを所有する。

このとき,

それはタイムスタンプ要求者として機能する。

また,あるエンティティは,受け取ったタイムスタンピングされたデータが有効なタイムスタンプである

証拠を得て,タイムスタンプ検証者として機能する。

  TSA は,タイムスタンピングサービスを提供する。このサービスの性質は,データの有効性,特にこの

データに関係した暗号を使った要素の有効性を特定する手助けのために非常に重要となる。その TSA は,

データが時間軸上のある点に存在することの証拠を提供し,時間のパラメタの正確さを保証する。

  導入されたすべてのエンティティは,双方向のハンドシェイクプロトコルで通信する。そのことは,あ

るエンティティが TSA に要求を送り,タイムスタンプを得ること(詳細は 5.1 及び 5.2 参照)を意味する。

トークンは,エンティティが時間軸上のある点よりも後の時刻でトークンを検証することを許す,十分な

情報を含んでいる。

4.2

タイムスタンプ  タイムスタンプは,時間軸上の特定の点におけるデータの存在の証拠を与えるため

に使われる。これは,データ項目の表現とタイムスタンプとを暗号を使って結合することによって行って

もよい。

  タイムスタンピングされたデータは,後に再度,タイムスタンプが押されてもよい。例えば,次の理由

から必要になってもよい。

  1)  データに時刻の値を結合するために使われる暗号プリミティブが,その運用の有効期限が間もなく

切れるため(例えば,TSA の署名かぎは失効する直前である。

  2)  TSA は,別の TSA によってすぐに置き換えられるため。

  3)  要求者のハッシュアルゴリズムが問題となることがあるため。

  したがって,それぞれの TSA によってタイムスタンピングされたデータは,上のいずれかの条件に及ぶ

前に,タイムスタンプの再発行を受けることがある。このようにして,既存のタイムスタンプの有効期間

が延長される。

  時刻,ハッシュ値及び他の運用パラメタを合わせて結合するのに使われる暗号プリミティブが有効期限

に達する前に,データは改めてタイムスタンピングされてもよい。そのとき生成されたタイムスタンプは,


6

X 5063-1

:2005 (ISO/IEC 18014-1:2002)

     

そのデータに関連付けられた前のタイムスタンプとはつながりのない新しいタイムスタンプとなり,タイ

ムスタンプの再発行と呼ばれる。

  また,タイムスタンプの再発行は,初期のデータからのハッシュ値を形成するために使われるハッシュ

関数が問題となるときに必要となることがある。この場合,古いタイムスタンプトークン及び原データは

共に,タイムスタンプの再発行のために提出され,新しく計算されたハッシュ値に含まれなければならな

い。

  タイムスタンピングサービスは,オンラインでも,オフラインでも運用することができる(例えば,蓄

積交換プロトコル)

。その区別は,関係するエンティティ間の通信プロトコルの伝送レベルでなされる。

4.3

タイムスタンプの利用  タイムスタンプは,電子文書が作成,変更又は署名された時点の正確な時刻

を表さない。TSA が暗号を使って署名された文書のハッシュに時刻の値を結合するのに対して,タイムス

タンピングの対象となる文書を提供するエンティティは,TSA とは独立に文書に署名してもよい。

  利用できる唯一の証拠は,含まれるタイムスタンプが押される以前に文書が存在したことである。

  また,タイムスタンプは,署名された文書の有効性に重要な役割を果たす。タイムスタンピング及びデ

ータの署名の発生については,時間的に,三つの異なる可能性がある。タイムスタンプの要求者がデータ

に署名する前,文書の送り手の署名がなされた後及び署名の前後に,データはタイムスタンピングされる

ことがある。これによって署名の時間的有効性を調査したときに異なる結果が導かれる。

表 は,これら

の可能性を示す。

表 1  署名及びタイムスタンプの時間的配置

ケース 1 t

1

 TSA

がタイムスタンプを生成する。

 s

要求者は提供されたタイムスタンプと一緒にデータに署名する。

ケース 2 s

要求者はデータに署名する。

t

2

 TSA

は署名されたデータにタイムスタンプ処理する。

ケース 3 t

1

 TSA

はタイムスタンプを生成する。

 s

要求者は提供されたタイムスタンプと一緒にデータに署名する。

t

2

 TSA

は署名されたデータにタイムスタンプ処理する。

  ケース 1(署名は,タイムスタンプを含む。

)は,データが署名された時刻を正確には定義しない。デー

タがタイムスタンピングされた後で署名されたことを示している。ケース 2 は示された時刻以前にデータ

が署名されたことを表す。ケース 3 は文書が署名された期間を定義する。

4.4

タイムスタンプトークンの検証  タイムスタンプトークンを検証するとき,最初にタイムスタンプに

含まれる時刻の値を評価し,それからタイムパラメタを含んだタイムスタンプトークンの有効性を検証す

る。タイムスタンプの有効性は,タイムスタンプトークンの正確さを評価することによって検証する。又

は,タイムスタンプトークンの正確さの評価は,信頼される第三者機関(TTP)に任されてもよい。

4.5

タイムスタンピングに関連したサービス  タイムスタンピングと関連する次の二つの基本的な運用

がある。

−  時刻の値をデータ値に暗号を使って結合する,タイムスタンピング処理

−  暗号を使った結合の正確さを評価する,タイムスタンプ検証処理

  TSA は,タイムスタンピングサービスを提供するが,一方,タイムスタンプ検証処理は,他の信頼され

る機関と関連してもよい。

  提供された時刻は,正確であるという一般的な要求条件を満足しなければならない。TSA のために時刻


7

X 5063-1

:2005 (ISO/IEC 18014-1:2002)

     

を与えるサービスは,この規格の適用範囲外とする。

5.

関連するエンティティ間の通信  タイムスタンピング処理に関係するエンティティは,一方がタイム

スタンプを要求する又はタイムスタンプを検証する,そのいずれかのエンティティであり,もう一方が一

か所以上の TSA である。これらのエンティティ間の処理を 5.1 及び 5.2 に示す。

5.1

タイムスタンプ要求処理  タイムスタンプを要求する場合におけるエンティティ(要求者)と TSA

との間の通信は,次のステップからなる。

要求者は,タイムスタンピングされることになっているデータのためにハッシュ値を生成する。ハッシ

ュを生成するために,ISO/IEC 10118-2:1998,ISO/IEC 10118-3又はJIS X 5057-4に規定された機構を用いて

もよい。

  1)  タイムスタンプの要求メッセージが,次のデータを含めてTSAに送られる。

  −  ハッシュ値

  −  用いられたハッシュアルゴリズム

  −  ノンス(nonce)

なお,最初の二つのパラメタだけが必す(須)であり,3番目の値は任意選択とする。

参考  ノンスとは,メッセージが古いメッセージの再使用攻撃(replay)ではないことを保証するために

利用されるパラメタで,一度だけ使用される数値をいう。

  2)  TSAは,受け取った要求の完全さを確認する。

  3)  TSAは,タイムスタンプ(タイムスタンプトークン)を生成する。タイムスタンプは,次を含むデ

ータ構造となる。

  −  生成した又は確かな出所から受け取った時間パラメタ

  −  要求者によって配られたデータ

    −  ハッシュ値,ハッシュアルゴリズム及び任意選択であるノンスに,暗号を使って時刻の値を結合

するためにTSAによって生成されたデータ

  暗号を使った結合にディジタル署名が用いられる場合,TSAは,JIS X 5061-3:2001及びISO/IEC

15946-2

に規定された暗号アルゴリズムを用いてもよい。

  4)  TSAは,タイムスタンプトークンを要求するエンティティに戻す。

  5)  エンティティは,受け取ったタイムスタンプトークンの完全さ及び正確さを直ちに確認してもよい

し,又は最終的に信頼できる機関に確認させてもよい。

    要求者とTSAとの間の通信を

図  1に示す。

    なお,図中の番号は,上記の1)∼5)を指している。

                                  5                                          2,3

                                            4

                                                           1

図 1  要求者と TSA との間の通信

5.2

タイムスタンプ検証処理  独立したトークン生成機構を用いて生成されたトークンの検証には,単一

のタイムスタンプトークンに含まれる情報を利用する。検証作業を完了するため,機構が必要とする追加

情報を検証者に要求してもよい。検証作業は,要求しているエンティティが行ってもよいし,又は別のTTP

要求者

TSA


8

X 5063-1

:2005 (ISO/IEC 18014-1:2002)

     

がエンティティに代わって行ってもよい。

連結されたトークン生成機構を用いて生成されたトークンの検証には,単一のタイムスタンプトークン

と,おそらくTSAによって生成された別のトークンとに含まれる情報を利用する。検証作業を完了するた

め,機構が必要とする追加情報を検証者に要求してもよい。検証作業は,要求しているエンティティが行

ってもよいし,又は別のTTPがエンティティに代わって行ってもよい。

追加情報に関しては,この規格群の第 2 部(

ISO/IEC 18014-2

)及び第 3 部(

ISO/IEC 18014-3

)に規定

する。

6.

メッセージフォーマット  5.に示す処理を開始させるために必要なメッセージには,タイムスタンピン

グの要求者又は検証者からTSAへのメッセージ,TSAから要求者又は検証者へのメッセージの,2種類があ

る。すべてのメッセージは,ASN.1記法で記述する。完全なASN.1モジュールを

附属書Aに示す。サービス

の種類に対応して,異なるメッセージの型が規定されている。

6.1

タイムスタンプ要求  TimeStampReq  メッセージは,エンティティがタイムスタンピング機関に対し

タイムスタンピングサービスを要求するために用いられる。TimeStampReq  メッセージは,次のとおりに

形成する。

TimeStampReq ::= SEQUENCE {

version

Version,

messageImprint MessageImprint,

reqPolicy TSAPolicyId

       OPTIONAL,

nonce

INTEGER

        OPTIONAL,

certReq

BOOLEAN

        DEFAULT FALSE,

extensions [0]

Extensions

      OPTIONAL

}

次の表は,変数及びその値について説明する。

データフィールド

説明

version

構文の版数

messageImprint

サービス提供者が時刻の値を結合することになっている messageImprint

reqPolicy

タイムスタンプトークンを発行する TSA から要求されたサービス方針

nonce

特定の要求を表す。この値の目的は,特定の要求をそれぞれの応答に結び付けること
である。

certReq

このデータフィールドが存在して,値が真(true)の場合,証明書情報を提供するよ
うに TSA に求める。

extensions

要求されたタイムスタンピングの操作を適切に遂行するために必要な拡張を含む。

MessageImprint

タイプは,メッセージの押印を生成するために用いられたアルゴリズムを示すほかに,メ

ッセージの押印データをカプセル化するために用いられる。

MessageImprint ::=  SEQUENCE {

hashAlgorithm

  DigestAlgorithmldentifier,

hashedMessage

  OCTET STRING

}


9

X 5063-1

:2005 (ISO/IEC 18014-1:2002)

     

データフィールド

説明

hashAlgorithm

ハッシュアルゴリズム識別子及びパラメタ値

hashedMessage

hashAlgorithm

データフィールドで指定したハッシュ関数を用いて計算された,タイ

ムスタンピングされることになっているメッセージに対応するハッシュ値。

ハッシュ関数は,衝突回避ハッシュ関数でなければならない。

TSAPoIicyId

は,次のように定義される。

TSAPolicyId ::=  POLICY.&id({TSAPolicies})

6.2

タイムスタンプ応答  タイムスタンプの要求に対する応答は,TimeStampResp  データ構造となる。そ

れは,次のように表現される。

TimeStampResp ::=  SEQUENCE {

status

PKIStatusInfo,

timeStampToken TimeStampToken     OPTIONAL

}

TimeStampToken

構造は,次のように定義される。

TimeStampToken ::=  SEQUENCE {

contentType     CONTENT.&id({Contents}),

content        [0] EXPLICIT CONTENT.&Type ({Contents}{@contentType})

}

この構造は,TSTInfo  構造をカプセル化するために用いられる。TSTInfo  構造は,次のように定義され

る。

TSTInfo ::= SEQUENCE {

version

 Version,

policy

 TSAPolicyId,

messageImprint   MessageImprint,

serialNumber

 SerialNumber,

genTime

GeneralizedTime,

accuracy

 Accuracy                    OPTIONAL,

ordering

  BOOLEAN                                    DEFAULT FALSE,

nonce

  Nonce                                            OPTIONAL,

tsa

 [0] EXPLICIT GeneralName    OPTIONAL,

extensions

[1] Extensions                                  OPTIONAL

}

次の表は,まだ定義されていないデータフィールドについて説明する。


10

X 5063-1

:2005 (ISO/IEC 18014-1:2002)

     

データフィールド

説明

accuracy

協定世界時(UTC)と比較される,genTime フィールドの精度

genTime TSA

がタイムスタンプトークンに含めた時間

serialNumber

このフィールドは,TSA によって各 TimeStampToken に割り当てられた整数値である。

TSA

を一つ決めれば,この整数値は,発行された TimeStampToken ごとに唯一の値で

なければならない。

参考  協定世界時(Coordinated universal time,UTC)  国際度量衡局(BIPM)及び国際地球回転観測事業(IERS)に

よって維持管理されている時間尺度。標準周波数及び時刻信号に関する標準電波の基礎となるもの(JIS X 0301

TSTInfo

構造は,TSAにおける実現に適切な ContentInfo のカプセル化手法を用いることで TimeStamp

Token

構造にカプセル化される。

EncapsulatedContentInfo

構造を用いて ContentInfo 構造にカプセル化され

た場合,eContentType  のフィールドは,次のオブジェクト識別子を含む。

id-ct-TSTInfo OBJECT IDENTIFIER ::= {

iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 4

}

さらに,eContent  フィールドは,オクテット列としてDERコード化された TSTInfo 構造を含む。

GenerallzedTime

は,JIS X 0301で規定する,完全表記による暦日付の基本フォーマット及び協定世界時

の基本フォーマットの組合せである。この形式は,次の書式となる。

参考  完全表記  表現に関連したすべての日付及び時間の要素を含む表記(JIS X 0301)。

暦日付  暦年,暦月及び暦月の中の序数によって指定される特定の日の日付(JIS X 0301)。

YYYYMMDDhhmmss[.ff]Z

最後の文字を除く個々の文字は,一けたの数字を意味する。

  YYYYは,暦年(0000-9999)を表す。

  MMは,実際の月(01-12)を表す。

  DDは,その月における実際の日(01-31)を表す。

  hhは,その日における実際の時(00-23)を表す。

  mmは,その時における実際の分(00-59)を表す。

  ssは,その分における実際の秒(00-59)を表す。

  ffは,1秒未満の端数を表す。

  Zという文字は,協定世界時(UTC)を表す。

Accuracy ::= SEQUENCE {

seconds

      INTEGER                    OPTIONAL,

millis

[0] INTEGER (1..999)   OPTIONAL,

micros

[1] INTEGER (1..999)   OPTIONAL

}

(ALL EXCEPT ({- none; at least one component shall be present - }))


11

X 5063-1

:2005 (ISO/IEC 18014-1:2002)

     

6.3

タイムスタンプ検証  検証プロトコルは,タイムスタンプの要求プロトコルと似ており,要求メッセ

ージ(VerifyReq)とそれに対する応答(VerifyResp)とからなる。これには,次のデータ構造が適用され

る。

VerifyReq ::= SEQUENCE {

version

         Version,

tst

TimeStampToken,

requestID

[0] OCTET STRING     OPTIONAL

}

VerifyResp ::= SEQUENCE {

  Version

Version,

  status                    PKIStatusInfo,

  tst

TimeStampToken,

  requestID

[0] OCTET STRING     OPTIONAL

}

  requestIDのフィールドは,要求をそれに対する応答に結び付ける。

6.4

拡張領域

ExtHash 

拡張

  タイムスタンピングサービスの要求者は,単一のデータ項目から得られた一つ以上のハッシュ値をタイ

ムスタンピングのために提示することを要求してもよい。

  異なるハッシュ関数を用いて単一のデータ項目から得られた複数のハッシュ値を提示することによって,

要求者は,生成されたタイムスタンプトークンを,いずれかのハッシュ関数の問題から保護することがで

きるようになる。

  複数のハッシュ値の提示を可能にするために,次のような拡張が定義される。

ExtHash ::=    SEQUENCE SIZE (1 ..MAX) OF MessageImprint

tsp-ext-hash ::=    OBJECT IDENTIFIER { tsp-ext I }

extHash EXTENSION ::= {

SYNTAX ExtHash IDENTIFIED BY tsp-ext-hash

}

  この拡張は,要求者によってTSAに送られるTimeStampReqメッセージの“extensions”フィールドに格納

されるとともに,この結果,TSAによって作成されるTimeStampToken構造の“extensions”フィールドに格

納され,要求者に戻される。

  この拡張が存在し,かつ,TSAがそれを処理することができる場合,TSAは,messageImprintsフィールド

で指定されたタイムスタンプの要求メッセージのハッシュ値とこの拡張の中に含まれる複数のハッシュ値

との両方を,結果として生じるタイムスタンプトークンに割当てる時刻の値に,暗号を使って結合しなけ

ればならない。


12

X 5063-1

:2005 (ISO/IEC 18014-1:2002)

     

ExtMethod 

拡張

  タイムスタンピングサービスの要求者は,タイムスタンプトークンを作成するときに使用するタイムス

タンピング方法を特定の TSA に指示することを要求してもよい。要求者が特定の TSA にタイムスタンプ

トークンの作成に使用するタイムスタンピング方法を指示できるように,次のような拡張が定義される。

Method ::=  METHOD.&id ({Methods})

ExtMethod ::=    SEQUENCE SIZE (1 ..MAX) OF Method

tsp-ext-meth ::=    OBJECT IDENTIFIER { tsp-ext 2}

extMethod EXTENSION ::=    {

SYNTAX ExtMethod IDENTIFIED BY tsp-ext-meth

}

  この拡張は,要求者によってTSAに送られるTimeStampReqメッセージの“extensions”フィールドに格納

されるとともに,この結果,TSAによって作成されるTimeStampToken構造の“extensions”フィールドに格

納され,要求者に戻される。

  この拡張が存在し,かつ,TSAがそれを処理することができる場合,TSAは,指定された方法について

要求を満たそうとするか,又はその方法が利用可能でないことを示す誤り(error)を返そうと試みなけれ

ばならない。要求者が一つ以上の可能な方法を挙げた場合,TSAは,タイムスタンプトークンの作成に使

用するために挙げられた方法の一つを選択してもよい。この拡張が存在しない場合,TSAは,デフォルト

のタイムスタンピング機構を用いる。


13

X 5063-1

:2005 (ISO/IEC 18014-1:2002)

     

附属書 A(規定)タイムスタンピングのための ASN.1 モジュール

  この附属書は,タイムスタンピングのためのASN.1モジュールを規定する。

このモジュールは,現行のASN.1規格に基づき,ITU-TのASN.1プロジェクトによって使用された信頼で

きる構文チェッカで合格した正式なASN.1を含んでいる。

TimeStampProtocol {

iso(1) standard(0) time-stamp(18014) modules(0) tsp(1 )}

DEFINITIONS IMPLICIT TAGS ::= BEGIN

-- EXPORTS All; --

IMPORTS

-- ISO/IEC 9594-8 | ITU-T Rec. X.509 AuthenticationFramework --

EXTENSION, Extensions

FROM AuthenticationFramework {

joint-iso-itu-t ds(5) module(1) authenticationFramework(7) 4 }

-- ISO/lEC 9594-8 | ITU-T Rec. X.509 CertificateExtensions --

GeneralName

FROM CertificateExtensions {

joint-iso-itu-t ds(5) module(1) certificateExtensions(26) 4 }

AuthenticatedData, SignedData

FROM CryptographicMessageSyntax {

iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) };

time-stamping-services OBJECT IDENTIFIER ::=    { iso(1) standard(0) time-stamp(18014) }

modules OBJECT IDENTIFIER ::=    { time-stamping-services modules(0) }

extensions OBJECT IDENTIFIER ::=    { time-stamping-services extensions(1) }

TimeStampReq ::= SEQUENCE {

version                    Version,

messageImprint   MessageImprint,

reqPolicy                TSAPolicyId            OPTIONAL,

nonce                      Nonce                      OPTIONAL,

certReq                    BOOLEAN            DEFAULT FALSE,

extensions       [0] Extensions     OPTIONAL

}

MessageImprint ::= SEQUENCE {

hashAlgorithm       DigestAlgorithmIdentifier,

hashedMessage              OCTET STRING

}


14

X 5063-1

:2005 (ISO/IEC 18014-1:2002)

     

DigestAlgorithmIdentifier AlgorithmIdentifier ::=    AlgorithmIdentifier {{ DigestAlgorithms }}

DigestAlgorithms ALGORITHM ::=  {

{OID sha1 PARMS NULL},

--

…-- Expect additional digest algorithms --

}

TSAPolicyId ::=  POLICY.&id({TSAPolicies})

TSAPolicies POLICY ::=    {

--

…-- Any supported TSA policy --

}

TimeStampResp ::=                SEQUENCE {

status                                    PKIStatusInfo,

timeStampToken                  TimeStampToken        OPTIONAL

}

PKIStatusInfo ::=    SEQUENCE {

status                                    PKIStatus,

statusString                          PKIFreeText                OPTIONAL,

failInfo                                  PKIFailureInfo            OPTIONAL

}

PKIStatus ::= INTEGER {

granted                                  (0),        -- the request is completely granted

grantWithMods                      (1),

  -- modifications were necessary, the requester is responsible for asserting the differences

rejection                                (2),

  -- the request could not be fulfilled, the failure code delivers additional information

waiting                                  (3),

  -- the request is not processed, the requester receives a receipt that the request has been received

revocationWarning        (4),   -- a revocation is imminent

revocationNotification      (5)   -- notification that a revocation has been occurred

}

PKIFreeText::=    SEQUENCE SIZE(1..MAX) OF UTF8String

PKIFailureInfo ::= BIT STRING {

badAlg                 (0),    -- unrecognized or unsupported Algorithm Identifier

badRequest              (2),    -- transaction not permitted or supported

badDataFormat           (5),    -- data submitted has the wrong format

timeNotAvailable         (14),   -- the TSAs service is not available

unacceptedPolicy         (15),   -- the requested TSA policy is not supported

unacceptedExtension      (16),   -- the requested TSA extension is not supported,

addInfoNotAvailable      (17),   --the requested additional information is not available,


15

X 5063-1

:2005 (ISO/IEC 18014-1:2002)

     

systemFailure                        (25)        -- System Failure

}

TimeStampToken ::= SEQUENCE {

contentType   CONTENT.&id({Contents}),

content       [0] EXPLICIT CONTENT.&Type({Contents}{@contentType})

}

Contents CONTENT ::= {

time-stamp-mechanism-signature  |

time-stamp-mechanism-MAC    |

time-stamp-mechanism-archival,

--

…-- Expect additional time-stamp mechanisms --

}

-- Time-stamp mechanism information objects --

time-stamp-mechanism-signature CONTENT ::=

{ SignedData IDENTIFIED BY id-signedData }

time-stamp-mechanism-MAC CONTENT ::=

{ AuthenticatedData IDENTIFIED BY id-ct-authData }

time-stamp-mechanism-archival CONTENT ::=

{ ETSTInfo IDENTIFIED BY id-data }

ETSTInfo ::=

OCTET STRING (CONTAINING TSTInfo ENCODED BY der)

TSTInfo ::=  SEQUENCE {

version                      Version,

policy                        TSAPolicyId,

messageImprint        MessageImprint,

serialNumber      SerialNumber,

genTime                    GeneralizedTime,

accuracy          Accuracy                  OPTIONAL,

ordering                    BOOLEAN                                  DEFAULT FALSE,

nonce                        Nonce                                          OPTIONAL,

tsa                              [0] EXPLICIT GeneralName      OPTIONAL,

extensions                  [1] Extensions                            OPTIONAL

}

Version ::= INTEGER {vl(1)}

SerialNumber ::= INTEGER    -- Expect large values

Accuracy ::= SEQUENCE {

seconds            INTEGER                      OPTIONAL,

millis     [0] INTEGER(1..999)     OPTIONAL,

micros        [1] INTEGER(1..999)          OPTIONAL }


16

X 5063-1

:2005 (ISO/IEC 18014-1:2002)

     

(ALL EXCEPT({-- no components present --}))

Ordering ::= BOOLEAN

Nonce ::= INTEGER -- Expect large values

-- Time-stamping extensions --

TSExtensions EXTENSION::=  {

extHash    |

extMethod,

--

…-- Expect additional extensions –

}

extHash EXTENSION ::= {SYNTAX ExtHash IDENTIFIED BY tsp-ext-hash}

ExtHash ::= SEQUENCE SIZE(1..MAX) OF MessageImprint

extMethod EXTENSION ::= {SYNTAX ExtMethod IDENTIFIED BY tsp-ext-meth}

ExtMethod ::= SEQUENCE SIZE(1..MAX) OF Method

Method ::= METHOD.&id({Methods})

Methods METHOD ::= {

--

…--Any time-stamping method --

}

EncapsulatedContentInfo::= SEQUENCE {

eContentType     CONTENT.&id({EContents}),

eContent                  [0] EXPLICIT

CONTENT.&Type({EContents}

{@eContentType})

}

EContents CONTENT ::= {

{ ETSTInfo IDENTIFIED BY id-ct-TSTInfo},

--

...        --Expect additional content types --

}

-- Supporting definitions

AlgorithmIdentifier { ALGORITHM:IOSet } ::= SEQUENCE {

algorithm  ALGORITHM.&id({IOSet}),

parameters  ALGORITHM.&Type({IOSet}{@algorithm}) OPTIONAL

}

ALGORITHM ::= CLASS {

&id    OBJECT IDENTIFIER UNIQUE,

&Type  OPTIONAL


17

X 5063-1

:2005 (ISO/IEC 18014-1:2002)

     

}

WITH SYNTAX {OID &id [PARMS &Type]}

CONTENT::=  TYPE-IDENTIFIER   -- ISO/IEC 8824-2, Annex A

OIDS ::= CLASS {

&id OBJECT IDENTIFIER UNIQUE

}

WITH SYNTAX { OID &id }

POLICY ::= OIDS -- Supported TSA policies

METHOD ::= OIDS -- TSA Methods

-- Information object identifiers

--

tsp-ext-hash OBJECT IDENTIFIER ::= { extensions hash(1) }

tsp-ext-meth OBJECT IDENTIFIER::= { extensions meth(2)}

der OBJECT IDENTIFIER ::= {

joint-iso-itu-t asn1 (1) ber-derived(2) distinguished-encoding(1) }

sha1 OBJECT IDENTIFIER ::= {

iso(1) identified-organization(3) oiw(14) secsig(3) 2 26 }

pkcs7 OBJECT IDENTIFIER ::= {

iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7)

}

  id-data OBJECT IDENTIFIER ::= {

pkcs7 data(1) }

id-signedData OBJECT IDENTIFIER ::= {

pkcs7 signedData(2) }

id-ct-authData OBJECT IDENTIFIER ::= {

iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)

pkcs-9(9) smime(16) ct(1) 2 }

id-ct-TSTInfo OBJECT IDENTIFIER ::= {

iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)

pkcs-9(9) smime(16) ct(1) 4 }

-- verification of a timestamp token

VerifyReq ::= SEQUENCE {

version      Version,

tst                    TimeStampToken,

requestID    [0] OCTET STRING OPTIONAL

}

VerifyResp ::= SEQUENCE {

version     Version,

status      PKIStatusInfo,

tst                  TimeStampToken,


18

X 5063-1

:2005 (ISO/IEC 18014-1:2002)

     

requestID   [0] OCTET STRING OPTIONAL

}

END -- TimeStampProtocol –


19

X 5063-1

:2005 (ISO/IEC 18014-1:2002)

     

附属書 B(規定)暗号メッセージ構文抜粋

  この附属書は,RFC 2630 CMS Cryptographic Message Syntax(暗号メッセージ構文)の一部分であり,タ

イムスタンピングに要求されるコンテントタイプを規定する。この附属書は,RFC 2630 の定義を使用して,

記述している。Abstract Syntax Notation One(ASN.1)構文は,本体の 2.で引用する規格を利用する。

B.1

序文  この附属書は,暗号メッセージ構文について記述する。この構文は,電子署名,ダイジェスト

作成,認証又は任意のメッセージの暗号化に使われる。

  暗号メッセージ構文は,データ保護のためのカプセル化構文を記述し,電子署名,メッセージ認証符号

及び暗号化の機能をもつ。この構文は,多重のカプセル化を許容するので,一つのカプセルが他のカプセ

ルに入れ子になっていることがあり得る。同様に,一つの機関が,既にカプセル化されたあるデータに電

子署名を付与することも可能である。例えば,メッセージコンテントに並べて,署名時刻のような任意の

属性に署名することも許容するし,署名に関連付けられた連鎖署名のような他の属性を与えることも許容

する。

  例えば,暗号メッセージ構文は, PKIX ワーキンググループが定義したかぎ管理のように,証明書に基

づくかぎ管理の多様なアーキテクチャの機能をもつ。

  暗号メッセージ構文の値は,ASN.1 を使い,BER(Basic Encoding Rules:基本符号化規則)符号化及び

DER

(Distinguished Encoding Rules:識別符号化規則)符号化を使って,生成される。値は,通常,オクテ

ット列として表現される。多くのシステムでは任意のオクテット列を確実に転送できるが,多くの電子メ

ールシステムではそうではないことがよく知られている。この附属書では,そのような環境で確実な転送

をするためのオクテット列符号化機構は扱わない。

B.2

総論  暗号メッセージ構文(CMS)は,たくさんのコンテントタイプに対応するように十分に一般

化されている。この附属書では,一つの保護コンテントである ContentInfo を定義する。ContentInfo は,識

別されたコンテントタイプをカプセル化し,

識別されたコンテントタイプは更にカプセル化をしてもよい。

附属書のこの箇条では,データ及び署名付きデータ(signed data)の二つのタイプを定義する。

  一般的な設計思想として,不定長の基本符号化規則(BER)を使って,それぞれのコンテントタイプは,

単一パス処理することができる。特に,単一パス操作は,コンテントが大きい場合,テープに格納される

場合又は他のプロセスからパイプライン処理される場合に役立つ。単一パス操作には,一つの顕著な欠点

がある。すなわち,種々の成分の長さをあらかじめ知ることができないので,単一パスで識別符号化規則

(DER)を使って符号化処理することが難しい。しかし,署名付きデータに含まれる署名付きの属性は,

DER

符号化を必要とする。署名付き属性は,受信者が一つ以上の認識できない属性をもつコンテントを検

証することを確実にするために,DER形式で転送されなければならない。署名付き属性は,DER符号化を

必要とするCMSデータタイプである。

B.3

一般構文  暗号メッセージ構文(CMS)は,コンテントタイプ識別子をコンテントに関連付ける。

構文は,ASN.1 タイプ ContentInfo を使用しなければならない。


20

X 5063-1

:2005 (ISO/IEC 18014-1:2002)

     

ContentInfo ::= SEQUENCE {

 ContentType

CONTENT.&id({Contents}),

content [0] EXPLICIT CONTENT.&id

({Contents}{@contentType })}

ContentInfo

の領域は,次の意味をもっている:

データ領域

記述

contentType

関連付けられたコンテントのタイプ。これはオブジェクト識別子であり,このコンテントタ
イプを定義した機関によって割り当てられた一意に定まる整数列である。

content

関連付けられたコンテント。コンテントのタイプは,ContentType によって一意に定められ
る。有効な型は,データ又は署名付きデータである。

B.4

データのコンテントタイプ  次のオブジェクト識別子は,データのコンテントタイプを識別する。

id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)

rsadsi(113549) pkcs(1) pkcs7(7) 1}

  データのコンテントタイプは,ASCII のテキストファイルのような,任意のオクテット列を参照するこ

とを意図しており,解釈はアプリケーションに委ねられている。そのような文字列は,

(独自の ASN.1 定

義又は他の構造をもてるとしても,

)内部的な構造を必要としない。

データのコンテントタイプは,一般的に,署名付きデータのコンテントタイプにカプセル化される。

B.5

署名付きデータのコンテントタイプ  署名付きデータのコンテントタイプは,データと 0 個以上の署

名とで構成される。どのようなタイプのコンテントに対しても,署名者が何人でも並列に署名することが

できる。

  署名付きデータのコンテントタイプの典型的な応用としては,データのコンテントタイプのコンテント

に対する一人の署名者による電子署名がある。他の典型的な応用として,証明書及び証明書失効リスト

(CRL)がある。

  署名付きデータが作成される処理は,次のステップを含む。

1)

  それぞれの署名者に対して,署名者に固有のメッセージダイジェストのアルゴリズムを使って,コン

テントのメッセージダイジェスト又はハッシュが計算される。署名者がコンテント以外の何らかの情

報に署名をすると,コンテントのメッセージダイジェスト,その他の情報は,署名者のメッセージダ

イジェストのアルゴリズム(B.5.4 参照)を使って署名され,その結果が“メッセージダイジェスト”

になる。

2)

  それぞれの署名者に対して,署名者のプライベートかぎを使ってメッセージダイジェストがディジタ

ル署名される。

3)

  それぞれの署名者に対して,署名値及びその他の署名者に固有の情報が,B.5.3 に定義されているよう

に,SignerInfo の値として集められる。それぞれの署名者の証明書及び CRL,並びにどの署名者にも


21

X 5063-1

:2005 (ISO/IEC 18014-1:2002)

     

対応しない証明書及び CRL は,このステップで集められる。

4)

  すべての署名者に対するメッセージダイジェストのアルゴリズム及びすべての署名者に対する

SignerInfo

の値は,B.5.1 に定義されているように,コンテントと一緒に SignedData の値の中に集めら

れる。

  受信者は,独立にメッセージダイジェストを計算する。このメッセージダイジェスト及び署名者の公開

かぎが署名値の検証に用いられる。発行者固有のシリアル番号に伴う発行者識別名(issuer distinguished

name

)によって,又は公開かぎを含む証明書を一意に識別するサブジェクトかぎ識別子(subject key

identifier

)によって,署名者の公開かぎは参照される。署名者の証明書は,SignedData の証明書領域に含

むこともできる。

  B.5 は,六つの部分に分かれる。1 番目の部分は,最上位のタイプ SignedData について記述する。2 番目

の部分は,EncapsulatedContentInfo について記述する。3 番目の部分は,署名者ごとの情報であるタイプ

SignerInfo

について記述する。4 番目,5 番目及び 6 番目の部分は,それぞれ,メッセージダイジェストの

計算,署名生成及び署名検証の各処理について記述する。

B.5.1

  SignedData タイプ  次のオブジェクト識別子は,署名付きデータのコンテントタイプを識別する。

id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2}

  署名付きデータのコンテントタイプは,ASN.1 のタイプである SignedData をもたなくてはならない。

SignedData ::= SEQUENCE {

 version

  CMSVersion,

 digestAlgorithms

 DigestAlgorithmIdentifiers,

encapContentInfo           EncapsulatedContentInfo,

certificates

[0] IMPLICIT CertificateSet              OPTIONAL,

 crls

  [1]

IMPLICIT

CertificateRevocationLists

OPTIONAL,

 signerInfos  SignerInfos }

ここで,次のとおりとする。

DigestAlgorithmIdentifiers::= SET OF

DigestAlgorithmIdentifier

SignerInfos ::= SET OF SignerInfo

  SignedData タイプの領域は,次の意味をもつ。

  version は,構文の版数である。もし certificates 領域に属性の証明書がなければ,カプセル化されたコン

テントタイプは id-data で,SignerInfos のすべての要素は第 1 版であり,version の値は 1 でなければならな

い。また,属性の証明書がある場合,カプセル化されたコンテントタイプが id-data 以外である場合又は

SignerInfos

のいずれかの要素が第 3 版である場合には,version の値は 3 でなければならない。

  digestAlgorithms は,メッセージダイジェストのアルゴリズム識別子の集まりである。この集まりの要素

の数は,0 を含めどのような数でもよい。それぞれの要素は,関連するパラメタを伴う,一人以上の署名


22

X 5063-1

:2005 (ISO/IEC 18014-1:2002)

     

者が使ったメッセージダイジェストのアルゴリズムを識別する。この集まりは,単一パスの署名検証を容

易にするために,すべての署名者が採用したメッセージダイジェストアルゴリズムを順不同に並べること

を意図している。メッセージダイジェストの処理は,B.5.4 による。

  encapContentInfo は,署名付きコンテントとし,コンテントタイプ識別子及びコンテント自体からなる。

encapContentInfo

タイプの詳細は,B.5.2 による。

  certificates は,証明書の集まりである。この証明書の集まりは,認識される“ルート”又は“最上位の

証明機関”から signerInfos 領域に含まれるすべての署名者までの連鎖を十分に含むことを意図している。

必要以上に多くの証明書を含むこともあるし,二つ以上の独立した最上位の証明機関からの連鎖を十分に

含むこともある。受信者が必要な証明書を得る別の手段(例えば,これまでの証明書の集まりから得る。

が予想される場合には,

必要な証明書よりも少ない証明書しか含まないこともある。

上で規定したように,

certificates

属性がある場合には,version の値は,3 でなければならない。

  crls は,証明書失効リスト(CRL)の集まりである。その集まりは certificates 領域に含まれる証明書が

有効とするか否かを決定するために十分な情報を含んでいることを意図している。必要以上に多くの CRL

を含むこともあるし,必要数に満たない CRL しか含まないこともある。

  signerInfos は,署名者ごとの情報の集まりである。この集まりの中には,0 個も含めて,どのような数の

要素も含むことがある。SignerInfo タイプの詳細は,B.5.3 による。

B.5.2

  EncapsulatedContentInfo

タイプ  EncapsulatedContentInfo タイプのコンテントは,次のとおり表現

される。

EncapsulatedContentInfo::= SEQUENCE {

eContentType              CONTENT.&id({EContents}),

eContent           [0] EXPLICIT CONTENT.&id({EContents}{@eContentType })

}

  EncapsulatedContentInfo タイプの領域は,次の意味をもっている:

eContentType

は,コンテントタイプを一意に識別するオブジェクト識別子である。

  eContent は,コンテントの本体であり,オクテット列として伝えられる。eContent は,DER 符号化され

る必要はない。

  EncapsulatedContentInfo 領域内の eContent を任意に省略することによって,

“外部署名”を構成すること

が可能になる。外部署名の場合には,署名されるコンテントは,署名付きデータのコンテントタイプに含

まれる EncapsulatedContentInfo の値には存在しない。EncapsulatedContentInfo 内の eContent 値が存在しない

場合は,eContent 値が存在するかのように signatureValue を計算し,eContentType を割り当てる。

  署名者が存在しない場合には,“署名された”EncapsulatedContentInfo 値は意味がない。この場合は,

EncapsulatedContentInfo

値の中の“署名された”コンテントタイプは(B.4 で定義した)id-data とし,

EncapsulatedContentInfo

値のコンテント領域は省略されることが望ましい。

B.5.3

  SignerInfo

タイプ  署名者ごとの情報は,タイプ SignerInfo で次のとおり表現される。

SignerInfo   ::= SEQUENCE {

 version

  CMSVersion,

 sid

  SignerIdentifier,


23

X 5063-1

:2005 (ISO/IEC 18014-1:2002)

     

 digestAlgorithm

 DigestAlgorithmIdentifier,

signedAttrs

[0]IMPLICIT SignedAttributes     OPTIONAL,

signatureAlgorithm         SignatureAlgorithmIdentifier,

signature

                SignatureValue,

unsignedAttrs

[1]IMPLICIT UnsignedAttributes   OPTIONAL}

ここで,次のとおりとする。

SignerIdentifier     ::= CHOICE {

 issuerAndSerialNumber

 IssuerAndSerialNumber,

 subjectKeyIdentifier[0]

 SubjectKeyIdentifie }

SignedAttributes    ::= SET SIZE(1..MAX) OF Attribute

UnsignedAttributes  ::= SET SIZE(1..MAX) OF Attribute

Attribute                      ::= SEQUENCE {

attrType          OBJECT IDENTIFIER,

attrValue    SET OF AttributeValue }

AttributeValue      ::= ATTRIBUTE.&Type

SignatureValue     ::= OCTET STRING

  タイプ SignerInfo の領域は,次の意味をもつ。

  version は,構文の版数である。SignerIdentifier が CHOICE issuerAndSerialNumber ならば,version は1で

なければならない。SignerIdentifier が subjectKeyIdentifier ならば,version は 3 でなければならない。

  sid は,署名者の証明書を特定する(それによって署名者の公開かぎも特定する。)。署名者の公開かぎは,

受信者が署名を検証するのに必要である。

  SignerIdentifier は,署名者の公開かぎを特定するための二つの選択肢を提供する。issuerAndSerialNumber

という選択肢は,署名者の証明書を,発行者の識別名及び証明書のシリアル番号によって識別する。

subjectKeyIdentifier

という選択肢は,署名者の証明書を X.509 の subjectKeyIdentifier の拡張値によって識別

する。

  digestAlgorithm は,署名者に使われたメッセージダイジェストのアルゴリズム及び関連するパラメタを

識別する。メッセージダイジェストは,B.5.に記述される処理を使って,署名されるコンテント又は署名

された属性を伴ったコンテントについて,計算される。メッセージダイジェストのアルゴリズムは,関連

する SignerData の digestAlgorithms 領域に挙げられているものでなければならない。

  SignedAttributes は,署名される属性の集まりである。この領域は任意選択とするが,署名される

EncapsulatedContentInfo

値のコンテントタイプが id-data でない場合は存在しなければならない。SET の中

のそれぞれの SignedAttributes は,領域が存在するならば,DER 符号化されなければならない。この領域

が存在するならば,少なくとも,次の二つの属性を含まなければならない:

  content-type 属性は,署名される EncapsulatedContentInfo 値のコンテントタイプを値としてもつ。B.6.1 

content-type

属性を定義する。B.6.3 で定義される署名されない属性とする連鎖署名の一部として使われる

場合は,content-type 属性を必要としない。

  message-digest 属性は,コンテントのメッセージダイジェストを値としてもつ。B.6.2 で message-digest


24

X 5063-1

:2005 (ISO/IEC 18014-1:2002)

     

属性を定義する。

  signatureAlgorithm は,署名者が電子署名を生成するのに使う,署名アルゴリズム及び関連するパラメタ

を識別する。

  signature は,メッセージダイジェスト及び署名者のプライベートかぎを使った,電子署名生成の結果と

なる。

  UnsignedAttrs は,署名されない属性の集まりである。この領域は任意選択とする。連鎖署名などの有用

な属性は,B.6 で定義する。

  SignedAttrributes タイプ及び UnsignedAttributes タイプの領域は,次の意味をもつ。

  attrType は,属性のタイプを示す。これは,オブジェクト識別子である。

  AttrValues は,属性からなる値の集合である。集合のそれぞれの値のタイプは,attrType によって一意的

に決めることができる。

B.5.4

メッセージダイジェストの計算処理  メッセージダイジェストの計算処理は,署名されるコンテン

ト又は署名された属性を伴ったコンテントについてメッセージダイジェストを計算する。

いずれの場合も,

メッセージダイジェストの計算処理への入力は,署名の対象となるカプセル化された“値”である。特に,

署名処理が適用される初期入力は,encapContentInfo eContent OCTET STRING である。メッセージダイジ

ェストアルゴリズムの入力になるのは,eContent OCTET STRING の値からなるオクテットだけであって,

タグでも長さのオクテットでもない。

  メ ッ セ ー ジ ダ イ ジ ェ ス ト 計 算 処 理 の 結 果 は , signedAttributes 領 域 が あ る か ど う か に 依 存 す る 。

signedAttributes

領域がない場合,その結果は,前述のように,コンテントのただのメッセージダイジェス

トとなる。しかしながら,signedAttributes 領域がある場合は,その結果が,signedAttributes 領域に格納さ

れ た SignedAttributes 値 の 完 全 な DER 符 号 化 の メ ッ セ ー ジ ダ イ ジ ェ ス ト と な る 。 こ の 場 合 は ,

SignedAttributes

値はコンテントタイプ及びコンテントメッセージダイジェスト属性を含まなければならな

いので,それらの値は間接的に結果に含まれる。B.6.3 で定義するように,連鎖署名の署名されない属性の

一部として使われる場合,コンテントタイプ属性は要求されない。メッセージダイジェスト計算には,

signedAttributes

領域の符号化が別に実行される。

  DER 符号化には,signedAttributes 領域にある IMPLICIT[0]タグが使われるのではなく,むしろ EXPLICIT

SET OF

タグが使われる。すなわち,IMPLICIT[0]タグよりも SET OF タグの DER 符号化が,SignedAttributes

値の長さ及びコンテントオクテットとともに,メッセージダイジェスト計算に含まれることになる。

  SignedAttributes 領域がない場合には,signedData encapContentInfo eContent OCTET STRING の値からなる

オクテット(例えば,ファイルの内容)だけが,メッセージダイジェスト計算の入力になる。これには,

署名生成処理に先立って,署名されるコンテントの長さを知る必要がないという利点をもつ。

  encapContentInfo eContent OCTET STRING タグ及び長さのオクテットは,メッセージダイジェスト計算

に含まれないが,これらは他の手段によって保護されている。メッセージダイジェストアルゴリズムの性

質によって,どのような長さのメッセージであっても同じメッセージダイジェストをもつような異なる二

つのメッセージを見付けることは,計算量的に実行不可能なので,長さのオクテットは保護される。

B.5.5

メッセージ署名の生成処理  署名生成処理の入力は,メッセージダイジェスト計算処理の結果及び

署名者のプライベートかぎを含む。署名生成の詳細は,採用される署名アルゴリズムに依存する。パラメ

タを伴う,署名者が採用した署名アルゴリズムを特定するオブジェクト識別子は,signatureAlgorithm 領域

に入れて伝えられる。署名者によって生成される署名値は,OCTET STRING に符号化され,signature 領域

に入れられて伝えられる。


25

X 5063-1

:2005 (ISO/IEC 18014-1:2002)

     

B.5.6

メッセージ署名の検証処理  署名検証処理の入力は,メッセージダイジェストの計算処理及び署名

者の公開かぎを含む。何らかの手段によって受信者は署名者の正しい公開かぎを入手できるが,望ましい

方法は,SignedData certificate 領域から入手される証明書である。署名者の公開かぎの選択及び有効性確認

は,他の外部コンテントと同様に,証明書パスの有効性確認に基づくことができるが,この文書の範囲を

超える。署名検証の詳細は,採用された署名アルゴリズムに依存する。

  受信者は,生成者の計算したメッセージダイジェストの値を信頼しなくてもよい。signedData signerInfo

が signedAttributes を含めば,コンテントのメッセージダイジェストは B.5.4 で述べたように計算されなけ

ればならない。署名を有効とするためには,受信者によって計算されたメッセージダイジェストは

signedData signerInfo

の signedAttributes に含まれる messageDigest 属性の値と等しくなければならない。

B.6

有用な属性  B.6 は,signed-data とともに使うことのできる属性を定義する。属性は,特別な順序で

並べられてはいない。

B.6.1

コンテントタイプ  content-type 属性タイプは,signed-data の中で署名される ContentInfo 値のコン

テントタイプを特定する。認証された何らかの属性がある場合,content-type 属性タイプが要求される。

  content-type 属性は,署名された属性,又は認証された属性でなければならない。すなわち,署名されて

いない属性,認証されていない属性,又は unprotectedAttribute であってはならない。

  次のオブジェクト識別子が content-type 属性を識別する。

id-contentType OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3}

  content-type 属性値は,ASN.1 の ContentType をとる。

ContentType ::= OBJECT IDENTIFIER

  content-type 属性は,構文が SET OF AtgtributeValue と定義されていても,属性値を 1 個だけとらなければ

ならない。AttributeValue のインスタンスがなくてもいけないし,複数個あってもならない。

  SignedAttributes 及び AuthAttributes の構文は,それぞれ SET OF Attributes として定義される。signerInfo

の中の SignedAttributes は,content-type 属性をもつ複数のインスタンスを含んではいけない。同様に,

AuthenticatedData

の中の AuthAttributes は,content-type 属性をもつ複数のインスタンスを含んではいけな

い。

B.6.2

メッセージダイジェスト  message-digest 属性タイプは,signed-data において署名されている

encapContentInfo eContent OCTET STRING

のメッセージダイジェストを特定する(B.5.4 参照)

。signed-data

に対して,メッセージダイジェストは,署名者のメッセージダイジェストアルゴリズムを使って計算され

る。何らかの属性が存在する場合は,署名付きの message-digest 属性タイプが必要である。

  message-digest 属性は,署名された属性でなければならない。署名されていない属性であってはならない。

  次のオブジェクト識別子が message -type 属性を識別する。

id-messageDigest OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4}


26

X 5063-1

:2005 (ISO/IEC 18014-1:2002)

     

  message -type 属性値は,ASN.1 の MessageDigest をとる。

MessageDigest::= OCTET STRING

  message-type 属性は,構文は SET OF AttributeValue と定義されているとしても,単一の属性値をとらな

ければならない。0 個又は複数の AttributeValue のインスタンスがあってはならない。

  SignedAttributes 構文は,

SET OF Attributes

として定義される。

signerInfo

の中の SignedAttributes は,

message

-type

属性をもつ複数のインスタンスを含んではいけない。

B.6.3

連鎖署名  countersignature 属性値は,signed-data における SignerInfo 値の signatureValue 領域の DER

符号化からなるコンテントオクテットに対する一つ以上の署名を特定する。よって,countersignature 属性

値は,他の署名を連鎖署名(順番に署名)する。

  countersignature 属性は,署名されていない属性でなければならない。署名された属性であってはならな

い。

  次のオブジェクト識別子が countersignature 属性を識別する。

id-countersignature OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6}

  countersignature 属性値は,ASN.1 の Countersignature をとる。

 Countersignature

::=

SignerInfo

  countersignature 値は,次の点を除いて,通常の署名に対する SignerInfo 値と同じ意味をもつ:

1)

  signedAttributes 領域は,他の何らかの属性を含むのであれば,message-digest 属性を含まなければなら

ないが,連鎖署名にはコンテントタイプはないので,content-type 属性を含む必要はない。

2)

  メッセージダイジェスト処理の入力は,属性が関連する SignerInfo 値の signatureValue 領域の DER 符

号化からなるコンテントオクテットである。

  countersignature 属性値は,複数の属性値をもつことができる。構文は SET OF AttributeValue として定義

され,一つ以上の AttributeValue のインスタンスが存在しなければならない。

  UnsignedAttributes 構文は,SET OF AttributeValue として定義される。signerInfo の中の UnsignedAttributes

は,countersignature 属性をもつ複数のインスタンスを含まなければならない。

  countersignature は,SignerInfo タイプをもつので,それ自体の中に countersignature 属性を含むことがで

きる。よって,連鎖署名の任意長の列を構成することができる。