1

Extended validation certificates are identity certificates issued to a legal entity. This means that anything signed by that certificate is "guaranteed" to come from the entity instead of just from the domain name.

Since phishing emails are a big deal and (at least in my mind) appear to be growing in prevalence, why don't companies sign emails using these certificates (and include the signature as an attachment)?

The trust infrastructure is already (mostly) in place and the verification could be handled fairly transparently by email clients using the OS or browser certificate store.

I imagine that this could render many of the "ENTER YOU BANKING CREDENTIALS IN 24 HOURS OR ACCOUNT WILL BE DELETE" emails and other, better crafted phishing emails, largely useless to the phishers.

|improve this question
  • 2
    Very few people use PGP, which is free and easily configured without any kind of validation process. What makes you think people would go to the extent of paying for an EV certificate and going through all of the validation processes? Also, how would you integrate such PKI validation into worldwide SMTP/POP/IMAP infrastructure? How would email clients know to validate the certificate and EV metadata? Which organisation should standardise this whole process? – Polynomial Sep 21 '17 at 15:12
  • @polynomial PGP requires a network of trust to be built and largely for this reason cannot be transparent. This network already exists with EV certs, email sig verification can be as transparent as https. The companies that would want this, e.g. banks, already have The EV certs. The validation would happen at the application level and so none of the underlying protocols matter (attachments are already standardised). The standardization of validation could be done by RFC. – Liam Sep 21 '17 at 15:24
  • 2
    @Liam Are you going to do the work to standardise this? – Polynomial Sep 21 '17 at 15:26
  • @polynomial No. Is that relevant? If the answer you're getting at is "it's a lot of work and the advantages simply aren't worth it (Because for example it might not help with spear phishing)", then please post that as an answer. Also I probably should have mentioned in my first comment that I am the op. – Liam Sep 21 '17 at 15:32
  • @Polynomial: you don't need to integrate into the transport; e-mail encryption can be and should be end-to-end and transparent to transport; both PGP and S/MIME are. And both are standardized by IETF since last century (although only S/MIME started there) and the requirements for MUAs are known and have been implemented successfully. – dave_thompson_085 Sep 22 '17 at 6:22
1

According to the EV (SSL) Guidelines as of 1.6.5 (July 2017) from cabforum (warning: like others they've now 'optimized' their website to display as little data as possible, so to find anything useful you have to grovel through the pulldown) in clause 1:

This version of the Guidelines addresses only requirements for EV Certificates intended to be used for SSL/TLS authentication on the Internet and for code signing. Similar requirements for S/MIME, time-stamping, VoIP, IM, Web services, etc. may be covered in future versions

Although FWIW the EV guidelines do not say anything about ExtendedKeyUsage, and in the baseline requirements (incorporated by reference) 7.1.2.3f says it MUST contain clientAuth and/or serverAuth and MAY contain emailProtection. So I think a member CA could issue an EV cert includig email without violating the rules. OTOH I doubt any email software currently checks for EV even when it supports X.509 (S/MIME) since this is not expected.

Of course there's the usual chicken-egg problem; legitimate email senders won't want to use this until at least a significant fraction of recipients are using email software or systems that support it, and at least most recipients won't even look for such support as long as no one is sending it. Possibly if some big players like gmail push this it might get some traction, in much the same way some browsers have been pushing improvements in web/HTTPS cryptography.

|improve this answer
0

There are already verification methods today that can establish a secure connection between a email and its sending domain name. Three of them is SPF and DKIM, but also S/MIME.

Since the web site and/or a mail server, residing on the same domain, can be EV certified, it means that once you make that connection, you can be sure that the organization did do the request.

The only thing lacking is that the mail client needs to show the result of the SPF/DKIM validation, and its associated domain name, in some promient way to the user.

Implementing EV for emails would only add complexitiy, and also added costs for companies.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy