Where to get/buy a CSR generated S/MIME certificate

Question

I'm not sure if the question is eligable for this board as I ask for concrete service providers which can be kind of advertisement, but there is also technical issue involved, so I give it a try.

My concrete scenario is as follows:

I want to use S/MIME for EMail encryption. My decision was made in terms of S/MIME as all default E-Mail clients support S/MIME but not PGP without additional plugins. I also want to obtain a trusted certificate and not a self signed one because it will be easier to use with all contacted people in mind.

Now to the problem: I want to be future safe with my EMail archives. As far as I researched, most CAs create their S/MIME certificates with the html < keygen > tag. This lets the browser create a new private public keypair. No problem so far. However, a certificate is usually valid only 1-3 years. If I want to renew my certificate, I have to create a new private/public keypair from the browser. In terms of archiving my emails this leads to a bunch of keys which I have to store/backup and reuse if I want to read an archived email. Furthermore, I will have to try which key is the correct one for decrypting or need the concrete datum and a list at which time which keypair was used.

As far as I understand, this shouldn't be a problem with certificates I receive from CSR requests. I can reuse the CSR every time my certificate expires and keep the same key for all my mails over all years.

So now to the questions: Do you know any CA which offers S/MIME certificates generated by a clients CSR?

Is it even possible to use a default server certificate for S/MIME? (With another email then webmaster, root, ... @mydomain.com but something like theo@mydomain.com which is not a default email adress for getting a class 1 domain validated server certificate)

Or do you have other ideas how to obtain long time durability without a mess of keys?

Answer 1

The theory is that as long as you keep your old keys, your email software will still be able to decrypt your received emails. That the certificate is expired means that other people won't accept to use your old public key to send you new encrypted emails, but reading your mailbox on your side does not entail using your public key or your certificate, only the private key. In other words, certificates expire, but private keys do not. Note that usual email software indexes keys by certificate (they have a certificate, and the certificate links to the corresponding private key) so you'd better keep the certificates around, even if expired.

Under this theory, there is no problem in generating a new key pair whenever you want a new certificate, except maybe storage space for accumulated private keys. One RSA private key would take less than 2 kB, so once key every 3 years will not fill your disk up any time soon. However, this may be an issue if you keep your private key on a smart card: smart cards are not eternal and not easy to backup, so they imply a risk of key loss (and thus data loss). Reusing the same key pair for a new certificate, instead of generating a new one, will not help for that, anyway.

Professional CA are supposed to follow their Certification Practice Statement which often requires new keys for certificate renewals. This requirement can be there for a lot of reasons, not necessarily good ones. One argument, for instance, goes thus: key cracking algorithms take time; by using a long-lived key (key life extending over many years and certificate renewals), you are giving more time to the attacker to break your key. This is not a very good argument because breaking an old key is already interesting for an attacker (it grants access to old emails), but that's a nonetheless widespread argument. Forcing new key pairs is also an easy way to enforce longer keys on a regular basis. Therefore, many CA will not easily accept a pre-made CSR.

Of course, you can potentially alter your browser's code (assuming it is open-source) to pretend to generate a new key, but actually reuse the previous one. The CA cannot really prevent that, unless it checks explicitly that your new key is distinct from the previous one.

---

Another facet of the issue is that encryption keys should be escrowed (i.e. backupped somewhere). Indeed, losing your private key implies using access to old emails encrypted with that key. So the storage policy for your private key is already complex, out of necessity. Enlarging that policy so as to be able to cover a dozen keys instead of one seems unlikely to be that much an issue.

---

Summary: while this does not answer your exact question, I would recommend that you do not insist on keeping the same private key across certificate renewal. Generating a new key pair ought to be fine, and it is at least arguable that changing the key is "A good thing". A one new certificate per 3 years, or even per year, it won't be "a mess" before your own demise (which we wish you to be as far in the future as possible).

Key life cycle management is a hard problem. Though simplicity is, all other things being equal, a good thing, there is a point at which too much simplicity begins to degrade usability or security.

("One Ring to rule them all" looked like a good idea at the time.)

Answer 2

There are certain rules Certificate Authorities need to follow in order to issue trusted certificates (one of these is that the certificate can not be valid for longer than 3 years)

In the case of archiving you can keep a copy of old certificates (it will show as expired if you try and use it for sending emails after the expiry date) but it will allow you to still view the old emails

The certificates are stored deep in the computers registry - the web browsers hold a short cut to this (they need to for SSL purposes)

When you order a certificate the private key is created on the computer you order through. As you place the order it sends a CSR (Certificate Signing Request) to the issuer to create one for you that matches your Private Key

Once these certificates are created they are fixed (which is why everyone relies on them) so when you "reissue" or "renew" you are essentially replacing the old certificate with a new unrelated one (in your account the time is edited to match)

Answer 3

I haven't seen any CAs that offer this feature, but if you join those asking at the StartCom forum, perhaps they will be more likely to consider adding support in the future. The discussion is at https://forum.startcom.org/viewtopic.php?f=15&t=1680