timestamp.bringer.cloud bringer.cloud ↩
RFC 3161bringer

そのデータは、
いつからそこにあったのか。証明する仕組みが、実はあります。

ファイルの中身も更新日時も、あとからいくらでも書き換えられます。 「たしかにこの時刻に、この内容で存在していた」ことを第三者の立場から 証言する仕組みが、タイムスタンプ(時刻認証)です。日本では総務大臣が 認定した事業者がこのサービスを提供しており、電子契約や電子帳簿の分野で 使われています。

このサイトについて

timestamp.bringer.cloud は、上で説明したタイムスタンプの仕組み (RFC 3161という国際規格)を、個人が自宅のサーバに実装したものです。 総務大臣の認定は受けていません。認定は「その仕組みを運用する事業者」に 対して与えられるもので、監査や財務基盤の審査を伴うため、個人の実装だけで 得られる性質のものではないからです。

それでも、通信プロトコルや署名方式といった技術面は、認定事業者と同じ規格に 沿うように作ってあります。時刻の同期から鍵の管理まで、仕組みを勉強しながら 組んだ個人の実験場だと思ってください。

費用

無料

総務大臣の認定を受けていないので、対価を求める理由がありません。

認定タイムスタンプは、監査・保険・24時間体制の運用などを含んだ事業として 提供されるサービスであり、利用には料金がかかるのが普通です。 timestamp.bringer.cloud はその認定を受けていない、個人が趣味で動かしている サーバです。そうした事業としての体制も費用も存在しないので、今のところ、 そしてこの先も、料金を取る予定はありません。

何を証明できるのか

あるデータのハッシュ値を送ると、「そのハッシュ値をこの時刻に受け取った」ことを 署名付きで証言します。証明できることとできないことは、はっきり分かれています。

○ そのデータが、指定した時刻には存在していたこと
○ タイムスタンプ取得後、データが改変されていないこと
✕ 誰がそのデータを作ったか(作成者・署名者の身元)
✕ そのデータがどこかに公開されていたこと、公開先のURL
✕ 電子帳簿保存法など、法令が要求する「認定タイムスタンプ」としての効力

技術仕様

プロトコルRFC 3161 (ISO/IEC 18014-2 相当)
時刻源NICT公開NTPサーバ ntp.nict.jp へ chrony 経由でトレーサブルに同期
署名鍵RSA 3072bit(ルートCAは4096bit)
署名アルゴリズムSHA-256withRSA
証明書X.509、Extended Key Usage を timeStamping のみに critical 指定
ポリシーOID1.2.392.200011.61.1.1.1(検証段階の仮値)
運用基盤自宅k3sクラスタ上、鍵はSecretで管理、特定ノードに固定
運営者個人(ぶりんがー)。事業者ではない

使い方

1. ハッシュ値からリクエストを作る

証明したいファイルは送信しない。ハッシュ値だけを渡す。

openssl ts -query -data yourfile.pdf -sha256 -cert -out request.tsq

2. リクエストを送信する

curl -X POST \
  --data-binary @request.tsq \
  -H "Content-Type: application/timestamp-query" \
  https://timestamp.bringer.cloud/timestamp \
  -o response.tsr

3. 受け取ったTSTを検証する

下記のルート証明書を使って検証する。

openssl ts -verify \
  -in response.tsr -queryfile request.tsq \
  -CAfile bringer-root-ca.crt

ルート証明書

検証にはこのルート証明書が必要です。手元に保管しておいてください。

SHA-256 フィンガープリント
B8:6F:E6:D9:99:83:80:77:E1:3F:83:30:F8:ED:AE:21:CD:86:9D:E1:41:44:96:E2:C8:F2:E7:D5:5F:2E:B9:FC
発行者 / サブジェクト
C=JP, ST=Tokyo, L=Chiyoda, O=bringer, CN=bringer.cloud(自己署名)
有効期間
2026-08-26 〜 2036-08-23
root-ca.crt をダウンロード

使う前に