docs: updated the section about discovering vulnerabilities and aband…

…oned law repositories

specification/cross-repository-timestamp.md

@@ -82,10 +82,12 @@ This is crucial in establishing a reliable network of trust.
 As highlighted earlier, the process of securely creating local copies, authenticating, and
 applying updates to digital law repositories is available to all interested parties.
 However, in this section, we turn our attention specifically to reputable institutions
-such as libraries, universities, and archives. It is crucial to note that, although
-human and technical errors are always a possibility, the framework operates under the
-assumption of good faith regarding internal employees of these institutions. Rare cases
-when a trusted party is malicious or compromised can be handled out of band.
+such as libraries, universities, and archives. It is crucial to note that, although human
+and technical errors are always a possibility, the framework operates under the assumption of
+good faith regarding internal employees of these institutions. TAF should provide tools for these
+institutions to detect human and technical errors as well as compromises in their own or other
+trusted institutions' repositories. These compromises can then be handled out of band.
+The discussion of these tools, however, falls beyond the scope of this specification.
 
 The goal is to engage as many reputable institutions as possible, ensuring they conduct
 out-of-band authentication and vouch for the authenticity and timeliness of digital law
@@ -108,6 +110,11 @@ endorsed by that entity. This method reduces the number of necessary out-of-band
 authentication requests and spreads the remaining requests more evenly across a larger
 pool of institutions.
 
+Institutions can compare data regarding digital law repositories after conducting
+out-of-band authentication and utilizing the TAF updater to clone and update local
+versions of governments' digital law repositories. This process enables the detection
+of invalid copies within a web of trusted institutions, such as instances where
+an institution may have cloned an attacker's fork.
 
 ### Disaster recovery
 
@@ -121,34 +128,86 @@ authenticated updates.
 
 In other scenarios where key rotation is necessary, the TUF framework provides comprehensive
 guidelines to handle such situations. This process can be executed without the need to establish a
-new repository, and it does not requie attesting institutions to update their out-of-band data.
+new repository, and it does not require attesting institutions to update their out-of-band data.
 By following TUF's specified procedures, an existing digital law repository can continue to be
 validated and trusted.
 
 
-### Government abandoning their digital law repository
+### Handling discovery of vulnerabilities in hash algorithms and asymmetric cryptography
 
 Considering the long-term perspective, where legal data must remain accessible for decades or
 even centuries, it is can be assumed that some governments may eventually abandon their digital law
 repositories. In these situations, the out-of-band authentication previously conducted by
 various institutions becomes essential. Even in the absence of direct support from the
 original government publisher, users can still approach these institutions. Having already
-validated the repository’s authenticity and retrieved the out-of-band data, they can continue
+validated the repository's authenticity and retrieved the out-of-band data, they can continue
 supplying this information, ensuring that interested parties maintain the ability to
 authenticate and access the legal content they need.
 
-
-Note: this is based on what's written in the grant proposal and my understanding of
-what that would mean from the technical standpoint.
-
-Given the extensive time frame of decades and centuries that we are considering for
-maintaining accessibility to legal data, changes in secure hash algorithms are inevitable.
-
-The TUF specification mandates that all targets metadata files store hashes of the target
-files, ensuring that clients can verify the integrity of these files. The snapshot
-metadata file, in turn, records the version number of the targets metadata file, as well
-as that of the root metadata file. The timestamp metadata file then stores the hash of
-the snapshot metadata file, facilitating a quick check for updates.
+Given the extensive time frame of decades and centuries that we are considering for maintaining
+accessibility to legal data, changes in secure hash algorithms are inevitable. The TUF specification
+mandates that all targets metadata files store hashes of the target files, ensuring that clients can
+verify the integrity of these files. The snapshot metadata file, in turn, records the version number
+of the targets metadata file, as well as that of the root metadata file. The timestamp metadata
+file then stores the hash of the snapshot metadata file, facilitating a quick check for updates.
+
+Similarly, in considering the long-term implications for digital law repositories, it's essential
+to acknowledge potential vulnerabilities in asymmetric cryptography
+Take, for example, a digital law repository where the keys were generated in 2020 using a specific key
+generation method, denoted as method X. Fast forward a decade, numerous updates to the digital law have
+been made, and a security flaw is discovered in method X. This flaw potentially compromises the first n
+commits, as they were signed with keys generated by the now-vulnerable method X.
+
+If a government is still maintaining its digital law repository, it can create hashes using new and secure
+algorithms or execute key rotation and sign. That means that, going forward, an attacker would not be able
+to exploit these vulnerabilities. However, they would still be able to attack commits predating these updates
+and create their fork  of a digital law repository. If institutions only stored their out-of-band authentication
+of the first commit in the chain, there would be no way to know which chain was authentic. By periodically
+time-stamping the up-to-date state of all attested-to repositories, it becomes impossible for an attacker
+to fork the authentication chain without detection.
+
+After performing the initial out-of-band authentication, the attesting institutions will periodically run
+the TAF updater, which will validate and pull the latest updates published by the governments.
+The system needs to preserve enough metadata so that the institutions don't need to take any affirmative
+action in case of a discovered exploit. This could mean maintaining a record of the most recent validated
+commit every time the updater updates their copy of a digital law repository. Institutions should also
+validate against other institutions, meaning that they would compare the information they have about
+digital law repositories. They would not only compare the first out-of-band commits but also the most
+recent commits that they pulled. That way, if there was a malicious fork, and a trusted institution grabbed
+it, it would be detected as a divergence between all the institutions. The system would not expect all
+institutions to have the same latest commit; the latest validated commit of an institution whose copy
+is older is expected to be in the list of all authenticatable commits of other institutions.
+
+
+### Governments abandoning their digital law repositories
+
+
+Problems arise when governments cease to maintain their authentication repositories. If such a case,
+it won't be correct to assume that a repository will be updated following the discovery of vulnerabilities
+described in the previous section. One possibility is for governments to add and sign a capstone for a repository
+that would  effectively render it un-updatable beyond that point. Issues like an attacker modifying the commit history
+should be detected by the updater. If a government abandons their repository without providing such a capstone,
+institutions will need to provide metadata within their own repository that a repository they reference has been abandoned.
+
+
+Challenges emerge when governments discontinue the maintenance of their authentication
+repositories. In such scenarios, we cannot rely on the assumption that the repository will
+be updated in response to vulnerabilities as outlined in the prior section. The
+introduction and signing of a final 'capstone' commit by a government could serve as an
+official end-of-life marker for a repository, indicating that no further updates should occur.
+Issues such as an attacker altering the commit history, whether by modifying old commits
+or adding new ones after a capstone, should be identified by the updater.
+If a government abandons their repository without providing such a capstone,
+institutions will need to include metadata within their own repository indicating that
+the referenced repository has been abandoned
+
+
+Although this does not prevent an attacker from attempting to alter the
+commit history, it does communicate to users that any subsequent updates are not
+legitimate. The updater is designed to detect such unauthorized changes. If a government
+abandons its repository without implementing such a capstone, it becomes necessary for
+institutions to annotate within their own repositories that the referenced government
+repository has been forsaken.
 
 In scenarios where a government ceases to maintain its authentication repository, the
 responsibility falls on attesting institutions to manage the creation of hashes using new
