LWN: Comments on "Wolf: Stop it with those short PGP key IDs!"

on OpenPGP signature not embedding the complete fingerprint

dd9jn — Mon, 13 Jun 2016 06:40:36 +0000

Right, the problem will eventually turn up. But we can't do anything else than to tell the user it is a "BAD signature". OTOH, most time you see a "BAD signature" this is due to bugs in MUAs, partly in MTAs, and list manager. What to tell the user in these cases?

I consider to put the mail address into the signature as another method to lookup the key. With that old PKA method this was already possible but I meanwhile consider a separate signature sub-packet a better idea because that does not mingle key discovery with key validation (which is combined in PKA).

on OpenPGP signature not embedding the complete fingerprint

dkg — Fri, 10 Jun 2016 20:27:00 +0000

dd9jn said:

I doubt that anyone has seen the problem you describe in the second paragraph in real life.

Really? I ran into that ambiguity/confusion myself when working on the UI/UX for the OpenPGP signature verification functionality for notmuch. As an implementer planning out how to deal with bad scenarios, it's quite unclear how to present this sanely to the user in a way that they can take reasonable action. Colliding long keyIDs exist, and will only become more common over time.

fwiw, i totally agree with you that the many ways S/MIME has to fetch keys are often broken. I'm not recommending that we adopt them all for OpenPGP!

on OpenPGP signature not embedding the complete fingerprint

dd9jn — Fri, 10 Jun 2016 20:03:57 +0000

I doubt that anyone has seen the problem you describe in the second paragraph in real life.

Now if we move to S/MIME, we get into worse problems, because there are many different ways to denote a required key and none of them are guaranteed to work. You more or less have to pick a method on good luck and hope that the mentioned LDAP server is up and running and actually has the certificate you need - or well all of them, and those for the CRL, ...

on OpenPGP signature not embedding the complete fingerprint

dkg — Fri, 10 Jun 2016 14:03:52 +0000

yes, the DoS is one potential problem.

Another way to look at the issue is that when writing an MUA (or other signature-verifying system), if you discover a signature that doesn't appear to verify, it's unclear how to describe this problem to the user. Do you say "this signature is broken" or "this signature may have been made by a different key" or something entirely different?

This kind of unnecessary ambiguity and confusion for implementers and users is one of the thousand papercuts that discourage people from using strong crypto. What does using the keyid instead of the full fingerprint save us? 12 octets per signature, in signatures that (these days) are hundreds of octets in length. It's a terrible tradeoff.

Wolf: Stop it with those short PGP key IDs!

robbe — Fri, 10 Jun 2016 10:09:43 +0000

Is key pinning not helpful for your usecase? It should be coming to SMTP as well, although I’m not sure how useful it would be there.

> If a domain gets used for spam then you can block trivially based
> on domain.

Only workable if there were a very high setup cost for domains (hopefully offset by much lower yearly fees). And then it sounds like „bonded email“ proposals I’ve all but forgotten about.

on OpenPGP signature not embedding the complete fingerprint

robbe — Fri, 10 Jun 2016 09:31:58 +0000

Huh? What is your attack scenario?

Ok, with a work factor of 2^64, you are able to generate a key that matches the one that was signing a given message. But what are you going to do with it?

The only thing I can imagine amounts to DoS: smuggle the fake key to the recipient, resulting in failed verfication. Sure, it’s not nice, and may induce the recipient to make human errors. But it’s not the same as a forged signature (that you get with 2^160).

Wolf: Stop it with those short PGP key IDs!

szbalint — Wed, 08 Jun 2016 11:27:43 +0000

We're also a long way away from deprecating algorithms imperiled by quantum computing. It'd take decades and pretty serious investment to prepare for a post quantum world so it shouldn't just be neglected.

on OpenPGP signature not embedding the complete fingerprint

dd9jn — Wed, 08 Jun 2016 06:22:34 +0000

Nope, the 64 bit key id is only used to *search* the public key. The verification if obviously only possible with the public key and that has the full strength of the used algorithms. The fingerprints of the keys are internally used to build up the web-of-trust and users are asked to compare them to a second source (via key signing party, visiting cards, etc.).

Wolf: Stop it with those short PGP key IDs!

dd9jn — Wed, 08 Jun 2016 06:16:45 +0000

