... | ... | @@ -1146,6 +1146,32 @@ Update, 2021-06-04: there was [another iteration](https://people.kernel.org/mons |
|
|
this time based on DKIM-like headers, with support for OpenPGP
|
|
|
signatures but also "native" ed25519.
|
|
|
|
|
|
One key takeaway from this approach, which we could reuse, is the way
|
|
|
public keys are stored. In [patatt](https://pypi.org/project/patatt/), the git repository itself
|
|
|
holds the public keys:
|
|
|
|
|
|
> On the other hand, within the context of git repositories, we
|
|
|
> already have a suitable mechanism for distributing developer public
|
|
|
> keys, which is the repository itself. Consider this:
|
|
|
>
|
|
|
> * git is already decentralized and can be mirrored to multiple
|
|
|
> locations, avoiding any single points of failure
|
|
|
> * all contents are already versioned and key additions/removals can
|
|
|
> be audited and “git blame’d”
|
|
|
> * git commits themselves can be cryptographically signed, which
|
|
|
> allows a small subset of developers to act as “trusted
|
|
|
> introducers” to many other contributors (mimicking the
|
|
|
> “keysigning” process)
|
|
|
>
|
|
|
> The idea of using git itself for keyring management was originally
|
|
|
> suggested by the did:git project, though we do not currently
|
|
|
> implement the proposed standard itself.
|
|
|
>
|
|
|
> <https://github.com/dhuseby/did-git-spec/blob/master/did-git-spec.md>
|
|
|
|
|
|
It's unclear, however, why the latter spec wasn't reused. To be
|
|
|
investigated.
|
|
|
|
|
|
### Ryabitsev: Secure Scuttlebutt
|
|
|
|
|
|
A more exotic proposal is to [use the Secure Scuttlebutt (SSB)
|
... | ... | |