@@ -158,43 +217,24 @@ secure hashing algorithm, and subsequently update the targets metadata with thes
 hashes. This process also requires updates to the snapshot and timestamp metadata to
 accurately reflect the changes made to the targets metadata.
 
-It is important to note that these attesting institutions will then store this
-information in their metadata files. Consequently, users will be able to validate a
-government's digital law library solely based on the information provided by attesting
-institutions. However, it is crucial to understand that these institutions will not
-update the actual digital legal documents, which will remain in the state they were in
-when the government last published updates. Multiple institutions can undertake this
-responsibility, and a user's software will trust any files that match the secure hash
-algorithm listed by trusted entities.
-
-Dealing with conflicting secure hashes should be approached with caution, as it could
-indicate malicious activity or a compromise of a trusted party. In such rare cases,
-resolution may require out-of-band communication or other manual intervention.
-
-
-
-In considering the long-term implications of digital law repositories, it’s essential to
-acknowledge the potential vulnerabilities in the asymmetric cryptographic algorithms we
-currently rely on. Take, for example, a digital law repository where the keys were
-generated in 2020 using a specific key generation method, denoted as method X. Fast
-forward a decade, numerous updates of the digital law have been made, and a security flaw
-is discovered in method X. This flaw potentially compromises the first 1000 commits, as
-they were signed with keys generated by the now vulnerable method X.
-
-TUF is designed to handle key rotation effectively, ensuring that from the 1001st commit
-onwards, all transactions are secure. However, this situation necessitates prompt action
-from the attesting institutions.
-If any of the first 1000 commits is still marked as verified, it becomes impossible to
-distinguish between the genuine government-maintained repository and a fork that might
-exploit the discovered cryptographic vulnerability. It is, therefore, imperative for
-attesting institutions to act swiftly and update their records to reflect the changes and
-maintain the trustworthiness of the digital law repository.
-
-In the event that a government ceases to maintain its digital law repository, attesting
-institutions can take a proactive role to ensure the ongoing security and authenticity of
-the repository. Similar to addressing vulnerabilities in hashing algorithms, these
-institutions can use their own secure keys to sign the metadata. In this case,
-recalculating hashes would not be necessary.
+
+### Note
+
+
+The grant application includes this paragraph:
+
+Changes in the secure hash algorithm will be handled by an attesting institution
+creating hashes using the new algorithm.  Any attesting institution will
+download the original files, perform a different secure hash algorithm, and then
+republish that metadata.  A user's software will trust any files that match the
+secure hash algorithm listed by all trusted entities. Note that it does not make
+much sense to automatically deal with conflicting secure hashes in a way that
+ends up with a file being trusted, because this is evidence that a trusted party
+is malicious or compromised.  This rare case can be handled out of band.
+
+We did not envision a scenario in which institutions would be capable of publishing such updates.
+We should discuss.
+
 
 
 ## Example
@@ -203,7 +243,7 @@ Let's say the following:
 
 - City of San Mateo, City of Baltimore, and District of Columbia all manage their own
 repositories, each containing their respective laws and legal documents.
-- University of Wisconsin Law Library and University of New York Law Library, acting as
+- University of Wisconsin Law Library and New York University Law Library, acting as
 secondary, validating entities, clone the aforementioned repositories, perform
 out-of-band authentication to ensure validity, and then create their respective repositories.
 - In creating their own repositories, Wisconsin and New York universities will add an
@@ -219,7 +259,5 @@ cease to maintain their repositories, the data, having been preserved by Wiscons
 New York, remains available and authenticated up until the last point of update.
 
 In practical application, it's recommended to engage more entities than merely Wisconsin
-and New York, as discrepancies could aris/e between even trustworthy sources. Expanding
+and New York, as discrepancies could arise between even trustworthy sources. Expanding
 the network to involve a multitude of actors enhances the system's reliability and resilience.
-
-