Key material typing, rotation, context and hardware support

[veikkoeeva]

Currently there are rough sketch of separate key material and key handling code. In the code this shows as SentitiveMemory, PublicKeyMemory, PrivateKeyMemory and related types.

For the plain key material, the idea:

1. Use type checking as rudimentary safeguard against misusing public/private key material.
2. Have a type that can include context information and information on data layout (e.g. how the key material is stored) with the raw material.
3. Have a well defined type to access the material if it is located actually in a security chip, a separate process space, remote server and so on.
4. Have a baseline to work towards key management functionality.

Some of these will be tested (e.g. TPM/security chip usage), for others such as Pkcs11Interop it may make sense to write an integration example.

Further notes and thoughts

Trying to remove the need to trust cloud providers
Quick update on Pluton and Linux
https://transparency.dev/application/strengthen-discovery-of-encryption-keys/ and at https://ioc.exchange/@matthew_d_green/109513247860625543.

Git Credential Manager Web Account Manager integration: https://github.com/GitCredentialManager/git-credential-manager/blob/main/docs/windows-broker.md, https://github.com/GitCredentialManager/git-credential-manager

https://github.com/ionescu007/tpmtool

NIST SP 800-63 Digital Identity Guidelines (Call for Comments on Initial Public Draft of Revision 4)
[Security and Privacy Controls for Information Systems and Organizations](https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final]

And material related to EU Cyber Resiliency Act.