Allow importing of private s/mime keys (only in Settings as additional key)

[tomholub]

The primary imported key during setup still has to be openpgp
But this will add option to import a secondary s/mime key in settings
There should be a way to differentiate stored keys if they are openpgp or x509 (in KeyInfo or whatever gets stored), and this needs to be done in a way that would not break upgrades. That means we could do a storage migration on upgrade, or we could design it carefully to be forward-compatible without a migration.

[tomholub]

@wiktor-k ping - this appears to be the most important issue once you've settled your PR on pgpainless

[wiktor-k]

Got it 👍 I'll address this soon.

[tomholub]

To copy from our conversation - useful for future reference.

---

I did some further development in the S/MIME space.

My findings:

1. PKCS#12 files, like the one attached, are encrypted containers with
   private key and certificate. Problem with them is that we cannot get
   any info about the key before we decrypt it with password. It takes
   some time to do so (to be calculated) but all our functions expect Key
   object to have some basic info (like fingerprint, identities etc.)

So I propose that we extract stuff from PKCS#12 files (that are commonly
used to import/export private S/MIME keys) on import time and leave it
like that.

2. Inside PKCS#12 we've got one PRIVATE KEY and possibly multiple
   CERTIFICATEs. I just did a small proof of concept 0 and the good news
   is that the PRIVATE KEY can be encrypted or decrypted at will so I think
   we could emulate what we have with OpenPGP: dispose PKCS#12, encrypt
   private key and store encrypted private key + public certificate info in
   the chrome store. Then we can decrypt/encrypt the private key at will.

You can see the proof of code here:

(refresh if you don't see PKCS#12 file selector at the top, use file
from attachment).

As for the performance issues if we use this design then we pay only at
the import time (PKCS#12 decryption) but I'll gather more concrete data
later.

The only risk I didn't check is the prevalent use of MsgBlockParser that
may interfere with S/MIME (as S/MIME certs and private keys are usually
multiple blocks). I'll dig into that the next time.

---

Is it common at all, or at least reasonable, to share these keys in a format different than p12? For example some DER or PEM format?

---

PKCS#12 is already DER encoded. PEM doesn't exist for pure PKCS#12 files but exists for components (keys and certs). Even if there would be one the problems I've listed still remain (most importantly no way to inspect without decoding). PEM encoded (armored) collection of keys and certs are used (eg. Openssl).

---

That means there is possibility to use PEM encoding for the individual components - if I understood correctly. We just need the private key + one or more certs. Probably can get away with supporting just one cert. Then we could handle them similarly as OpenPGP afterwards (one PEM key, one cert). Is this true?

[tomholub]

Yes, but PEM encodes in armor headers each component. So private key is one PEM armored block then an owner cert is one PEM armored block then you can have N other certs (forming cert chain). And you need at least two blocks (one for private key one for the owner cert). For verification if we have a good key entire chain may be needed.

In openpgp it doesn't matter if you've got private or public key or N subkeys or M signatures. It's all encoded to one armored block.

Hope this helps clearing matters up.

[tomholub]

I suppose this is a subset-duplicate of #3530 ?