Tracking issue for generic (e.g. key) types and owned/ref aliases

[tarcieri]

In the latest release of spki it was changed to have generic AlgorithmIdentifier and SubjectPublicKeyInfo, along with *Owned and *Ref type aliases. This allows either zero-copy decoding with a lifetime, or decoding to an owned type with no lifetime (which enables e.g. on-the-fly 1-pass PEM decoding, since you can't borrow bytes from a PEM input).

However, other crates in this repo didn't receive a similar treatment. This is a tracking issue for those.

• pkcs1
  • OtherPrimeInfo
  • RsaOaepParams
  • RsaPrivateKey
  • RsaPssParams
  • RsaPublicKey
• pkcs5 pkcs5: remove lifetimes #1195
  • pbes2::kdf::Kdf
  • pbes2::EncryptionScheme
  • pbes2::Parameters
  • EncryptionScheme
• pkcs8 pkcs8: provide PrivateKeyInfoRef/PrivateKeyInfoOwned #1483
  • PrivateKeyInfo
  • EncryptedPrivateKeyInfo
• sec1
  • EcPrivateKey

[baloo]

pkcs8::EncryptedPrivateKeyInfo will require:

• pkcs5
  • pbes2::kdf::Kdf
  • pbes2::EncryptionScheme
  • pbes2::Parameters
  • EncryptionScheme

[tarcieri]

Ugh, splitting up pkcs5 sounds rather painful. The others are relatively straightforward but that one sounds like it will involve a lot of duplication.

Perhaps we can save EncryptedPrivateKeyInfo for the end, or possibly even make it just an implementation detail and remove it from the public API entirely. There are already helper methods that handle decryption/encryption.

[carl-wallace]

At present, EncryptedPrivateKeyInfo is duplicated in #1165.

[tarcieri]

Okay, I guess we should find a solution.

Perhaps we can find a way to remove the lifetime that will still work on heapless targets.

[baloo]

I don't think there is too much duplication though. Pretty sure I can make it work without too much drama. I'll take a shot at it later today.