GPGME is an API for crypto protocols like OpenPGP and CMS. There are several methods to do it. The highest level is the UI-server access, which allows to add encryption to any application with a few dozen lines of code; that requires an UI server like GPA or Kleopatra. The more commonly used level is the basic crypto API to perform encryption, signing, and key management; this is available by using gpgsm (for CMS) and gpg (for OpenPGP). A more rarely used API is a wrapper around the Assuan IPC which provides an easy to use interface to access low-level fucntion of gpg-agent, scdaemon, and dirmngr; GPA makes extensive use of this to implement its smartcard manager.

Right. gpg currently uses a spawn/use/terminate model but we have not seen any problems with that so that we would need to change it right now. gpgsm however (which has originally been designed with GPGME in mind) is run as a co-process using descriptor passing to avoid creating pipes.

The reason why gpg and gpgsm (and since 2.0 gpg-agent, scdaemon, and dirmngr) are separate processes is to fence the crypto code from other applications by the most rigid separation feature we have in an OS, the process. Thus bugs or exploits in a large GPGME using application won't directly affect the gpg code and thus your keys are better protected. For private keys this goes even further by delegating this to gpg-agent, which could even run on a different box or under a different user.

BTW, we are currently integrating C++ and Python 3 bindings into the GPGME package so that it will be easier to decide which already existing language binding to use (there are several of them, but an "upstream" maintained binding is probably a good choice).

Wolf: Stop it with those short PGP key IDs!

kjp — Wed, 08 Jun 2016 01:26:59 +0000

I've just encrypted stuff with people's ssh pub keys when I've had to send something confidential. I might make a web front end just to make that easier. I don't care about signing at all.

Wolf: Stop it with those short PGP key IDs!

gwolf — Tue, 07 Jun 2016 23:57:45 +0000

I *think* those used for the signature subpackets are long keyids. From "gpg --list-packets" on my own key, the first signature I have is:

:signature packet: algo 1, keyid 587979573442684E
version 4, created 1249167784, md5len 0, sigclass 0x13
digest algo 8, begin of digest 27 b2
hashed subpkt 2 len 4 (sig created 2009-08-01)
subpkt 16 len 8 (issuer key ID 587979573442684E)
data: [4095 bits]

Yes, it would be much better were they to carry the 160 bits... But at least they are not limited to 32!

on OpenPGP signature not embedding the complete fingerprint

gwolf — Tue, 07 Jun 2016 23:48:55 +0000

Ouch.

If nothing else does, *this fact* seems of utmost severity. Then, for all practical purposes, the signature's strength is only 64 bits. Which is not trivial, but is a far cry from 160 bits.

If this change enters the new OpenPGP standard, how long will it take for most implementations in the wild to carry it? I guess saying 3-5 years is not too conservative.

Wolf: Stop it with those short PGP key IDs!

gwolf — Tue, 07 Jun 2016 23:31:19 +0000

As for now, we are still perfectly safe by cross-signing based on the 160-bit key fingerprints. Having the full 4K of your public key is overkill. Besides, you'd have to strip the key to get just the 4K part (as it would most probably already carry signatures and other attributes).

Wolf: Stop it with those short PGP key IDs!

gwolf — Tue, 07 Jun 2016 23:29:35 +0000

Back in 2010, Daniel Kahn Gillmor insisted on having all DebConf nametags printed with the PGP fingerprint as a QR code. His reasoning was quite sound: Humans suck at crypto. For keysigning, we could perfectly well take a picture of a person's face+nametag, and run a QR recognition on that; signing the keys would have an effect of making you remind a person instead of just scratching your head (and probably signing blindly, what often happens).

Daniel's idea is sound and very good, provided every person receiving a nametag is able to check right away that QR's content. I don't know why we have abandoned the idea, but it might be worth pushing again for DebConf this year.

Wolf: Stop it with those short PGP key IDs!

raven667 — Tue, 07 Jun 2016 20:53:18 +0000

> If it becomes widespread that email servers can start rejecting non-signed emails then it can end spam as we know it. No more needing to blacklist servers or maintain long spam lists... you just validate the domain. If a domain gets used for spam then you can block trivially based on domain. No email spoofing or anything like that would be possible.

I don't think spoofing is a problem right now, spammers are _more_ likely to use SPF records for example or DV certs because they automate the provisioning of domain names with all the legitimate resources that go with them, they just don't care if the domain is usable for more than a day.

Wolf: Stop it with those short PGP key IDs!

