About Identities

[kim]

@mmassi

This ID “schema” ( repo:root/branch/filename )

I like this!

(… ← pow’ing the 20 characters minium post length)

[onur]

@mmassi

The reasons why we are not formally switching to git-did are:

• The spec is still preliminary.
• Most importantly, the git-did resolution step ultimately relies on URLs which in turn rely on DNS and HTTPS, and DNS is in practice a centralized system that we don’t want to depend on to use radicle.

Regarding DNS, this is true for the private TLDs controlled by mainly ICANN. With a system like Handshake however it would be more decentralized. We could even bid in the auction for the .rad TLD and could have unique name.rad URIs on-chain. What I want to say is, if centralization is the issue, it would be interesting to consider an alternative root zone file, that is maintained peer-to-peer.

[kim]

@onur

if centralization is the issue, it would be interesting to consider an alternative root zone file

While handshake is cool, it doesn’t solve the issue, for two reasons:

1. The data served from this name is still vulnerable to history rewriting attacks, as it is not stored nor checkpointed on-chain
2. Acquiring the name has to be expensive for each owner of the name, not just the owner of the TLD

radicle-registry is in some ways similar to handshake, conceptually, but can address both concerns. It means, however, that people would have to pay for their own onboarding, and that radicle-link cannot be used without validating on-chain data.

[kim]

@kim

S/Kademlia

The goal of the crypto puzzle in S/Kademlia is to impede generating large numbers of node IDs, such that the attacker controls a majority of nodes on the network, or is able to partition it. I don’t think this is a viable threat for us, as long as the data is authenticated.

About finding a collision: well, no. Even SHAttered is still quite expensive, and hiding the colliding blocks in a plaintext file doesn’t seem realistic.

[mmassi]

@kim

About finding a collision: well, no. Even SHAttered is still quite expensive, and hiding the colliding blocks in a plaintext file doesn’t seem realistic.

I agree.

Moreover we hash, sign and verify canonical forms of the data structures which must still be valid json, leaving even less room for collision-inducing garbage.

That said, I was just wondering about how much we should build upon git and how much we should be independent from it.

Two cases that just occurred to me:

The root hash

Should this be the git SHA1 hash of the commit introducing the metadata fle? Or of its contents (its git blob)?
And what if the git repo is then converted to SHA256?

Would it be just better to use our own content hash function (nothing fancy, let’s start with SHA256), and handle eventual hash content function evolution on our own, independently from the underlying git repo?

Metadata file history “certification”

Each new revision of a metadata file that evolves according to TUF rules must point to the previous revision in an unambiguous way.
Using git commits this works (the pointer is the parent commit) but again it conflates these two functions of git:

• storing the history of file revisions
• providing Merkel-tree based certification of the whole contents of the history (using a given hash function, for now SHA1, in the near future SHA256)

The second function could work differently in other SCM systems. it is entirely possible that patch-based SCMs provide different content-hashing guarantees than what git does.

Now, one thing is hashing and signing code, which is a project development issue.
Each software project should choose a SCM (often git!) and use it with the guarantees it provides.
Another thing is signing and hashing user and project metadata files, which is something that radicle as a tool needs to perform its functions.
We already found out that for radicle metadata we should handle signatures at the radicle level and not at the git one.
Maybe this is the same for content hashes?

[mmassi]

More on signatures and key revocation

Signature structure

First of all an obvious fact: a signed artifact should refer to the key used to sign it, so that the same key can be used for verification.

This is important because the artifact cannot simply refer to the user that authored it. This information is important because it is what we ultimately want to assess checking the signature, but the signature check needs an actual key.

Therefore a signature should contain three pieces of information (plus, obviously, the signature itself):

• A user identity (which resolves to the user metadata file).
• A “local reference” to one of the keys stored in the metadata file.
• Since that “local reference” is not guaranteed to be globally stable in time (i.e. the key could have been revoked or, more subtly, different user metadata files could “name” different keys in the same way), the exact revision of the user metadata file that was valid at the time in which the artifact has been signed.

Using those three pieces of information a key is unambiguously identified and can be used to check the signature.
If the check succeeds we can have confidence that the signed item has in fact been authored by the referred user.

Key revocation and timestamps

To revoke a key the simplest thing to do seems to be generating a new revision of the metadata file without the revoked key.
Older signatures referring to previous revisions would still be valid and new signatures should refer to newer revisions which lack the revoked key.

The key here is that “should”: a malicious user that gained control of the corresponding private key could still generate signatures referring to older revisions, which by definition should be valid.

The point is that the revocation should mark a given moment in time: signature before that moment are still valid and signatures after that moment should be retroactively invalidated.

The problem here is that we lack a global, shared timeline encompassing different repositories (the one of the metadata files and the ones of signed artifacts).
We would have this timeline on a blockchain but here we operate on a set of independent repositories.

The best I can think of is the following:

• Each user metadata file (and perhaps specifically each key revocation) should carry a UTC timestamp.
• Each signed artifact (each signature) should also carry a UTC timestamp.
• In every repository these timestamps should guaranteed to be monotonic, perhaps with a given small tolerance.

Thanks to the third point it should be impossible to sign artifacts with a timestamp in the past, or at least “too much” in the past: specifically, with a timestamp preceding the previous one in the current branch timeline.

Therefore, while it is technically possible to use a revoked key to produce a signature that would, by itself, look valid, it should be impossible to use such a signature for an artifact inside a history that already contains timestamps past the revocation point.

Unless one tries a history rewrite, which hopefully should be impossible because the history itself should be protected by other signatures (but I’d like somebody to think more about this).