I would also add that your ability to pretend to be the client to the server is also limited, if ssh key based client authentication is used. This means that even if the host key is leaked, an attacker will not be able to push in the name of the attacked client. The attacker will be able to pretend to be the server to the client, and thus be able to get the pushed code from the client (even if the client just added one patch, the attacker can pretend to be an empty repo server side and receive the entire repo.
If ssh token based auth is used, it's different of course, because then the server gets access to the token. Ideally Github would invalidate all their auth tokens as well.
The fun fact is that a token compromise (or any other attack) can still happen any point in the future with devices that still have outdated ssh keys. That's a bit unfortunate as no revocation mechanism exists for ssh keys... ideally clients would blacklist the ssh key, given the huge importance of github.
WKD also lacks key revocation and CT Certificate Transparency.
E.g. keybase could do X.509 like Certificate Transparency.
:
$ keybase pgp -h
NAME:
keybase pgp - Manage keybase PGP keys
USAGE:
keybase pgp <command> [arguments...]
COMMANDS:
gen Generate a new PGP key and write to local secret keychain
pull Download the latest PGP keys for people you follow.
update Update your public PGP keys on keybase with those exported from the local GPG keyring
select Select a key from GnuPG as your own and register the public half with Keybase
sign PGP sign a document.
encrypt PGP encrypt messages or files for keybase users
decrypt PGP decrypt messages or files for keybase users
verify PGP verify message or file signatures for keybase users
export Export a PGP key from keybase
import Import a PGP key into keybase
drop Drop Keybase's use of a PGP key
list List the active PGP keys in your account.
purge Purge all PGP keys from Keybase keyring
push-private Export PGP keys from GnuPG keychain, and write them to KBFS.
pull-private Export PGP from KBFS and write them to the GnuPG keychain
help, h Shows a list of commands or help for one command
$ keybase pgp drop -h
NAME:
keybase pgp drop - Drop Keybase's use of a PGP key
USAGE:
keybase pgp drop <key-id>
DESCRIPTION:
"keybase pgp drop" signs a statement saying the given PGP
key should no longer be associated with this account. It will **not** sign a PGP-style
revocation cert for this key; you'll have to do that on your own.
- Why secrets shouldn't be passed in $ENVIRONMENT variables; though e.g. the "12 Factor App" pattern advises to parametrize applications mostly with environment variables that show in /proc/pid/environ but not /proc/pid/cmdline
Blockerts is built upon W3C DID and W3C Verified Credentials, W3C Linked Data Signatures, and Merkel trees (and JSON-LD). From the Blockerts FAQ
https://www.blockcerts.org/guide/faq.html :
> How are certificates revoked?
> Even though certificates can be issued to a cohort of people, the issuer can still revoke from a single recipient. The Blockcerts standard supports a range of revocation techniques. Currently, the primary factor influencing the choice of revocation technique is the particular schema used.
> The Open Badges specification allows a HTTP URI revocation list. Each id field in the revokedAssertions array should match the assertion.id field in the certificate to revoke.
If ssh token based auth is used, it's different of course, because then the server gets access to the token. Ideally Github would invalidate all their auth tokens as well.
The fun fact is that a token compromise (or any other attack) can still happen any point in the future with devices that still have outdated ssh keys. That's a bit unfortunate as no revocation mechanism exists for ssh keys... ideally clients would blacklist the ssh key, given the huge importance of github.