To begin with you'd need some reason to actually trust that these certificates provide any value. Without that there's no reason for ISRG (the people behind Let's Encrypt) to spend five minutes on it.
Within an organisation in principle S/MIME can provide that value, on the wider Internet there's never been a serious attempt to do so. What exists already is left as it is, basically to rot.
Things you'd want (off the top of my head, there are probably more)
- One or more agreed mechanisms to ensure the legitimate owner of name@example.com can get a cert for name@example.com but no-one else can. If the owners of example.com can, you need a rationale for why that's OK, which will be a struggle - consider whether you think tialaramex@gmail.com is me, or might also be just anybody who works for Google...
- Oversight to ensure that the rules get followed. This is truly difficult to achieve, I think we got there for the Web PKI, but it's a journey not a destination and every year is a further struggle. Interest in doing this for S/MIME tends to fizzle after just a few weeks each time.
- Client interop good enough that any normal user can expect to send S/MIME signed and encrypted mail to any other normal user and have it be delivered
- Clients that can go get a user their certificate for myname@example.com using a key they created, not some centrally administrated key which renders this whole process useless outside of a centralised trust environment.
- Widespread clients that provide a reliable UX in respect of these features to ordinary end users.
>One or more agreed mechanisms to ensure the legitimate owner of name@example.com can get a cert for name@example.com but no-one else can. If the owners of example.com can, you need a rationale for why that's OK, which will be a struggle - consider whether you think tialaramex@gmail.com is me, or might also be just anybody who works for Google...
Existing S/MIME CAs already do this by sending a challenge to the user by email. Of course, this doesn't prevent e.g. Google changing MX records or just intercepting email, but that's an issue for much more than just S/MIME. I suspect I could get an DV web certificate issued if you let me intercept email.
>Oversight to ensure that the rules get followed. This is truly difficult to achieve, I think we got there for the Web PKI, but it's a journey not a destination and every year is a further struggle. Interest in doing this for S/MIME tends to fizzle after just a few weeks each time.
Can you expand on this? From what I've seen of mozilla.dev.security.policy and Bugzilla, the process CAs have to go through to get the email trust bits set is similar in structure to Web PKI requests. It's all discussed in the Root Store Policy: https://www.mozilla.org/en-US/about/governance/policies/secu...
From what I've seen, the certs get CT logged too.
>Client interop good enough that any normal user can expect to send S/MIME signed and encrypted mail to any other normal user and have it be delivered
>Widespread clients that provide a reliable UX in respect of these features to ordinary end users.
Part of the reason why the UX is poor is arguably the process of requesting a certificate and the limited offering from CAs. I think adoption UX are linked.
>Clients that can go get a user their certificate for myname@example.com using a key they created, not some centrally administrated key which renders this whole process useless outside of a centralised trust environment.
Not sure I follow this. When I got my cert from Sectigo, the key was generated on my machine, by the browser using the <keygen> element. Can you explain what you mean by "centrally administrated key", and which CAs are doing this?
Within the US Department of Defense (who may be the most widely-deployed users of S/MIME), email encryption keys (which all DoD personnel carry on a smartcard) are escrowed with DISA.
Within an organisation in principle S/MIME can provide that value, on the wider Internet there's never been a serious attempt to do so. What exists already is left as it is, basically to rot.
Things you'd want (off the top of my head, there are probably more)
- One or more agreed mechanisms to ensure the legitimate owner of name@example.com can get a cert for name@example.com but no-one else can. If the owners of example.com can, you need a rationale for why that's OK, which will be a struggle - consider whether you think tialaramex@gmail.com is me, or might also be just anybody who works for Google...
- Oversight to ensure that the rules get followed. This is truly difficult to achieve, I think we got there for the Web PKI, but it's a journey not a destination and every year is a further struggle. Interest in doing this for S/MIME tends to fizzle after just a few weeks each time.
- Client interop good enough that any normal user can expect to send S/MIME signed and encrypted mail to any other normal user and have it be delivered
- Clients that can go get a user their certificate for myname@example.com using a key they created, not some centrally administrated key which renders this whole process useless outside of a centralised trust environment.
- Widespread clients that provide a reliable UX in respect of these features to ordinary end users.
Don't hold your breath.