josh — Tue, 07 Jun 2016 20:47:37 +0000

As far as I know, GPGME is a wrapper around the command-line tool, not an OpenPGP implementation itself.

Using gpg-agent via assuan seems reasonable, but as far as I can tell, libassuan implements the low-level IPC protocol, not the full details of gpg-agent requests.

Wolf: Stop it with those short PGP key IDs!

dd9jn — Tue, 07 Jun 2016 20:08:06 +0000

What's wrong with GPGME? There are all standard features available you need for MUAs. And you can also directly talk to gpg-agent or dirmngr via its high-level Assuan API.

Wolf: Stop it with those short PGP key IDs!

josh — Tue, 07 Jun 2016 19:47:59 +0000

Shelling out to a command-line program is a lot more error-prone, involves a lot more text parsing and text construction, requires passing parameters as command-line arguments, requires care to avoid exposing sensitive information to the rest of the system, requires managing the lifetime and possible errors of a separate program, adds overhead, and otherwise adds quite a bit of complexity compared to a library.

Note that I'm not necessarily arguing for *just* a standalone libopenpgp that handles key material, though I'd also like that library; a library that talks to gpg-agent to handle key material would be nice. That's possible to build on top of libassuan, but something higher-level would be nice.

Wolf: Stop it with those short PGP key IDs!

lsl — Tue, 07 Jun 2016 18:59:12 +0000

On Fedora, you can fix that with "dnf install unbound; systemctl enable unbound.service" and pointing your resolv.conf at localhost.

If you need the ability to subvert DNSSEC validation at a click of the mouse (people seem to require this "feature"), there's even a GUI tool for that.

See:
https://fedoraproject.org/wiki/Changes/Default_Local_DNS_...

Other distributions (and FreeBSD) have similarly convenient ways to set this up.

Wolf: Stop it with those short PGP key IDs!

lsl — Tue, 07 Jun 2016 18:40:43 +0000

> I'm hoping that GPG starts providing a usable OpenPGP library at some point, because no program should need to fork/exec the gpg command-line tool to use GPG.)

Why is that? Calling out to gpg(1) doesn't seem that bad, especially considering the things it does to make it nice to run programmatically (like giving you control over the file descriptors it uses for different kinds of output).

Wolf: Stop it with those short PGP key IDs!

paulj — Tue, 07 Jun 2016 08:08:51 +0000

Caching, local, recursive, DNSSec capable nameservers exist. Distros even provide packages to make it a 'dnf install'. Local recursive nameservers were a good idea even before DNSSec (less vulnerable to DNS poisoning).

Wolf: Stop it with those short PGP key IDs!

flussence — Tue, 07 Jun 2016 00:50:43 +0000

>Mozilla is hardly the primary CA gatekeeper; other browsers maintain their own CA list. And the major burden there tends to be the expensive audit required.
That's correct, but Mozilla owns the whitelist that everything else on an average Linux system uses. Moreover, that list excludes CACert, which is the only traditional CA I'm aware of that provides assurances beyond the bare minimum required to comply with the letter of such an audit.

>But DNS-based certificates just move the problem around; why do you trust the DNS system and domain registrars, but not CAs?
I can make myself part of the DNSSEC chain of trust just by giving the registrar the public half of my zone-signing key, pointing them at my server, and waiting for the changes to propagate. That means I have to trust, at most, four things: the DNS root, the TLD servers, the registrar's security, and my own system security. Note that using CAs doesn't make any of these go away.

I've seen enough people get burned by things like StartSSL post-heartbleed and the CNNIC "oil spill" of forged certs that I don't have much faith left in the bookkeepers and their policies. I'd rather not stick my head in the sand and pretend the other 200 points of failure in that list will never fail when there's a better option.

>To some extent, CAs cross-check that you're not getting bad data from DNS and the registrars.
DNSSEC doesn't preclude the use of an external CA. It allows key-pinning at the DNS level, similar to the HTTP pinning currently in browsers.

>Among other things, the main DNS hierarchy has this strange notion that domain names should "expire", and they'll happily sell the name to someone else when it does, at which point they'll also certify the new owner.
DNSSEC wouldn't make serving domain squatter pages over HTTPS any easier than ACME does, so it's not a point either way.

Wolf: Stop it with those short PGP key IDs!

AnthonyJBentley — Tue, 07 Jun 2016 00:10:50 +0000

The author of signify, Ted Unangst, also wrote a tool called reop.

