Some notes on OpenSSL, S/MIME, email, various RFC standards and their relations.
Posted by jpluimers on 2015/03/10
Stuff I found out myself:
- OpenSSL does not like to have a period (dot) at the end of a S/MIME message (like many .EML files have as SMTP basically requires a period to terminate an email message.
- Indy sometimes changes the ContentType of S/MIME messages; you can reproduce this using the CopyEml demos; preliminary fix is in IdMessageHelperUnit.pas.
They should reorganize their site to make the most current version more findable; these links help me to track down what’s new: - Make sure your tools
- accept the old RSA MIME types:
- application/x-pkcs7-mime
- application/x-pkcs7-signature
- application/x-pkcs10
- but emit the new RFC 2311+ MIME types:
- application/pkcs7-mime
- application/pkcs7-signature
- application/pkcs10
- emit the new RFC MIME types:
- accept the old RSA MIME types:
Some links I found useful:
- Ruby interface to S/MIME: Maximum encryption length [SOLVED] (already archived at the WayBack machine) ; How to Decode/extract smime.p7m file contents of SMIME signed email using Ruby OpenSSL library – Stack Overflow.
- Wikipedia:
- English: S/MIME – Wikipedia, the free encyclopedia.
- German: S/MIME – Wikipedia.
(the German article is more thorough) - English: PKCS – Wikipedia, the free encyclopedia.
German: PKCS – Wikipedia.
- Interesting take on enhancing the “sign, then encrypt” way of security that most mail clients use: email – How to check if encrypted S/MIME message is also signed, without decrypting it – Stack Overflow.
- RFCs (the obsoletes tree is important for the historic perspective)
- S/MIME:
- RFC 5751 – Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification.
Obsoletes:
- RFC 5750 – Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling.
Obsoletes: - RFC 2634 – Enhanced Security Services for S/MIME.
- RFC 5035 – Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility.
- RFC 2311 – S/MIME Version 2 Message Specification.
- RFC 2312 – S/MIME Version 2 Certificate Handling.
- RFC 5751 – Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification.
- Encryption:
- RFC 2631 – Diffie-Hellman Key Agreement Method.
- RFC 5652 – Cryptographic Message Syntax (CMS).
Obsoletes: - RFC 5083 – Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type.
- RFC 4853 – Cryptographic Message Syntax (CMS) Multiple Signer Clarification.
- RFC 3369 – Cryptographic Message Syntax.
Obsoletes:- RFC 2630 – Cryptographic Message Syntax. (derived from PKCS7)
- RFC 3211 – Password-based Encryption for CMS.
- RFC 3370 – Cryptographic Message Syntax (CMS) Algorithms.
- RFC 5754 – Using SHA2 Algorithms with Cryptographic Message Syntax.
- RFC 2315 – PKCS #7: Cryptographic Message Syntax Version 1.5.
- RFC 1421 – Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures.
Obsoletes: - RFC 1422 – Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management.
Obsoletes:
- MIME, mail, mail headers, etc:
- Mail headers:
- MIME
- RFC 4021 – Registration of Mail and MIME Header Fields.
- RFC 2231 – MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations.
Obsoletes: - RFC 2045 – Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies.
Obsoletes:- RFC 1590 – Media Type Registration Procedure.
- RFC 1522 – MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text.
- RFC 1521 – MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies.
- RFC 2046 – Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types.
(see also the separate Media Types section below) - RFC 2047 – MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text.
Obsoletes: 1590, 1522, 1521. - RFC 4289 – Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures.
Obsoletes:- RFC 2048 – Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures.
Obsoletes: 1590, 1522, 1521.
- RFC 2048 – Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures.
- RFC 2049 – Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples.
Obsoletes: 1590, 1522, 1521. - RFC 6657 – Update to MIME regarding “charset” Parameter Handling in Textual Media Types.
- RFC 5147 – URI Fragment Identifiers for the text/plain Media Type.
- SMTP
- RFC 6531 – SMTP Extension for Internationalized Email.
Obsoletes: - RFC 4865 – SMTP Submission Service Extension for Future Message Release.
- RFC 3463 – Enhanced Mail System Status Codes.
Obsoletes: - RFC 2852 – Deliver By SMTP Service Extension.
- RFC 3885 – SMTP Service Extension for Message Tracking.
- RFC 4954 – SMTP Service Extension for Authentication.
Obsoletes: - RFC 5248 – A Registry for SMTP Enhanced Mail System Status Codes.
- RFC 6531 – SMTP Extension for Internationalized Email.
- Media types:
- Notifications:
- RFC 3798 – Message Disposition Notification.
Obsoletes: - RFC 6533 – Internationalized Delivery Status and Disposition Notifications.
Obsoletes: - RFC 3461 – Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs).
- RFC 3464 – An Extensible Message Format for Delivery Status Notifications.
Obsoletes: - RFC 3886 – An Extensible Message Format for Message Tracking Responses.
- RFC 4468 – Message Submission BURL Extension.
- RFC 6522 – The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages.
- Obsoletes:
- RFC 3798 – Message Disposition Notification.
- S/MIME:
- Via Wikipedia: via Free S/MIME providers.
–jeroen
The Wiert Corner - irregular stream of stuff 
The End of Gmane? – via: Random Thoughts « The Wiert Corner – irregular stream of stuff said
[…] Some notes on OpenSSL, S/MIME, email, various RFC standards and their relations. (already archived at the WayBack machine) […]
Remy said
Indy saves EML files in dot-transparent format, which is not how EML files are supposed to be formatted. The entire file is actually encoded, but you will only notice the dot at the end if no other lines start with a dot, but they can. You should not be processing dot-transparent data with S/MIME, so it is not fair to say OpenSSL can’t handle the dots because it should not be given the dots to begin with. Dot-transparency is a transport encoding only. However, Indy’s dot-transparency logic is currently implemented at a layer that is shared with both its SMTP send/receive code and its file save/load code, the layer doesn’t know the data is being saved to file vs transmitted over a socket. That is going to be changed in Indy 11. But in the meantime, there is a workaround available (via TIdIOHandlerStreamMsg and its EscapeLines/UnescapeLines properties) to allow users to save/load EML files without dot-transparency if needed.
jpluimers said
Thanks for the update.