GMime: Working like a madman on GMime-2.0 recently. So far, between yesterday and today, I've implemented a few new classes such as GMimeMultipartSigned and GMimeMultipartEncrypted which handle the multipart/signed and multipart/encrypted MIME types defined by rfc1847 as well as an abstract class GMimeCipherContext that has generic methods for encrypting, decrypting, signing, verifying, importing keys, and exporting keys. This class was mostly just ported from my GMIME_PGP_MIME branch (which was based on glib1) over to GObject. The only real difference is the addition of the import/export methods which will be useful for anyone (probably gonna be me) implementing the application/pgp-keys MIME type (which is only briefly mentioned in rfc2015 and rfc3156) for example. I'm sure S/MIME has a similar method, although I'm not as well versed with the S/MIME specifications so I'm not 100% sure how they go about this.
While I'm on the subject of multipart/signed, let me just say that I think the authors of this spec really screwed the pooch. Multipart/signed is completely Broken-By-Design (tm) - it must be treated completely different from any other multipart types. To work, its contents MUST be treated as opaque - but nothing in any of the mail specifications guarentee that content will go from point A to point B without modifying, in any way shape or form, the headers nor contents of a MIME part. This makes multipart/signed completely unreliable. You can't just go changing the rules for christ-sakes! When you extend a protocol that has been in use, you MUST be compatable with transfer agents that have already been implemented. This was NOT done in the multipart/signed specification. At all!