The interface is so much simpler than GPG. Just a few commands:

usage:  reop -G [-n] [-i ident] [-p pubkey -s seckey]
        reop -D [-i ident] [-p pubkey -s seckey] -m message [-x encfile]
        reop -E [-1b] [-i ident] [-p pubkey -s seckey] -m message [-x encfile]
        reop -S [-e] [-x sigfile] -s seckey -m message
        reop -V [-eq] [-x sigfile] -p pubkey -m message

(Generate, decrypt/encrypt, sign/verify)

And comes with a simple but entirely complete manpage:

$ man reop | wc -l
     102
$ man gpg | wc -l
    3233

I know a handful of people with reop keys, mostly OpenBSD folks. But despite having been to multiple Linux User Groups and cryptoparties, I’ve never received a single OpenPGP‐encrypted mail… so it’s not like reop’s low adoption actually affects me in a meaningful way.

Alas, reop’s development has stalled. But even if reop is not the end solution, I firmly believe OpenPGP implementations could stand to learn from the simplicity of its interface.

Wolf: Stop it with those short PGP key IDs!

anselm — Mon, 06 Jun 2016 22:56:09 +0000

I'd like to see DV certs die (which probably eliminates most commercial CAs), but I continue to see a need for EV certs.

You probably mean OV (organization-validated) certs, which are the ones where the CA is supposed to satisfy itself that the organization that applies for the certificate exists.

EV certificates are basically OV certificates that look nicer in the browser because the CA in question has a special deal with the browser makers. (Unlike standard DV and OV certificates, you can't make EV certificates yourself with, say, OpenSSL, because EV certificates have special per-CA extensions which are hard-coded into browsers and are checked based on who signed the certificate. You could of course patch Firefox or Chromium but then you would have to get all your users to use that browser and no other.) EV certificates don't usually differ a lot from OV certificates as far as the work that the CA does to verify the organization behind the certificate is concerned, but are vastly more expensive just so you can get that green bar in your browser's URL field. Essentially, EV certificates were the CAs' way of saving their bottom line in the face of constantly-dropping prices for OV certificates. The “race to the bottom” has now started for EV certificates, too, and we can only wait for the CAs to come up with, say, “extra-validated” (XV) certificates which will be marketed as “even more secure than EV certificates” and of course be five times as expensive.

Since HTTPS these days is mostly security theatre in the first place, there is little point in wasting money on expensive certificates. From a practical POV, there is no compelling reason to pay for an OV certificate over a (free) DV certificate – users won't be able to tell the difference –, and pretty much the only reason to get an EV certificate is if you're operating in a market where all your competitors have one, and you don't want to appear to be lax on “security” (think “bank”).

Wolf: Stop it with those short PGP key IDs!

drag — Mon, 06 Jun 2016 20:06:41 +0000

oh and this also sets a way to revoke CAs for a domain.

If you lose control of your private keys then you can work with the TLD to update the DNSSEC records to trust a different CA then all clients should, in short order, start rejecting certs made by the old CA.

Wolf: Stop it with those short PGP key IDs!

drag — Mon, 06 Jun 2016 19:58:41 +0000

> But DNS-based certificates just move the problem around; why do you trust the DNS system and domain registrars, but not CAs? To some extent, CAs cross-check that you're not getting bad data from DNS and the registrars.

Because there is no real way to validate that the CA is supposed to be providing certificates for a particular domain.

If I sign a cert for a domain from 'Good Guy. Inc'... there is no technical measures in place to prevent somebody using any other CA to sign their own certs for my domain. As long as governance for CAs are rock solid then this isn't a problem. Unfortunately the security for any cert is only as good as the weakest CA the clients trust. If your client software is configured to trust 300 different CAs then the security for all those CAs must be good for any of the their certs to be really trustworthy.

With DNSSEC I only have to trust the domain operator and TLD it depends on to get it right, if they choose to manage their own CA. That cuts a huge number of people (aka, potential issues) out of the equation. It can make self-signed CAs a sane solution use as well.

Sure, but as long as you control domain you should be able to control what CAs clients trust without having to have those clients pre-configured to do so.

This means that all sorts of tasks that require signing and encryption that can depend on asymmetrical encryption schemes can be automatically configured via DNS records explicitly setting the CA information. Signing messages, signing packages, encrypting websites, vpns, client auth, instant messaging, VoIP, etc etc. All this can be done automatically and securely.

(Possibly. I know there are problems.)

Wolf: Stop it with those short PGP key IDs!

Cyberax — Mon, 06 Jun 2016 19:53:51 +0000

> Personally I think that the best solution for this sort of thing is to have the OS provide more sophisticated name resolution validation as a service to applications, like running a local DNS resolver or whatever. Until that happens then having the option to use better libraries is probably a good thing, of course.
Just switch to systemd ;)

