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

Thank you, Allen. This is great content to explore!

I’d love to learn more about the differences between SSH and GPG/PGP
keys. I initially thought the key distinction lies in how they are
used. SSH for authentication and remote access, and GPG for encryption
and signing.

From my perspective, in the context of expanding the decentralized
space, whether it's SSH or GPG doesn't matter much.

You also made me realize that the GitHub API supports both SSH and GPG
keys associated with a user account.
> curl https://api.github.com/users/filip26/gpg_keys

Best regards,
Filip

On Fri, Dec 13, 2024 at 11:08 PM Christopher Allen
<ChristopherA@lifewithalacrity.com> wrote:
>
> 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

Received on Friday, 13 December 2024 23:24:38 UTC