X 5063-1：2005(ISO/IEC 18014-1：2002)
（1）
2019年7月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）
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
目 次
ページ
序文 ··································································································································· 1
1. 適用範囲 ························································································································ 1
2. 引用規格 ························································································································ 1
3. 定義 ······························································································································ 3
3.1 データ項目の表現（data items' representation） ··································································· 3
3.2 タイムスタンピング機関，TSA（time-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
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
日本工業規格 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)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
が，この規格と一致している。
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)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
規則（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)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
に一致している。
次の用語は，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)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
タイムスタンプの要求者へ送付される。
参考 機密性 アクセスを許可された（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)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
そのデータに関連付けられた前のタイムスタンプとはつながりのない新しいタイムスタンプとなり，タイ
ムスタンプの再発行と呼ばれる。
また，タイムスタンプの再発行は，初期のデータからのハッシュ値を形成するために使われるハッシュ
関数が問題となるときに必要となることがある。この場合，古いタイムスタンプトークン及び原データは
共に，タイムスタンプの再発行のために提出され，新しく計算されたハッシュ値に含まれなければならな
い。
タイムスタンピングサービスは，オンラインでも，オフラインでも運用することができる（例えば，蓄
積交換プロトコル）。その区別は，関係するエンティティ間の通信プロトコルの伝送レベルでなされる。
4.3 タイムスタンプの利用 タイムスタンプは，電子文書が作成，変更又は署名された時点の正確な時刻
を表さない。TSAが暗号を使って署名された文書のハッシュに時刻の値を結合するのに対して，タイムス
タンピングの対象となる文書を提供するエンティティは，TSAとは独立に文書に署名してもよい。
利用できる唯一の証拠は，含まれるタイムスタンプが押される以前に文書が存在したことである。
また，タイムスタンプは，署名された文書の有効性に重要な役割を果たす。タイムスタンピング及びデ
ータの署名の発生については，時間的に，三つの異なる可能性がある。タイムスタンプの要求者がデータ
に署名する前，文書の送り手の署名がなされた後及び署名の前後に，データはタイムスタンピングされる
ことがある。これによって署名の時間的有効性を調査したときに異なる結果が導かれる。表1は，これら
の可能性を示す。
表1 署名及びタイムスタンプの時間的配置
ケース1 t1
TSAがタイムスタンプを生成する。
s
要求者は提供されたタイムスタンプと一緒にデータに署名する。
ケース2 s
要求者はデータに署名する。
t2
TSAは署名されたデータにタイムスタンプ処理する。
ケース3 t1
TSAはタイムスタンプを生成する。
s
要求者は提供されたタイムスタンプと一緒にデータに署名する。
t2
TSAは署名されたデータにタイムスタンプ処理する。
ケース1（署名は，タイムスタンプを含む。）は，データが署名された時刻を正確には定義しない。デー
タがタイムスタンピングされた後で署名されたことを示している。ケース2は示された時刻以前にデータ
が署名されたことを表す。ケース3は文書が署名された期間を定義する。
4.4 タイムスタンプトークンの検証 タイムスタンプトークンを検証するとき，最初にタイムスタンプに
含まれる時刻の値を評価し，それからタイムパラメタを含んだタイムスタンプトークンの有効性を検証す
る。タイムスタンプの有効性は，タイムスタンプトークンの正確さを評価することによって検証する。又
は，タイムスタンプトークンの正確さの評価は，信頼される第三者機関（TTP）に任されてもよい。
4.5 タイムスタンピングに関連したサービス タイムスタンピングと関連する次の二つの基本的な運用
がある。
− 時刻の値をデータ値に暗号を使って結合する，タイムスタンピング処理
− 暗号を使った結合の正確さを評価する，タイムスタンプ検証処理
TSAは，タイムスタンピングサービスを提供するが，一方，タイムスタンプ検証処理は，他の信頼され
る機関と関連してもよい。
提供された時刻は，正確であるという一般的な要求条件を満足しなければならない。TSAのために時刻
7
X 5063-1：2005 (ISO/IEC 18014-1：2002)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
を与えるサービスは，この規格の適用範囲外とする。
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)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
がエンティティに代わって行ってもよい。
連結されたトークン生成機構を用いて生成されたトークンの検証には，単一のタイムスタンプトークン
と，おそらく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)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
データフィールド
説明
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)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
データフィールド
説明
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)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
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)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
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)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
附属書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)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
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)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
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)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
(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)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
}
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)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
requestID [0] OCTET STRING OPTIONAL
}
END -- TimeStampProtocol ‒
19
X 5063-1：2005 (ISO/IEC 18014-1：2002)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
附属書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)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
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)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
対応しない証明書及び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)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
者が使ったメッセージダイジェストのアルゴリズムを識別する。この集まりは，単一パスの署名検証を容
易にするために，すべての署名者が採用したメッセージダイジェストアルゴリズムを順不同に並べること
を意図している。メッセージダイジェストの処理は，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)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
digestAlgorithm
DigestAlgorithmIdentifier,
signedAttrs
[0]IMPLICIT SignedAttributes OPTIONAL,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature
SignatureValue,
unsignedAttrs
[1]IMPLICIT UnsignedAttributes OPTIONAL}
ここで，次のとおりとする。
SignerIdentifier ::= CHOICE {
issuerAndSerialNumber
IssuerAndSerialNumber,
subjectKeyIdentifier[0]
SubjectKeyIdentifier }
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は１で
なければならない。SignerIdentifierがsubjectKeyIdentifierならば，versionは3でなければならない。
sidは，署名者の証明書を特定する（それによって署名者の公開かぎも特定する。）。署名者の公開かぎは，
受信者が署名を検証するのに必要である。
SignerIdentifierは，署名者の公開かぎを特定するための二つの選択肢を提供する。issuerAndSerialNumber
という選択肢は，署名者の証明書を，発行者の識別名及び証明書のシリアル番号によって識別する。
subjectKeyIdentifierという選択肢は，署名者の証明書をX.509のsubjectKeyIdentifierの拡張値によって識別
する。
digestAlgorithmは，署名者に使われたメッセージダイジェストのアルゴリズム及び関連するパラメタを
識別する。メッセージダイジェストは，B.5.4に記述される処理を使って，署名されるコンテント又は署名
された属性を伴ったコンテントについて，計算される。メッセージダイジェストのアルゴリズムは，関連
する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)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
属性を定義する。
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)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
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)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
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属性を含むことがで
きる。よって，連鎖署名の任意長の列を構成することができる。