https://www.freedesktop.org/software/systemd/man/resolved... - look for DNSSEC. They're switching it to allow-downgrade in the next release.

Wolf: Stop it with those short PGP key IDs!

dsommers — Mon, 06 Jun 2016 19:45:37 +0000

Really?

https://www.youtube.com/watch?v=DZ2DcILZAbM
http://www.research.ibm.com/quantum/
https://www.technologyreview.com/s/537041/ibm-shows-off-a...
http://www.computerworld.com/article/2501748/emerging-tec...

Wolf: Stop it with those short PGP key IDs!

drag — Mon, 06 Jun 2016 19:19:02 +0000

Yea.. I didn't expect this to be a easy solution. Just a plausible one. :)

> Do you trust your ISP's DNS servers enough?

This is one of those 'trust but verify' situations. If you have a DNS server sending out phony DNSSEC information then it's going to be pretty trivial to discover, provided somebody takes the time to write a utility to do it. If have a nice script to validate a questionable DNS server with a known good DNS server.. then how many domains could you validate in a half a hour or so?

If the ISP is jacking with DNS then it isn't going to be something that is difficult to find out.

Personally I think that the best solution for this sort of thing is to have the OS provide more sophisticated name resolution validation as a service to applications, like running a local DNS resolver or whatever. Until that happens then having the option to use better libraries is probably a good thing, of course.

Wolf: Stop it with those short PGP key IDs!

farnz — Mon, 06 Jun 2016 18:49:02 +0000

Two reasons that I think DNSSEC is a net improvement over DV certs:

My browser's CA list has all sorts of entities in it, any of whom can certify any domain. For example, there's TW and US government certificates in the CA list I'm looking at right now.
For DV certificates, the CAs don't provide any value; all they do is confirm that at one point in time (details vary between CAs), the domain was controlled by the certificate receiver.

DNSSEC is better than DV certs because the effort required to issue a false DNSSEC cert is higher than that required to issue a false DV cert. You not only need to ensure that you have control of the DNS chain from me to the root, you have to ensure that my cached root key is expired or under your control; for a false DV cert, you merely need to control the DNS chain from the CA to the root at some point in the recent past, so that the CA is conned into issuing a DV certificate.

And the expiry argument applies to DV CA certificates, too - if lwn.net expires, and I pick it up, I can trivially get a DV cert for lwn.net (maybe from Let's Encrypt!). At least with DANE + DNSSEC, I have to maintain control of the domain to con you - I can't just pick it up, get the DV cert, and return it to its rightful owner as a "oops - you let this expire, but I picked it up for you!" generous act.

Having said that, EV certs are better than DNSSEC because the CA ties more than just the domain name to the entity controlling the domain - it also ties a physical world entity to them. I'd like to see DV certs die (which probably eliminates most commercial CAs), but I continue to see a need for EV certs.

Wolf: Stop it with those short PGP key IDs!

wahern — Mon, 06 Jun 2016 18:27:46 +0000

The problem with DNSSEC is that most applications only have access to a stub resolver, which means most applications must implicitly trust their local recursive resolver. Do you trust your ISP's DNS servers enough? Or rather, do you trust others' ISPs enough to roll-out an end-to-end security capability that depended on DNSSEC? However poorly CAs are managed these days, they're probably better managed than DNS servers.

Until recursive-capable resolver libraries becomes more widespread, I don't think we can expect DNSSEC to be used that way. AFAIU, part of the reason Mozilla and Chrome soured on DANE (DNSSEC+TLS) and DANE-like solutions was because they'd have to support recursive resolution in-browser.

FWIW, I have a non-blocking I/O DNS resolver that does recursive resolution: https://github.com/wahern/dns and http://25thandclement.com/~william/projects/dns.c.html. Adding DNSSEC is on my TODO list. It's a single-file .c library[1] which is quite long, partly because of the various record-specific code. But recursive resolution is nonetheless much more involved than stub resolution. Not in an absolute sense, but a stub resolver can be so incredibly simple that recursive resolution is much more complex by comparison.

[1] Single-file makes it easy to embed into projects, without saddling the project with build-time or run-time dependencies.

Wolf: Stop it with those short PGP key IDs!

josh — Mon, 06 Jun 2016 18:23:25 +0000

Mozilla is hardly the primary CA gatekeeper; other browsers maintain their own CA list. And the major burden there tends to be the expensive audit required. Personally, I'm hoping that Let's Encrypt puts almost every "commercial" CA out of business.

But DNS-based certificates just move the problem around; why do you trust the DNS system and domain registrars, but not CAs? To some extent, CAs cross-check that you're not getting bad data from DNS and the registrars.

Among other things, the main DNS hierarchy has this strange notion that domain names should "expire", and they'll happily sell the name to someone else when it does, at which point they'll also certify the new owner.

Wolf: Stop it with those short PGP key IDs!

flussence — Mon, 06 Jun 2016 18:07:17 +0000

Postfix already has some TLSA support: http://www.postfix.org/TLS_README.html#server_cert_key

I imagine it'll become pretty widely supported in other TLS clients, outside of the elephant in the room (which is no surprise, because this technology threatens Mozilla's position as CA gatekeeper).

signify public keys are not shorter than OpenPGP v4 fingerprints.

flussence — Mon, 06 Jun 2016 17:52:15 +0000

Bah, forget I said that. I must've been reading wrong and counted two consecutive fingerprints as one. signify keys are 6 characters longer than GPG FPs using the canonical output format of both, not quite as impressive.

Of course, that doesn't change the fact that it's only a fingerprint...

on OpenPGP signature not embedding the complete fingerprint

dd9jn — Mon, 06 Jun 2016 17:47:32 +0000

Right. Back when PRZ wrote the first PGP he tried to make messages as short as possible and probably did not assume the size of todays Internet. It should have been fixed with OpenPGP in 1998 but by then PGP 5 and PGP 6 were already out of the door and thus we are stuck with some legacy.

I wish we could make faster progress in rfc4880bis so that a signer-fingerprint could be added to software now as an option.

Wolf: Stop it with those short PGP key IDs!

dd9jn — Mon, 06 Jun 2016 17:39:51 +0000

That depends on whether you want a centralized systems or a peer system which is more like the original internet without the need for any central service. Recall that OpenPGP works fine even without (or with a cut) network.

Wolf: Stop it with those short PGP key IDs!

drag — Mon, 06 Jun 2016 15:34:54 +0000

https://wiki.mozilla.org/Security/DNSSEC-TLS-details

I don't see why this scheme can't be extended to support SMTP or any other TLS-enabled service.

Wolf: Stop it with those short PGP key IDs!

brian_lindholm — Mon, 06 Jun 2016 15:00:40 +0000

32 bits isn't enough to avoid collisions. Per the classic "birthday paradox" (https://en.wikipedia.org/wiki/Birthday_problem), you only need a body of 154325 short IDs to have a 50% probability of a collision.

Wolf: Stop it with those short PGP key IDs!

ms — Mon, 06 Jun 2016 14:43:12 +0000

> BTW, is there any way to configure gnupg to always include the full key fingerprint?

Yes. https://help.riseup.net/en/security/message-security/open...

"You should probably at least set keyid-format 0xlong and with-fingerprint gpg options (put them in ~/.gnupg/gpg.conf) to increase the Key ID display size to 64-bit under regular use, and to always display the fingerprint"

Wolf: Stop it with those short PGP key IDs!

drag — Mon, 06 Jun 2016 14:06:46 +0000

When I use TLS to 'secure' my servers for my own use I always make sure to specify the trusted CA when possible. Then it doesn't matter that any root CA gets compromised. I only trust the one I can control.

Of course this is useless for public-facing services... or is it?

If you have DNSSEC and it can be trusted then why not specify a CA through DNS TXT? That way you don't need all these expensive 'trusted roots'. You can make your own and it can be publicly discoverable via DNS records.

Since emails are naturally tied to domain name then automating the creation of private keys and signed client certs should be possible.

If it becomes widespread that email servers can start rejecting non-signed emails then it can end spam as we know it. No more needing to blacklist servers or maintain long spam lists... you just validate the domain. If a domain gets used for spam then you can block trivially based on domain. No email spoofing or anything like that would be possible.