Some digging results on Indirect CRLs:
Status as of May 2020: Indirect CRL CLI and support (message seems to be unanswered on the openssl-users mailing list)
Post of November 2017: Re: [openssl.org #3097] Incorrect revocation
status with indirect CRL
An earlier post of May 2011: Handling
Indirect CRL Issuer
Modern theory of authentication is that a human user should pass a challenge from two (or all three) of the following catagories:
Something you know (ie password)
Something you have (ie yubikey, OTP app, etc)
Something you are (biometric, fingerprint, etc)
Certificate-based mTLS (with a proper CA as you describe) provides a very strong challenge #2, but ...
Adding some color, please see Mike Ounsworths answer.
The device therefore has two private keys which nobody should ever get access to.
This is incorrect. The device has ONE private key, and one other certificate (the root CAs). A certificate is NOT a private key, it is an attestation that the signature it contains was generated using a private ...
TPM and HSM's has key hierarchies that encrypts your private key. For simple understanding you can say it "Master Key". Master Keys are generated and stored within the TPM and HSM itself and are never exposed to any software, process or user. All operation related to these keys happen inside TPM and HSM.
TPM and HSM are also hardened w.r.t ...
Let's do a thought-experiment.
Imagine a device whose purpose in life is to hold a private key. There are a couple of things it will do for you; you can ask it:
Please wipe your own memory and generate a new private key.
Please give me the public key associated with your stored private key.
Please use your stored key to sign or encrypt this data.
Please use ...
DISCLAIMER: This answer is a wild abuse of RSA keygen. I would think really hard about whether your use-case will allow HMAC signatures instead of RSA signatures before you resort to a kludge like this.
I would also consider a centralized key-management solution where the server generates the user's keys and gives it to them as a password-protected ssh or ...
It's possible, but there are some caveats to be aware of.
At first glance, it might seem that ECDH lends itself well to this, as an ECDH private key is nothing more than a 256-bit value.
So, in theory, you could simply take the SHA256 hash of your password, which will return a 256-bit value, and use this as the ECDH private key. Then, the ECDH public key ...
... is my understanding correct that primary keys and subkeys are all
key pairs consisting of a private and a public key?
Absolutely. Sometimes to keep it simple we say "key", where as actually we mean "key pair".
... handling the public primary key? Is this the one that should be
shared with others or uploaded to a key server?