5 ms·

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 c

by lol768 8y ago

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?

kevingrahl 8y ago
Let’s Encrypt has said multiple times that they will not offer S/MIME certificates.
- yardstick 8y ago
  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 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!
  - kevingrahl 8y ago
    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.
  - hannob 8y ago
    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).
    - lol768 8y ago
      >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.
      - jcranmer 8y ago
        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.
        lol768 8y ago
        >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.
        Chlorus 8y ago
        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.
        aaronmdjones 8y ago
        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).
      - hannob 8y ago
        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.
tialaramex 8y ago
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. Don't hold your breath.
- lol768 8y ago
  >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/security-group/certs/policy/#inclusion 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?
dcbadacd 8y ago
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%BChitutvustus_toorik https://eid.eesti.ee/index.php/EID_funktsioonide_l%C3%BChitu...
- andrewshadura 8y ago
  You don't need anything to specifically support them since AFAIK they provide a pluggable PCKS11 module.
jaas 8y ago
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.
- all_blue_chucks 8y ago
  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.
  - lol768 8y ago
    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 https://tools.ietf.org/html/draft-ietf-acme-email-smime-04) and offering free certs.
- lol768 8y ago
  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?

by lol768 8y ago

kevingrahl 8y ago

Let’s Encrypt has said multiple times that they will not offer S/MIME certificates.

yardstick 8y ago
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 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!
- kevingrahl 8y ago
  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.
- hannob 8y ago
  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).
  - lol768 8y ago
    >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.
    - jcranmer 8y ago
      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.
      - lol768 8y ago
        >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.
        Chlorus 8y ago
        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.
        aaronmdjones 8y ago
        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).
    - hannob 8y ago
      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.

tialaramex 8y ago

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. Don't hold your breath.

lol768 8y ago
>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/security-group/certs/policy/#inclusion 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?

dcbadacd 8y ago

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%BChitutvustus_toorik https://eid.eesti.ee/index.php/EID_funktsioonide_l%C3%BChitu...

andrewshadura 8y ago
You don't need anything to specifically support them since AFAIK they provide a pluggable PCKS11 module.

jaas 8y ago

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.

all_blue_chucks 8y ago
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.
- lol768 8y ago
  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 https://tools.ietf.org/html/draft-ietf-acme-email-smime-04) and offering free certs.
lol768 8y ago
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?