Requested s/Mime support

Feature Requests
22

For S/MIME certificates it is important to have certificates that last as long as possible (one year at least). Users will need to keep around all old certificates indefinitely in order to decrypt old mails. Adding one certificate per year is already less than ideal. Having to deal with another certificate every three month would mean 40 certificates to keep around after 10 years.

23

Do you really need the old certificates to decrypt, or does the old private keys suffice? (I never really used S/MIME, so I really don’t know.) Even if certificate lifetime is only 30 days, you could always get a new certificate for the same private key and thus keep the same private key for quite a long time.

24

I think S/MIME may work a bit differently than TLS…
But generally, the private key should also be changed (as often as possible).
So the default (60 day renewals) will actually generate 61 “key” pairs over a ten year span.

2 Likes
25

As LE doesn’t trust ‘did you see the token in the mail sent to admin@example.com/whois record/caa?’ as valid domain ownership method, I don’t think they will consider sending a mail to your email is proof enough for s/Mime cert?

2 Likes
26

Others were able to satisfy their “email ownership”.

  1. Send email from your email address (“user@email.address”)
  2. LE sends a verification reply email to “user@email.address” with “instructions” (click this link | reply to this email | etc.) to create the private key and actually request a cert.
    [Hopefully some method that allows the client to key the private key private]
  3. On validation success: S/MIME public cert is provided in new reply email.
  4. User enters S/MIME cert into their email client software.

Version 0.001 [completely manual client process]

2 Likes
27

Version 0.002 Delegate cert processing to an authorized “agent”.

  1. Install “agent” [work in progress]
  2. Run “agent” and choose: “Create new SMIME cert”
    Agent requests information:
  • enter “email address”
    [behind the scenes: private key is created and “CSR” is generated]
    returns “CSR” and instructions for validation/processing.
  1. User sends “CSR” in email (to some processing address: i.e.“smime@LE”) be processed and awaits for reply.
  2. On success: LE replies with public cert
    On failure: LE replies with reason(s)
  • address mismatch, etc.
  1. User runs agent and chooses “Process SMIME request”
    Agent requests public cert contents and completes the cert process.
  • error codes may be returned
    Improper entry, cert mismatch, etc.
  1. User runs agent and chooses export current cert
    Agent asks for format, etc.
    User chooses desired format (say PFX)
    Agent produces desired output file and user is asked to name and save this new file.
  2. User inputs new file into client email program.
2 Likes
28

There’s already an existing ACME proposal for S/MIME certificates via ACME: https://tools.ietf.org/html/draft-ietf-acme-email-smime-06 That’s independent of Let’s Encrypt and doesn’t mean they will support it or plan to implement it or something like it; but if Let’s Encrypt ever wants to support S/MIME certificates, this could be a possible way to implement it.

The draft is discussed on the IETF ACME mailing list (where also RFC8555 was discussed before it got finalized): https://www.ietf.org/mailman/listinfo/acme

7 Likes
29

It’s so frustrating that S/MIME is completely dead for private individuals because there are no free S/MIME certificates available with a duration of 1 year or more. :cry:

1 Like
30

I know a CA can issue free S/MIME certificates with a duration of 1 year.

The certificate ExtKeyUsage includes ClientAuth and EmailProtection, the KeyUsage is 0xb0 (DigitalSignature, KeyEncipherment, DataEncipherment)

