
S/MIME Version 4.0 Message Specification - okket
https://tools.ietf.org/html/rfc8551
======
ianlevesque
This section describes the changes made between S/MIME v3.2 and S/MIME v4.0.

    
    
       -  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.

~~~
ChrisSD
Formatting note: using code blocks for list works horribly on mobile.

~~~
microcolonel
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).

~~~
ChrisSD
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.

~~~
Ettvatre
Yes this is actually readable.

------
lol768
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?

~~~
jaas
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
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
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.

