要約

  • ES-Tはsignatureが早い時点で存在したことを固定し、ES-Cはcertificate pathとrevocation dataを参照し、ES-Xはその値を保持または時刻保護し、ES-Aは旧い保護が弱くなる前の再timestampを可能にした。
  • 長期性はformat名から生まれない。正確なbytes、実際のvalidation values、適用policy、そして前の層がまだ検証可能な間に行う更新が必要だった。

残るのはsignatureだけでは足りない

digital signatureのbitは劣化せず複製できる。しかし判断環境は消える。signer certificateは期限切れになり、古いCRLは配布されなくなり、OCSP responderは停止し、TSA certificateも寿命を迎え、hash algorithmの安全性も変わる。

2001年9月にInformationalとして出たRFC 3126は、この時間差を中心に置いた。RFC 3125のpolicy-aware signatureにCMS、ESS、X.509、revocation evidence、trusted timestampを重ねた。保存対象はsignature valueだけでなく、最初のverifierがなぜ有効と判断できたかという周辺資料だった。

ES-Tは存在時刻を示し、内容を裁かなかった

基本形ESに対し、ES-Tはsignature timestampを追加する。signerが用意しなければ、verifierは初回受領時に作るか、初回検証に近い安全なtime recordを残す必要があった。

RFC 3161のTSAはmessage imprintに署名し、そのdataがある時点に存在したことを示す。元文書を読む必要はない。したがってtimestampは、文の真実、signerの業務権限、全policy ruleへの適合、transaction完了を証明しない。

それでも順序は重要だった。鍵が後で漏えいした場合、それより前のtimestampはsignatureがincident以前にあったことを支えられる。ただしTSAにも鍵、certificate、policy、有限の寿命がある。trustは消えるのでなく移動する。

ES-Cは検証のrecipeを記録した

ES-CはES-Tの上に、検証に使ったcertification pathとrevocation informationの参照を加える。将来のverifierは、どのcertificate、CRL、status responseが当初の判断を支えたかを特定できる。

完全なstatus情報はsigningと同時に揃うとは限らない。revocation情報が公開されるまでの時間や、一時的suspensionの決着を待つ場合がある。長期証拠はsigning functionの一回のoutputではなく、後続のcapture工程だった。

参照は値そのものではない。repositoryが消えればidentifierだけでは検証できない。X-Longは実際のcertificate valuesとrevocation valuesを取り込んだ。索引と蔵書を分けた設計である。

OCSPも限定された証拠だった。RFC 2560のgood、revoked、unknownは特定時点のstatusであり、goodがsignerの権限や全validation conditionを保証するわけではない。

ES-Xは検証資料の「いつ」を守った

ES-Xはavailabilityと後日のcompromiseを分けて扱う。X-Longは参照先の値を保持する。X-Time-Stamp Type 1はES-C全体を、Type 2はcertificateとrevocationの参照をtimestampし、組み合わせも可能だった。

CA keyが数年後に盗まれたとき、争いの時点でcertificate chainを示すだけでは、それが盗難前から存在したか分からない。早い段階でvalidation evidenceをtimestampしていれば、適用policyの下で時間順序を説明できる。

ただし追加層は過去の誤りを修復しない。signed contentを失い、誤ったpathを保存し、compromise後に初めてstampしたなら、複雑なcontainerは不完全な歴史を精密に固定するだけだ。

ES-Aはarchiveに締切を持ち込んだ

ES-Aは保護手段自体の老化に備える。algorithm、key、過去のtimestamp certificateが弱くなる前に、signed data、ES-C、ES-Xをまとめて、できれば強いalgorithmや長いkeyで再timestampする。その処理は繰り返せる。

archive timestampはcontent、signed attributes、signature、最初のtimestamp、certificateとrevocationのreferences、保存済みvalues、任意のES-X stamp、過去の全archive stampを覆う。これはcryptographic chain of custodyであって、一個の永遠のsealではない。

更新は旧い層がまだ検証可能なうちに行う必要がある。hashが実用的に破られ、TSA key compromiseに信頼できる時間境界がなく、validation valuesが消えた後では、新しいstampは失われた過去を戻せない。RFC 4998は後に、timestamp更新とrehashを伴う更新をより一般的なevidence recordで整理した。

見た目ではなく同じoctetsを残す

RFC 3126は、signature生成に使ったOCTET STRINGが再検証時にも同じであることを求めた。archive migrationでline endingを正規化し、encodingを変え、detached contentを落とし、同じ見た目に再exportするだけでも証拠は壊れ得る。

長期保存すべき単位は、正確なbytes、signature、attributes、policy、certificate path、時刻付きstatus、timestamp tokens、保存したvalidation values、全更新履歴を含むbundleだった。rendered fileと「valid」というdatabase fieldだけでは、判断を再現できない。

RFC 5126はRFC 3126をobsoletesし、CAdES-T/C/X/Aのfamilyを継承した。この継続は設計思想の生命を示すが、2001年の具体的deploymentを証明しない。

長期signatureは動き続ける制度だった

signerは元の行為を担い、verifierは最初の時刻とvalidation dataをcaptureする。CAとstatus serviceは期間限定の材料を提供し、TSAはimprintに時刻を付け、archive custodianはbytesを保持して更新する。後日のarbitratorはpolicyと外部の法的・契約的instrumentに照らして判断する。

RFC 3126の歴史的な意味は「timestampで永遠になる」ことではない。最初のverifierが知っていたものを残し、remote serviceが忘れる値を取り込み、将来のcompromiseより前に存在したことを守り、前の仮定が崩れる前に更新する。鍵より長く生きる証拠は、止まらないchainだった。

出典

  1. https://www.rfc-editor.org/rfc/rfc3126.txt
  2. https://www.rfc-editor.org/info/rfc3126
  3. https://datatracker.ietf.org/doc/rfc3126/
  4. https://www.rfc-editor.org/rfc/rfc3125.txt
  5. https://www.rfc-editor.org/rfc/rfc3161.txt
  6. https://www.rfc-editor.org/rfc/rfc2630.txt
  7. https://www.rfc-editor.org/rfc/rfc2634.txt
  8. https://www.rfc-editor.org/rfc/rfc2459.txt
  9. https://www.rfc-editor.org/rfc/rfc2560.txt
  10. https://www.rfc-editor.org/rfc/rfc4998.txt
  11. https://www.rfc-editor.org/rfc/rfc5126.txt
  12. https://www.rfc-editor.org/rfc/rfc5652.txt