Single pass processing of S/MIME messages

0 votes
asked Jan 13, 2014 by Stefan (180 points)
edited Jan 14, 2014

Cryptographic Message Syntax (CMS), on which S/MIME is based, permits single pass processing by design.

This is from RFC 5652 Section 2:

As a general design philosophy, each content type permits single pass processing using indefinite-length Basic Encoding Rules (BER)encoding. Single-pass operation is especially helpful if content is large, stored on tapes, or is "piped" from another process.

The same holds true for MIME messages in general, nothing in their structure prevents single pass processing.

Such single pass processing (also called stream processing elsewhere) would be very interesting for me because I would like to be able to en-/decrypt or sign/validate very large MIME messages which may cause problems if loaded fully into memory, especially on low-end hardware. Whether or not it is recommended/possible to actually transfer such large messages via SMTP/POP3/IMAP doesn't matter to me because I plan to transfer them via other means.

As I understand it, the classes in the Rebex Secure Mail library don't support single pass processing but need to have the whole content in memory to perform any operations, including cryptographic, on it. Is that correct or is there actually a way to handle arbitrary sized messages?

Applies to: Rebex Secure Mail

1 Answer

0 votes
answered Jan 14, 2014 by Lukas Pokorny (128,250 points)
edited Jan 14, 2014

You are right. CMS, MIME and S/MIME permit single pass processing, but unfortunately, Rebex Secure Mail library currently lacks support for this.

We have been aware of this limitation since the first version was released. Back then, we actually planned to add support for this approach, but eventually postponed the plans indefinitely. Why? Sadly, it doesn't score well in our cost–benefit analyses. I basically boils down to two points:

  • It would involve lot of work. Single pass processing would require introducing two new sets of API objects. One for stream-based S/MIME writing and another for stream-based S/MIME reading (see .NET's XmlDocument / XmlReader / XmlWriter for an example of this).
  • Only few customers would benefit from this. Most of them are fine with MailMessage. For the majority of the rest, MimeMessage is sufficient. Although you are definitely not the only one who would benefit from single pass processing API, it looks like reading/writing very large S/MIME messages is not a very common scenario.

Don't get me wrong - we would love to add MimeReader / MimeWriter objects to Rebex Secure Mail! But it seems that there are not enough customers out there who would pay us for that...

commented Jan 14, 2014 by Stefan (180 points)
edited Jan 14, 2014

Thanks for the quick answer! I totally understand and agree with everything you said. I just wanted to confirm that I didn't miss something you actually took the effort to implement.