PP-TSAは、ファイルや記録のハッシュに署名付きデジタルタイムスタンプを発行するサービスです。元データをPP-TSAへ送ることなく、そのデータが記録時刻までに存在し、後から提示されたデータが当時のものと同じであることを確認できる証拠を残します。
元データはお客様の手元に残します。
自社システムで固有の指紋を作ります。
PP-TSAがハッシュと記録時刻に署名します。
返却tokenを元データと対応付け、必要なときに検証します。
連携方式：新しく自社実装するならREST API、対応済みの文書・署名ツールならRFC 3161。同じアカウントで両方利用できます。
送るのはハッシュだけです。PP-TSAは内容を見られず、データそのものはお客様の管理下に残ります。
署名付きタイムスタンプが指紋と記録時刻を結び付けるため、その時点は自社ログの記載だけに頼りません。
署名、証明書のつながり、公開台帳への登録は、年月が経ってからでも確認できます。
複製・差し替え・上書きは、ほとんど痕跡を残しません。監査、取引上の争い、成果物の引き渡しで説明が必要になったとき、自社では動かせない時刻に結び付いた正確なデータが必要になります。
更新日時、画面のスクリーンショット、自社だけが管理するログは、対象データと一緒に変更できる場合があります。
争いや引き渡しの場面で問われるのは、いま提示されたものが当時のものと同じかどうかです。ファイル名やサイズでは答えられません。
発行側の仕組みが変わったあとに再検証できない証拠は、いざ必要になった時点で役に立ちません。
1行ごとにひとつの主張と、その範囲外を明記しています。行をクリックすると詳細が開きます。
データのハッシュを、PP-TSAが記録した時刻とともに署名します。主張はその時点までの存在についてであり、作成者や内容の正しさについてではありません。
日付の遡り、そして保持者が書き換えられるファイル日時やスクリーンショットだけに頼った主張。
提示されたデータのハッシュを再計算し、タイムスタンプ済みのハッシュと比較することで、ビット単位で同じデータかを確認できます。
気づかれない差し替えや上書き、そしてどの版が問題のものだったかという争い。
tokenにはPP-TSAの署名と証明書のつながりが含まれます。検証では発行者とつながりの有効性を確認し、失効状態は別に報告します。
偽造・改変されたtoken、そして検証できないtokenを確認済みとして扱うこと。
発行済みtokenは指紋の公開台帳へ追加されます。署名済みcheckpointにより、そのtokenが台帳に含まれること、そこまでの履歴が一貫していることを確認できます。元ファイルは公開されません。
発行済みタイムスタンプの静かな削除や並べ替え、そして発行者の言葉だけに頼ること。
指紋の計算はお客様のシステムで行い、送るのはその値だけです。機密文書、個人データ、ソースコードも、環境の外に出さずにタイムスタンプできます。
証拠を得るという行為そのものによる、機密情報の流出。
新規実装にはREST API、対応済みツールにはRFC 3161。requestにはハッシュ、algorithm、random nonce、idempotency keyを含めるため、再試行で二重発行になりません。
手作業ゆえの付け忘れ、そして結果が不明な再試行による重複発行。
タイムスタンプが示すのは、記録時刻までにそのデータが存在したこと、そしていま提示されたものが同じデータであることです。誰が作成したか、内容が正しいか、権利が誰にあるかは示しません。台帳への包含は発行直後には保留の場合があり、pending・overdue・unknownを完了として扱うことはありません。
メールアドレスで登録すると、その場で組織用の環境が作られます。
月間の発行量に合わせて選択します。あとから変更できます。
完全なキーは発行時にしか表示されません。組織で決めた方法で記録してください。
ハッシュをローカルで計算し、HTTPSで呼び出します。返却tokenを元データと対応付けて保管し、独立して検証します。
自社システムでハッシュを計算し、JSONで /v1/timestamps へ送ります。Base64のtokenとmetadataが返ります。backend、Web service、CI pipelineに向きます。
TimeStampReqを /tsr へ送り、TimeStampRespを受け取ります。PDF、電子署名、archive製品がRFC 3161に対応済みの場合に選びます。
業種の問題ではなく、「その時点で存在したか」「提示されたものが当時のものと同じか」を示す場面で必要になります。
契約、見積、請求の確定版を固定し、後の争いが「どちらの控えが新しいか」ではなくデータそのもので判断されるようにします。
結果や図面、設計記録を、内容を誰にも開示せずに、生まれた時点でタイムスタンプします。
公開したbuildとその一覧を時刻に結び付け、出荷したものと後から作り直したものを区別できるようにします。
写真、測定値、点検logを検証できる形で残し、真正性が管理システムの表示だけに依存しないようにします。
証拠が信用されるかどうかは、何を預かるか、結果をどう返すかで決まります。どちらも最初から狭く定めています。
サービスが扱うのは指紋、algorithm、requestのmetadataです。元データの内容がPP-TSAへ届く経路はありません。
完全なAPIキーは発行時にしか表示されず、以後は再表示されません。紛失した場合は新しいキーを発行し、古いキーを失効します。
署名、証明書のつながり、timestampの状態、台帳への包含、失効状態を個別に返します。pendingやunknownを検証済みとして示すことはありません。
requestには必ずidempotency keyを含めます。結果が不明なときの再試行は、保存済みのrequest bytesと同じkeyを使い、発行を繰り返しません。
されません。ハッシュはお客様のシステムでローカルに計算し、送るのはその値だけです。機密文書や個人データは環境の外に出ません。
メールアドレスでのサインアップと、プランの選択だけです。営業とのやり取りや事前審査はありません。
はい、RFC 3161で利用できます。新しく自社実装する場合はREST APIの方が簡単です。同じアカウントで両方使えます。
しません。示すのは、記録時刻までにそのデータが存在したこと、そして後から提示されたものが同じデータであることです。作成者、内容の正しさ、権利の帰属は別の問題です。
保存済みのrequest bytesと同じidempotency keyを使ってください。二重に発行されるのではなく、最初の結果が返ります。