レシートが証明すること、証明しないこと

暗号による証拠は、過大な主張を招きがちです。「署名済み」は「真実」のように聞こえ、「改ざん検知可能」は「認証済み」のように聞こえます。どちらも正しくありません。監査、契約、紛争でTrustviceのレシートを使うなら、最も価値があるのは、それを正確に記述することです：示している以上のことも、それ以下のことも言わないことです。

この記事は、その記述です。慎重な弁護士、監査人、相手方がレシートに依拠する前に読んでほしいページであり、当社のドキュメントがすでに述べていることを、あえて繰り返しています。

有効なレシートが証明すること#

公開されたTrustviceの鍵に照らして検証されたレシートは、3つのことを証明します。

出所。 エンベロープは、signatureKeyIdに対応する秘密鍵の保持者によって署名されています。それはTrustviceの署名鍵です。お客様を含め、ほかの誰も、その鍵に照らして検証されるレシートを作ることはできません。

完全性。 signature以外のエンベロープのすべてのメンバーが、署名されたとおりの状態です：type、body、issuedAtの時刻、そして鍵ID。1文字でも変えれば、検証は失敗します。

署名された時刻。 Trustviceは、レシートがissuedAtに作成されたと主張します。これは発行者自身の時計です。

この3つは誰でも、オフラインで、アカウントなしで、当社に問い合わせることなく確認できます。確認は決定的です：2つの独立した実装に同じレシートと同じ鍵を与えれば、同じ答えにたどり着きます。それがレシートの強みであり、それは本物です。

申告された事実と観測された事実#

限界を挙げる前に、個々のレシートがどれだけの意味を持つかを左右する、1つの区別があります。

レシートが述べる事実には、誰かがTrustviceに提供した事実（提示されたことを示すために署名されたもの）と、Trustvice自身が実行した、または確認したことについての事実があります。申告された事実のレシートは、それらがissuedAtまでに提示されたことを証明し、観測された事実のレシートは、Trustviceが確認した内容を証明します。どちらの場合もレシートの見た目は同じなので、手元のレシートがどちらかはレシートの種類で確認してください。

レシートが証明しないこと#

これらは欠陥ではありません。主張の境界です。

申告された事実が真実であること#

ハッシュについてのレシートが対象にするのはハッシュです。虚偽の文書のハッシュも、真実の文書のハッシュとまったく同じように検証されます。プロンプトと応答のような申告されたやり取りについてのレシートは、そのやり取りがある時点で提示されたことを証明するものであり、記述どおりに起きたことを証明するものではありません。

それでも、申告された事実のレシートが与えてくれるものには価値があります：主張を時刻に固定するため、こっそり日付を遡らせることはできず、後からのどんな変更も検知できます。

誰が作成、承認、所有したか#

エンベロープは、ワークスペースやアカウントの識別子も、個人の署名も持ちません。そのJSONを持っている人なら誰でも提示できます。ハッシュが特定するのはバイト列であって所有者ではありません：ほかの誰も同じコンテンツを持っていないことは示しません。作成者が重要なら、コンテンツの内部にご自身の署名を入れてください。

お客様のコンテンツ#

レシートが保持するのはハッシュです。文書が一致することを示すには、その文書をハッシュ化して本文と比較してください。レシートが役に立つのは、そのコンテンツを提出できる場所に保管している場合だけです。

出来事の実際の時刻#

issuedAtは、署名時点の当社の時計です。申告された事実の場合、出来事はレシートより前のある時点で起きています。レシートは、いかなる法制度における適格タイムスタンプでもありません。出来事とレシートの間隔よりも細かい精度を主張しないでください。外部の基点が必要な場合は、独自の信頼できる時計を持つ場所に、レシートの署名を公開してください。

レシートのない場所で何も起きなかったこと#

レシートが証明するのは、そこに書かれていることであって、書かれていないことではありません。レシートの空白は、何も起きなかったことの証明にはなりません。それはお客様に有利にも不利にも働きません。

レシートが失効したこと、または鍵が一度も侵害されていないこと#

失効の仕組みはありません。発行時に検証されたレシートは、その署名鍵が公開されている限り検証され続けます。鍵の失効リストもありません。署名鍵が漏洩すれば、その保持者は検証に通るレシートを作れてしまい、署名の確認だけではそれを本物と区別できません。

お客様がなお当社を信頼している点#

検証によって、多くの点で当社を信頼する必要がなくなります：レシートが改変されたかどうか、どの鍵が署名したか、中の鍵がすり替えられたかどうかを、当社に教えてもらう必要はありません。残るのは、名前の付いた小さな集合です：

• 検証に使う公開鍵が当社のものであること。 信頼できるネットワークから鍵IDとxの値を固定し、そのコピーに照らして検証してください。
• 当社の署名鍵がレシートサービスによってのみ使われること。 鍵はTrustviceがAWS KMSのハードウェアセキュリティモジュール内に保管しており、そこから出ることはないため、複製は防げます。ただし、レシートサービスをデプロイできる者や、その署名専用のクレデンシャルを持つ者が、サービスに署名させることまでは防げません。
• 当社が何かを観測したと述べるとき、実際にそうしたこと。 これは、Trustviceが実行した、または確認したことについてのレシートに当てはまります。
• 当社の時計。

紛争で最も強い立場をとるには、レシートを、お客様ご自身が管理する記録と組み合わせてください。

レシートの提示の仕方#

レシートがお客様の手を離れるとき、短い添え状があれば、誤解のほとんどを防げます。よい添え状は5つのことを行います：

1. レシートが示すことを、レシート自身の言葉で述べる。 「10月14日09:41:07 UTCに、当社の鍵の保持者が、proof v3 deliveredというラベルのもとで、SHA-256 4d9a…7d62をTrustviceに提示した。」
2. それが誰の事実かを述べる。 当社による申告か、Trustviceによる観測か。
3. 証拠を一緒に送る。 レシート、それを検証した鍵セット、そして元のコンテンツ。
4. 独立した検証を促す。 /verifyとオフラインの手順を示し、相手方にtrustvice.comから自分で鍵を取得してもらいます。そうすれば、お客様が渡した鍵ファイルに頼らずに済みます。
5. 限界を述べる。 特に、時刻、観測点、そして空白について。

当社のガイド紛争のための証拠では、その全体の流れを紹介しています：紛争の前に、どの主張が必要になるかを決めておくこと、物事が起きた瞬間にレシートを残すこと、そして相手方がお客様を信頼せずに検証できる証拠一式をまとめることです。

レシートと法律#

ある裁判所、規制、契約の場面でレシートが証拠として認められるか、あるいは十分かどうかは、法域と事案によって異なります。レシートは、署名サービスに提示されたもの、または署名サービスが観測したものの技術的な記録です。法的助言でも、認証でも、法令遵守の証明でもありません。ご自身の弁護士に相談し、公開鍵に照らして検証されたレシートを、そこに記載された事実の証拠として双方が受け入れることを、契約に書き込むことも検討してください。

なぜこれを書き留めるのか#

はっきり述べられた限界は、主張よりも多くの信頼を築きます。レシートの有用性は、人々がそれをどれだけ正確に説明するかで決まるからです。当社自身のページがレシートの証明する内容を誇張している箇所を見つけたら、/contactからお知らせください。修正いたします。