BTW StartSSL also just offers S/MIME certs for email encryption. This are no SSL certs. (Both are of course X.509 certs but that’s another matter)
Hi, what came into my mind when i always read the discussion about the S/MIME certs / wildcard is an trustchain.
That mean if letsencrypt was “proved” that someone “ownes” an domain, than why not generate on request an certificate that allow:
- issuing certificates for subdomain’s
- issuing certificates for emails under this domain ?
Because no normal people should be able to to issue any certificate. If they would be able to issue certificates they could act like a CA.
And AFAIK there is actually no way in the PKI used by TLS / S/MIME to restrict issuing of certs to subdomains.
Besides this a subdomain does not always have to be under the control of the owner of the main domain.
E.g. think of free hosters or dynamic DNS services.
this is not correct. Even if your USE the domain my-private.dyn-dns-server.com the control
is still on the owner of dyn-dns-server. He own the domain and if he which he could also
change the ip for short time to get hold of an my-private.dyn-dns-server.com zertificate.
So i think it is legitimately to build and trust tree with CA / SubCA same as the DNS Tree.
And yes it is possible to limit an certificate to subdomains via restrictions as far as i know.
He owns the domain, but he does not own the server and he should certainly not own my private key.
Basically he should not be able to intercept traffic just because that’s a subdomain of him.
Well… if I notice that the DynDNS provider redirects the traffic I would switch it.
He could do this, but this does not mean it should generally be allowed to get certs for all subdomains.
Additionally why do you want to go such a strange and complex approach?
You could just use wildcard certs - .currently not with LE - but other CAs support this and that’s the reason why such wildcard certs exist.
Implemented a SMIME-milter into postfix and tried to sign/encrypt emails using the Let’s Encrypt certificate.
It successfully sign the email, but other providers/email-clients don’t trust.
The certificate used to sign the message was issued by a certificate authority that you do not trust for issuing this kind of certificate.
Das Zertifikat, das zum Erstellen dieser Signatur verwendet wurde, hat nicht die richtigen Eigenschaften, um für das digitale Signieren von Nachrichten verwendet zu werden.
The certificate that was used to create this signature does not have the right properties to be used for digitally signing messages.
Damn, it would be a great step forward to use these certificates for signing emails as well.
Hm this is an interesting new point. LE does not like to sign Certificate for an mail account.
But if an server is trusted why not allow him to sign the email with his certificate for sending
automatic generated mails ?
-> Because the mail client verify against the from mail address and not against the sending server.
So even if the cert would allow mail signing it would not created an trusted mail.
This behavior is deliberate; the extended key usage (EKU) is not set to allow use with S/MIME, because Let’s Encrypt has not validated control over individual e-mail accounts.
If you’d like to use Let’s Encrypt certificates to encrypt e-mail transfer, you can use one with SMTPS, STARTTLS, or IMAPS. That will provided a kind of e-mail encryption in transit that corresponds to what the CA has tried to verify control over. Yes, this is different from S/MIME and e-mail software will represent it differently. On the bright side, it should help with getting the padlock in the new Gmail e-mail transit security indication!
S/MIME is about confidentiality of the MESSAGE.
SSL/TLS is about confidentiality of the TRANSMISSION. Where a mail hub has total view of a message. Quite something different.
When a domain name is validated, it’s mail addresses can be validated as well by sending a link. (possibly using a signed message) with a link that needs to be validated.
S/MIME is about knowing E-mail addresses. If you need to know persons a merrit type system like PGP, or https://CACert.org is required which requires proof of identity.
I really hope that Let’s encrypt will start issuing S/MIME certificates soon with StartCom being put on the blacklist by Mozilla any day now! There are not many free options left. None that I like, anyway.
S/MIME certificates would require a lifetime of 1 or 2 years however, you don’t want to deal with them even more frequently. It’s already a pain to do it once a year. And you have to keep around the old certificates to be able to decrypt old messages and check their signatures.
Comodo is also issuing free S/MIME certificates (for non commercial activities).
I too hope to see LE issue S/MIME certificates, but using S/MIME certificates with 3 months validity will be a pain…
Yep, Comodo is one of those CAs I’d rather not use with their bad security record.
https://www.cacert.org might be of more value here.
Those are certificates that identify persons, not machines. Hence they were never included in the browsers besides triggering Mozilla to rethink the certificate business.
Most probably the non-inclusion also created LE.
I fail to see how LE can issue certificates that make a statement about personal identify without setting up a shop to verify people.
CACert has this.
If you put the root certificate of CA-Cert in your trusted store, you can also verify machines if you like.
Why do you need to validate Control of individual email accounts?
You could easily do that you can create S/MIME certificates for *@domain.tld (eg you can specify any email you want) provided you can do DNS-01 validation for domain.tld
Because if you have such access to a zone file so you can validate DNS-01 for domain.tld, then you also have such access you can Point the MX anywhere you want, and thus you have implicit Control over ANY email acccount tied to domain.tld
Same with subdomain, if you can DNS-01 validate mydomain.somedyndnsprovider.org then you have implicit Control over *@mydomain.somedyndnsprovider.org
I guess many e-mail encryption users don’t want to have to trust their providers (they intend the encryption to protect confidentiality against the mail server operator too). Correspondingly, if they do all trust their providers, they can already use STARTTLS over SMTP between providers to protect the data in transit.
But the thing is, that most other S/MIME providers which provide email-only authentication, sends a email with a one-time code or a link to get the certificate.
This means that the server operator can issue S/MIME certificates for any email account on the server. Theres nothing that prevents the server operator from doing the whole validation process at for example comodo or Actalis and then intercepting the validation email and using it.
True! This is a long-standing debate between the PGP and S/MIME communities, because this phenomenon makes it much easier for end-users but gives a provider much more power to intercept or interfere with communications.
However, a minority of users might use an out-of-band verification method and there have been many proposals to improve transparency of key exchange in S/MIME, including protocols where all certified keys are required to be made public in a channel outside of the certifier’s control (and can’t be accepted otherwise). So in principle maybe S/MIME is getting stronger, or will get stronger, against providers’ using their position to tamper with communications.
(Edit: Also, depending on the UI of the e-mail client, the provider may have a limited time window in which to perform an undetected attack.)
I get where you are coming from, but that is not necessarily true.
You can also use a set of three TLS-Certificates to encrypt, sign and secure the transmission channel.
Or you can use PGP for message encryption and signing while using TLS to secure the Transmission.
S/MIME is not about securing the transmission channel, it is about identifying that an EMAIL adress (email@example.com) is who she says she is, and about confidentiality of messages (eiter in transit or in storage).
Securing the channel can be done with the right LE Server certificate, on both ends of SMTP TLS sessions.
@schoen maybe it is an idea to talk the the CACert.org people. They are in the business of peoples identity. (peer to peer verification).
S/MIME’s key exchange is done by sending a signed message (in clear) accross. So even the public key is not wide spread and only known to intended parties (as well as eavesdropping parties) this seems a clear & simple procedure to me?
No need to setup some access to a central repository anywhere.