The certificate chain is
GDCA TrustAUTH R5 ROOT (https://crt.sh/?q=0f36385b811a25c39b314e83cae9346670cc74b4)
GDCA TrustAUTH R4 Primer CA (https://crt.sh/?q=14c2b33bbf6ebd84fca7015413ebd0433e171a98)

The CA is GDCA-TrustAUTH, you have to register a account in order to apply for the free certificate. The application address is https://certmall.trustauth.cn/Home/FreeEmail/index.html , you need to login before applying.

31

Interesting. Of course they should let me create the key, otherwise it is a joke :partying_face:. I will check them out.

32

Sure, you can use your own CSR.

33

OK. I tried to use their website using google translate. They seem to be asking for a mobile phone number.
The website neither accepts the phone number with two leading zeroes followed by the country code and the rest of the number, nor by “+” followed by the country code. It says “wrong format”.

@JemmyLoveJenny
Does it work with non-chinese phone numbers?

Edit: I noticed that the english wikipedia lists MeSince as a provider of free S/MIME certificates with a duration of 39 months.Does anyone know how to use their services without using their software?
2nd Edit: Looks like MeSince will create the private key for you. Not recommended.

34

It seems that they require a Chinese phone number, but you can use free virtual phone number , e.g. http://www.z-sms.com/
And AFAIK, MeSince is not normal S/MIME and it only works with their software.

35

have a look at these CA’s https://en.wikipedia.org/wiki/S/MIME

Though generally i would be running my own CA for S/MIME as it doesn’t require a public CA

36

There are no free offerings in that list with a 12+ months duration that let you generate your own private key.
Of course it requires a CA, otherwise you get the usual warnings which will make your correspondents mistrust your messages

1 Like
37

I've been looking into this recently and it's something I would also really like to see. My proposed solution would be something like the following:

  1. Script uses a new certbot command (or option) to request a key pair for the e-mail address(es).
  2. The domain(s) used by the e-mail address(es) are checked for a valid Let's Encrypt key pair that can be located by certbot. If one or more cannot be found, the request fails.
  3. certbot requests and stores a longer lasting (a year or more?) key/pair suitable for e-mail encryption and signing of the requested address(es).
  4. Though the key/pair is longer lasting than normal, it must still be re-checked within 90 days as for a domain certificate in order to confirm it is still valid. If it is not, or if it is not "refreshed" within 90 days then it will be added to a revocation list. This periodic check can also be used to issue a new key pair if there are any problems (Let's Encrypt intermediate CA is updated, security standards have changed etc.).

Basically the assumption is that if Let's Encrypt was able to issue a certificate for a domain, then it should be able to issue certificates for any e-mail address using that domain. Verification may need to be DNS based to be sure, since this is the level at which NX (mail server) records are controlled, though I'd argue that any verification should suffice as long as the domain has suitable DMARC and SPF record(s), because if it does then any malicious mail server you might control won't have its e-mails accepted by any DMARC and SPF enabled service (such as gmail). It may also be worth checking for a valid Let's Encrypt certificate for the mail server(s) themselves (since a mail server is what will most likely be requesting the e-mail certificates anyway).

Actually installing the e-mail certificate(s) will be left up to the user in the short term, who will need to decide how to get each certificate to the correct end user to install into their e-mail clients (and then distribute to their recipients). For a corporate setup this can probably be handled with a script installing the key pairs into an LDAP service.

For smaller setups there are some hackier options like handling automatic signing and decryption on the server for users who do not send outgoing encrypted/signed messages; this isn't as secure of proper end-to-end encryption but for a private setup it's fine if you trust your mail-server.

Long term it would be nice to see some automated installation methods such as setting an LDAP record, as LDAP isn't a bad thing for e-mail providers to setup anyway, especially if you're already setting up Let's Encrypt, plus the million other components dovecot/postfix required. :wink:

38

I'm pretty sure this assumption is flawed. I would not trust such a certificate for S/MIME.

4 Likes
39

As I said, it may require the domain be validated on the basis of a DNS check or to have restrictive DMARC and SPF records.

In the DNS validation case, if a malicious actor has control over the DNS records then they already have the ability to edit the NX records, so they can redirect the mail servers anywhere they like, so you're already fully compromised anyway.

Meanwhile with restrictive DMARC/SPF records even if you were to gain a key pair for an e-mail by compromising only a web server or other service, you wouldn't be able to send signed e-mails pretending to be someone else because recipient mail servers should reject any sender not identified by the DMARC/SPF records.

40

@Haravikk Correct me if I'm wrong, but I thought S/MIMEs certificates are specific for email addresses. By only validating a domain, you're empowering perhaps THOUSANDS of users (depending on the server) with a single validation? How does that compute?

E.g., if alice@example.com gets a certificate and the domain example.com gets validated, what would prevent her from getting a certificate for bob@example.com, if the validation is just for example.com?

Also, an RFC already exists for ACME support for S/MIME and describes the protocol for validating an email address. Which makes sense. Validating just a single domain to issue perhaps thousands of certificates for email addresses does not.

3 Likes
41

Sorry, I think maybe I didn't explain it clearly enough.

The domain validation is only for determining if you're allowed to request certificates for e-mail addresses on that domain. The actual issued certificate would only cover specifically named e-mail addresses, it wouldn't be a catch all covering all e-mails on the same domain.

So for typical usage you'd request one certificate for each individual mailbox that you want to offer encryption to, but the command should be able to support a single certificate for multiple addresses to cover cases where a single user has multiple mailboxes, aliases etc.

I wasn't aware of that RFC for ACME though, it's good if it's already been looked into. That said, it seems like they're looking at providing it as a client service (for the e-mail user); not that there's anything wrong with that but it's a lot more complicated due to the need to asynchronously handle e-mails and replies. My proposal would be more aimed at system administrators providing the key/pairs to users on their behalf.