Re: DID Method utilizing PGP/GPG keyservers for seamless on-boarding

Having been involved with PGP since the early 90s (I licensed them RSAREF,
the only patent license available to free software developers), I have
moved almost away from PGP Keys to SSH for everything. In fact, the origin
of the Rebooting Web of Trust was meeting with the former CTO of PGP and we
both agreed it was time to retire it and start over.

I have two DID napkin sketches related to SSH that I'm playing around
during some free time I'm hoping to get during the holiday break.

The first is a did:key style method that uses SSH keys which can be
bootstrapped from GitHub/GitLab, etc.

For instance, you can get my SSH Auth Keys from GitHub:

```
% % curl https://github.com/ChristopherA.keys

ssh-ed25519
AAAAC3NzaC1lZDI1NTE5AAAAIMNOXm9gTvmGKttlmTchKqiQcqLObHgfABjSmGzZk4DY

ssh-ed25519
AAAAC3NzaC1lZDI1NTE5AAAAICs/ct9OdmHmfXNNdDpHnTY0O5Ru5EFaa0LNMBvF5p9U
```

More importantly, since I practice key separation, you can also get my
signing keys GitHub:

```
% curl https://api.github.com/users/ChristopherA/ssh_signing_keys
[
  {
    "id": 184891,
    "key": "ssh-ed25519
AAAAC3NzaC1lZDI1NTE5AAAAINTazxjqxsdh3Sv/7fxSTgr3qlCVByYoGDHHe428Fubp",
    "title": "eurynome.local/sign_id_25519_christophera@github.com",
    "created_at": "2023-10-26T06:28:34.882Z"
  },
  {
    "id": 219925,
    "key": "ssh-ed25519
AAAAC3NzaC1lZDI1NTE5AAAAIMU0/lvWurXvUcrvYNgfb02Ska0qpwC/yv22dvDIxxzh",
    "title": "kymindis.local/sign_id_ed25519_christophera@github
2024-01-04",
    "created_at": "2024-01-04T20:13:55.503Z"
  },
  {
    "id": 233116,
    "key": "ssh-ed25519
AAAAC3NzaC1lZDI1NTE5AAAAIC2O9n9I7RK1DXvnd7+eKYT+0Cr1bCJvdN/pdkb7625S",
    "title": "sign_id_ed25519-mnemosyne.local-christophera@github_2024_02_26
",
    "created_at": "2024-01-26T21:35:28.362Z"
  }
]
```

There are equivalent web APIs for GitLab and most other git services.

The second area is leveraging git inception hashes (a specially formatted
and SSH signed first "0" commit to establish a root of trust for the repo,
since the SHA1 hash is weak).

You can see an example the one I'm playing around with in the commit
message for this inception commit:
https://github.com/ChristopherA/Open-Integrity-Inception-Test/commit/c22a885cc662aa0843c6f8523ddde6cbd9bafe69

```
Initialize repository and establish a SHA-256 root of trust
Signed-off-by: ssh-ed25519
AAAAC3NzaC1lZDI1NTE5AAAAIC2O9n9I7RK1DXvnd7+eKYT+0Cr1bCJvdN/pdkb7625S;2C
<U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgLY72f0jtErUNe+d3v54phP7QKvVsIm903+l2RvvrblIAAAAEZmlsZQAAAAAAAAAGc2hhNTEyAAAAUwAAAAtzc2gtZWQyNTUxOQAAAEB8USEis6d49g/F6SRPlyLz6q5nmsbDDg+OncxMGH2zLHmGbPDaVF6SGdMYR5M9Gr+SyHn4sP1trq/ohFENnckD>

This key also certifies future commits' integrity and origin. Other keys
can be authorized to certify additional commits via the creation of an
./_repo:allowed_commit_signers file. This file must initially be signed by
the repo's inception key, granting these keys the authority to certify
future commits to this repo, including the potential to remove the
authority of this inception key for commits. Once established, any changes
to ./_repo:allowed_commit_signers must be certified by one of the
previously approved signers.
```

This might resolve to a DID document something like:

```
{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:repo:deedb3380e3e75266a009ee43b1dec54619f1b0f",
  "verificationMethod": [
    {
      "id": "did:repo:deedb3380e3e75266a009ee43b1dec54619f1b0f#ssh-key-1",
      "type": "SshPublicKey",
     "controller":
"did:repo:dbe44e2f99347b403b8b649605dd718bf5a69614?serviceEndpoint=https%3A%2F%2Fgithub.com%2FChristopherA%2FChristopherA"
      "publicKeySsh": "ssh-ed25519
AAAAC3NzaC1lZDI1NTE5AAAAIC2O9n9I7RK1DXvnd7+eKYT+0Cr1bCJvdN/pdkb7625S"
    }
  ],
  "authentication": [
    {
      "id": "did:repo:deedb3380e3e75266a009ee43b1dec54619f1b0f#ssh-key-1",
      "type": "SshPublicKey",
      "controller":
"did:repo:dbe44e2f99347b403b8b649605dd718bf5a69614?serviceEndpoint=https%3A%2F%2Fgithub.com%2FChristopherA%2FChristopherA"
      "publicKeySsh": "ssh-ed25519
AAAAC3NzaC1lZDI1NTE5AAAAIC2O9n9I7RK1DXvnd7+eKYT+0Cr1bCJvdN/pdkb7625S",
      "proofPurpose": "authenticationCommitOnly"  // Indicating restricted
use specifically for commit authentication
    }
  ]
}
```
You can see some of my raw notes about this at
https://gist.github.com/ChristopherA/dcf963c3849bc0d67b35c215efd15f86. They
can be used to bootstrap an "Open Integrity" system using DID that point to
distributed git repos (not github or gitlab, but the repo hash), that can
serve as DID documents, as self-signed verifiable credential data stores,
or serve to carefully protect the provenance of the entire contents of a
git repo.

All of this can be accomplished completely through git, ssh-keygen, and a
shell scripting language (I currently use zsh.). No blockchain or custom
cryptographic code required. Longer term, I'm hoping to add transition to
using Gordian Envelope to leverage the ability to elide keys — we added SSH
capability to our envelope cli too earlier in the year:
https://github.com/BlockchainCommons/bc-envelope-cli-rust

My raw notes are getting somewhat dated, as I had to set this project aside
for paid opportunities, but as I said, my goal is to get some kind of
working proposal over the holidays (unless you want to sponsor my work, or
join in contributing code to the project, and I'll accelerate it!)

-- Christopher Allen