S/MIME Version 4.0 Message Specification(tools.ietf.org)
tools.ietf.org
S/MIME Version 4.0 Message Specification
https://tools.ietf.org/html/rfc8551
34 comments
This section describes the changes made between S/MIME v3.2 and
S/MIME v4.0.
Formatting note: using code blocks for list works horribly on mobile.
The original document is preformatted monospace text, so a preformatted block is the only way to display it without a lot of effort to rejoin the lines and separate them into paragraph breaks (so that HN won't combine them inappropriately).
No need to rejoin the lines, as HN will combine them as you say. Only need to add a new line before each bullet point.
>a lot of effort
Just ':%s/\n\s//g' in vim... substitute (newline + non-ws char) with nothing.
Just ':%s/\n\s//g' in vim... substitute (newline + non-ws char) with nothing.
Fair enough, but if I simply copy and paste the above without indents it doesn't look so bad:
- Added the use of AuthEnvelopedData, including defining and registering an smime-type value (Sections 2.4.4 and 3.4).
- Updated the content-encryption algorithms (Sections 2.7 and 2.7.1.2): added AES-256 Galois/Counter Mode (GCM), added ChaCha20-Poly1305, removed mention of AES-192 Cipher Block Chaining (CBC), and marked tripleDES as historic.
- Updated the set of signature algorithms (Section 2.2): added the Edwards-curve Digital Signature Algorithm (EdDSA), added the Elliptic Curve Digital Signature Algorithm (ECDSA), and marked DSA as historic.
- Updated the set of digest algorithms (Section 2.1): added SHA-512, and marked SHA-1 as historic.
- Updated the size of keys to be used for RSA encryption and RSA signing (Section 4).
- Created Appendix B, which discusses considerations for dealing with historic email messages.
- Added the use of AuthEnvelopedData, including defining and registering an smime-type value (Sections 2.4.4 and 3.4).
- Updated the content-encryption algorithms (Sections 2.7 and 2.7.1.2): added AES-256 Galois/Counter Mode (GCM), added ChaCha20-Poly1305, removed mention of AES-192 Cipher Block Chaining (CBC), and marked tripleDES as historic.
- Updated the set of signature algorithms (Section 2.2): added the Edwards-curve Digital Signature Algorithm (EdDSA), added the Elliptic Curve Digital Signature Algorithm (ECDSA), and marked DSA as historic.
- Updated the set of digest algorithms (Section 2.1): added SHA-512, and marked SHA-1 as historic.
- Updated the size of keys to be used for RSA encryption and RSA signing (Section 4).
- Created Appendix B, which discusses considerations for dealing with historic email messages.
Yes this is actually readable.
This is what we get for tolerating hard wraps. Same issue with git commit messages.
and desktop!
[deleted]
[deleted]
Nice to see AES GCM & ChaCha20-Poly1305 in there. Seems to generally be moving in a good direction.
Now we just need a CA that will offer free S/MIME capable certificates in a space that is rapidly shrinking (Sectigo have recently removed their offering... I think Actalis is now the only CA in this area that's trusted.
Let's Encrypt, will you step up to the mark?
Now we just need a CA that will offer free S/MIME capable certificates in a space that is rapidly shrinking (Sectigo have recently removed their offering... I think Actalis is now the only CA in this area that's trusted.
Let's Encrypt, will you step up to the mark?
Head of Let's Encrypt here.
So far as we can tell, there is no viable plan for mass adoption of S/MIME. It will remain a niche system whether or not we participate. There is no opportunity for impact that would justify the effort and expense on our part, no vision for the future of S/MIME that we're excited about.
There was a viable plan for mass adoption of HTTPS in a reasonable time frame, that's why we chose to execute.
A fundamental difference between those two ecosystems is that the burden of HTTPS is almost entirely on server administrators, end users don't have to do anything. The HTTPS user-agent ecosystem has been solidly in place for a while. In the S/MIME case individuals need to be more participatory, and it's hard to get end-users to do anything, let alone correctly.
So far as we can tell, there is no viable plan for mass adoption of S/MIME. It will remain a niche system whether or not we participate. There is no opportunity for impact that would justify the effort and expense on our part, no vision for the future of S/MIME that we're excited about.
There was a viable plan for mass adoption of HTTPS in a reasonable time frame, that's why we chose to execute.
A fundamental difference between those two ecosystems is that the burden of HTTPS is almost entirely on server administrators, end users don't have to do anything. The HTTPS user-agent ecosystem has been solidly in place for a while. In the S/MIME case individuals need to be more participatory, and it's hard to get end-users to do anything, let alone correctly.
People aren't making S/MIME software better because too few are using S/MIME. Too few are using S/MIME because it requires certificates to get started.
Making it easy to get email certificates certainly doesn't guarantee mass adoption, but the lack of easy access to email certificates absolutely is blocking mass adoption.
Making it easy to get email certificates certainly doesn't guarantee mass adoption, but the lack of easy access to email certificates absolutely is blocking mass adoption.
This hits the nail on the head exactly. It's a vicious cycle.
Let's Encrypt are perhaps one of the only players in a good position to make a real difference here. I don't see any other CAs implementing ACME for S/MIME (https://tools.ietf.org/html/draft-ietf-acme-email-smime-04) and offering free certs.
Let's Encrypt are perhaps one of the only players in a good position to make a real difference here. I don't see any other CAs implementing ACME for S/MIME (https://tools.ietf.org/html/draft-ietf-acme-email-smime-04) and offering free certs.
Hey Josh, thanks for your response.
>In the S/MIME case individuals need to be more participatory, and it's hard to get end-users to do anything, let alone correctly.
Do you not think there's a case to be made here for MUAs to implement e.g. ACME and make this seamless? Why shouldn't I be able to automatically get a certificate provisioned for my email account and then just opt-in to signatures/encryption as needed? If a player like Google decided to roll this out to consumer GMail (recall it's already available for enterprise customers) they could massively increase adoption.
>It will remain a niche system whether or not we participate.
Why do you think there's no chance of innovation if an automated certificate provisioning solution becomes available?
>There is no opportunity for impact that would justify the effort and expense on our part, no vision for the future of S/MIME that we're excited about.
This really is a shame and I fear it will pretty much cement S/MIME's fate going forward. As much as PGP has some strengths and I've used it for many years, it's poorly supported without external software and I'm not sure it's a good answer for the average user.
Out of interest: is there any vision for email integrity and confidentiality that you are excited about, if not S/MIME, or is LE really just about web PKI?
>In the S/MIME case individuals need to be more participatory, and it's hard to get end-users to do anything, let alone correctly.
Do you not think there's a case to be made here for MUAs to implement e.g. ACME and make this seamless? Why shouldn't I be able to automatically get a certificate provisioned for my email account and then just opt-in to signatures/encryption as needed? If a player like Google decided to roll this out to consumer GMail (recall it's already available for enterprise customers) they could massively increase adoption.
>It will remain a niche system whether or not we participate.
Why do you think there's no chance of innovation if an automated certificate provisioning solution becomes available?
>There is no opportunity for impact that would justify the effort and expense on our part, no vision for the future of S/MIME that we're excited about.
This really is a shame and I fear it will pretty much cement S/MIME's fate going forward. As much as PGP has some strengths and I've used it for many years, it's poorly supported without external software and I'm not sure it's a good answer for the average user.
Out of interest: is there any vision for email integrity and confidentiality that you are excited about, if not S/MIME, or is LE really just about web PKI?
> Do you not think there's a case to be made here for MUAs to implement e.g. ACME and make this seamless?
Something like ACME for email certificates would be helpful, but I don't think that's anywhere near the major blocker for practical email encryption.
In addition to the difficulty of acquiring certificates, email is quite likely to be read from different devices (including webmail!). This makes key management more challenging compared to server SSL keys, especially because you also have a much, much longer tail of email applications trying to read email. Key discovery is a difficult topic, depending on how much you trust MTAs and how much you're willing to give up on decentralized email. Widespread email encryption would also probably destroy anti-spam solutions.
Of course, the most difficult problem of all is that the threat model for email is rather different than for SSL. The automatic provisioning of DV certificates effectively relies on the difficulty of spoofing and intercepting a connection on the wider internet and is less effective against nation-state-level threats (if the US government wanted to get a certificate for any domain, it probably could). But email is already naturally secured against those common threats, as your connection to the email servers are protected by SSL. Instead, the goal of email certificates is to protect against others who (might) have access to your email account... which means that automatic provisioning of certificates doesn't cut it.
Something like ACME for email certificates would be helpful, but I don't think that's anywhere near the major blocker for practical email encryption.
In addition to the difficulty of acquiring certificates, email is quite likely to be read from different devices (including webmail!). This makes key management more challenging compared to server SSL keys, especially because you also have a much, much longer tail of email applications trying to read email. Key discovery is a difficult topic, depending on how much you trust MTAs and how much you're willing to give up on decentralized email. Widespread email encryption would also probably destroy anti-spam solutions.
Of course, the most difficult problem of all is that the threat model for email is rather different than for SSL. The automatic provisioning of DV certificates effectively relies on the difficulty of spoofing and intercepting a connection on the wider internet and is less effective against nation-state-level threats (if the US government wanted to get a certificate for any domain, it probably could). But email is already naturally secured against those common threats, as your connection to the email servers are protected by SSL. Instead, the goal of email certificates is to protect against others who (might) have access to your email account... which means that automatic provisioning of certificates doesn't cut it.
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 [email protected] can get a cert for [email protected] 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 [email protected] 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 [email protected] 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.
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 [email protected] can get a cert for [email protected] 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 [email protected] 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 [email protected] 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.
>One or more agreed mechanisms to ensure the legitimate owner of [email protected] can get a cert for [email protected] 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 [email protected] 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 [email protected] 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?
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 [email protected] 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.
I wonder if Estonian ID card can be used for S/MIME? Anyone knows?
EDIT: Yep, Estonia gives every citizen an ID card that can in theory do S/MIME as well, though I haven't just seen any good implementations of that: https://eid.eesti.ee/index.php/EID_funktsioonide_l%C3%BChitu...
EDIT: Yep, Estonia gives every citizen an ID card that can in theory do S/MIME as well, though I haven't just seen any good implementations of that: https://eid.eesti.ee/index.php/EID_funktsioonide_l%C3%BChitu...
You don't need anything to specifically support them since AFAIK they provide a pluggable PCKS11 module.
Let’s Encrypt has said multiple times that they will not offer S/MIME certificates.
Is there a specific reason they have given for not supporting it? I’m a PGP fan myself but S/MIME is still useful.
I’ve found https://community.letsencrypt.org/t/s-mime-certificates/153 which seems to imply that it’s because they can’t validate emails securely enough in— although the comment wasn’t from LE staff. Maybe because email certs should last longer than a few months so it wouldn’t be as useful? I’m curious now!
I’ve found https://community.letsencrypt.org/t/s-mime-certificates/153 which seems to imply that it’s because they can’t validate emails securely enough in— although the comment wasn’t from LE staff. Maybe because email certs should last longer than a few months so it wouldn’t be as useful? I’m curious now!
HTTPS is a mass feature and LE saw a need to make this available for free and with easier deployment and automation. And if implemented with state of the art technology it's a very robust and secure technology.
S/MIME is super niche. Even within the niche of email encryption it's a niche protocol. Also it suffers from loads of security problems and this RFC covers only a small fraction of them (and doesn't do a very good job due to backwards compatibility - it still has a "MUST support" the broken CBC modes).
S/MIME is super niche. Even within the niche of email encryption it's a niche protocol. Also it suffers from loads of security problems and this RFC covers only a small fraction of them (and doesn't do a very good job due to backwards compatibility - it still has a "MUST support" the broken CBC modes).
>S/MIME is super niche. Even within the niche of email encryption it's a niche protocol
Compared to what, PGP? As far as I know, S/MIME has the most prevalent support out of the box in email software.
Compared to what, PGP? As far as I know, S/MIME has the most prevalent support out of the box in email software.
It's been said that S/MIME has more implementations than users.
My guess would be there's more PGP users than S/MIME, but I could be wrong (and I doubt anyone has reliable numbers). In any case, everyone should agree that both are super niche.
My guess would be there's more PGP users than S/MIME, but I could be wrong (and I doubt anyone has reliable numbers). In any case, everyone should agree that both are super niche.
There's almost certainly more users of S/MIME than PGP. PGP keyservers can be well-analyzed for number of available keys, which is somewhere in the region of hundred thousands to millions, with the number of active users probably around a hundred thousand or so. S/MIME is known to be used by the DoD and CAC, which gives it several million users.
To rough orders of magnitude, there's something on the order of a few million users of S/MIME, a few hundred thousand of PGP, and a few billion for DKIM, with DKIM happening for about half of email.
>and a few billion for DKIM, with DKIM happening for about half of email
I'm not sure I'd count DKIM in this category, since it's not user-facing.
I'm not sure I'd count DKIM in this category, since it's not user-facing.
Also, does DKIM really provide the same sort of authentication that PGP / s/MIME would? All DKIMs verify is that the message was in fact authorized to emanate from that domain - PGP & S/MIME attempt to confirm that a particular identity belongs to a particular address.
DKIM signs the message headers (including the From: header) and (a hash of) the message body. So you can validate that a message has not been tampered with, and is from the mailbox it says it is (assuming your mail provider rejects messages with an invalid signature, irrespective of e.g. DMARC).
Search the forum.
If I remember correctly it’s about validation and scalability. I don’t believe they ever gave a good reason not to.
If I remember correctly it’s about validation and scalability. I don’t believe they ever gave a good reason not to.