It appears that certain MUA clients (e.g. Samsung S8) are starting to get picky about certificates that have X509v3 extensions that don’t include email and general encipherment.
So letsencrypt sets these fields:
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Basic Constraints: critical
CA:FALSE
Whereas for email + web serving (or just encrypted “media”) we probably need something like this:
X509v3 extensions:
Netscape Cert Type:
SSL Client, SSL Server, S/MIME
X509v3 Key Usage:
Digital Signature, Key Encipherment, Data Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication, E-mail Protection
Could this be added to future proof the strictness that is finally creeping into email TLS conversations?
It seems a trivial change, that increases overall utility.
It’s unclear to me why MUA would require the emailProtection EKU for TLS server certificates. Is there some kind of documentation that mentions this requirement?
S/MIME doesn’t happen on the TLS layer and uses different certificates, issued for individual email addresses. Let’s Encrypt doesn’t issue S/MIME certificates, so if you’d try to use one that way, that would indeed not work. I’m not aware of any plans for S/MIME certificates on Let’s Encrypt’s end.
The specific use cases are MTA <-> MTA SSL communications and MTA <-> imap server actions. As for documentation, all I can suggest is the openssl docs. The config shown produced a working certificate that covers web and email transactions. The S/MIME thing just falls out with that config.
I still don’t understand how this relates to S/MIME.
When you use S/MIME, you obtain a certificate from a trusted CA which includes your email address (verified by the CA), and then configure your mail client to use this certificate (and its key), for example to sign messages. When you send an email signed with your key, all the magic happens in the email header and body. From the SMTP server’s perspective, it’s just yet another message, and when you talk to your SMTP server via TLS, the SMTP server uses its server certificate and your S/MIME certificate isn’t involved at all. Similarly, when you retrieve an email from your IMAP server, and that email happens to be an S/MIME message, that doesn’t affect the TLS certificate used by your IMAP server, it’s just a property of the message. A certificate that would cover both does not make a whole lot of sense in this context.
Even if Samsung has arbitrarily decided to insist on wacky nonsense, that doesn’t make wacky nonsense a good idea, it makes Samsung an outlier and it hurts the Web PKI for everybody else.
… is hopelessly obsolete. Nothing should still be relying on this obsolete crap in 2017. Certainly not a brand new phone.
Requiring the Key Usage: Data Encipherment is not obsolete but very, very weird. In theory what it means is that you propose to use the keys to directly do public key crypto, which is very slow and cumbersome, instead of using it only to do key agreement and then use much faster and better symmetric crypto to actually send messages. Nobody does this. It’s in the standard in case anybody ever needs it, but requiring it will usually mean somebody has no clue what they’re doing and thought “Yeah, encipherment, that sounds like something I need”.
If you can work out what the S8 actually requires exactly, that might be worth re-reporting here, but most likely the main target needs to be Samsung who’ve apparently included random requirements that make no sense.