Feature Request: SMIME Support

[abhishek-ram]

I am working on a tool that implements the AS2 protocol for file transfers, a major requirement for it is SMIME support. I am currently using m2crypto to implement this but that project is no longer supported and also does not support Python 3.x and lacks support for PKCS7 signatures using the latest algorithms. Are there any plans to add SMIME support in your library?

[reaperhulk]

We do plan to eventually support SMIME, yes. The spec is pretty broad (and we're still working on some dependencies like X509), but we'll get there.

[Ayrx]

IIRC SMIME requires CMS? So we need to get #924 done as well.

[davidism]

Consider prioritizing this feature. The only other Python library providing SMIME is m2crypto, which is not available for Python 3, provides a very "raw" experience, and does not seem to be actively maintained.

This library is in a position to provide a feature that the Python ecosystem sorely lacks.

[reaperhulk]

@davidism Do you have some code written against M2Crypto right now that demonstrates your needs? The entirety of SMIME/CMS/X509 is very large and complex so supporting them generically is a long term project. However, if there's a way we can start supporting a subset of the complete specification and cover most use cases that'd be great.

[davidism]

I currently use it to sign (not encrypt) emails.

# load keys
smime = SMIME.SMIME()
smime.load_key('signer.key', 'signer.crt')

# generate signature from original message
# msg is an email object with no mail headers (just the multipart structure)
data = BIO.MemoryBuffer(msg.as_string())
p7 = smime.sign(data)
data.reset()
p7.write(data)

# signature attachment, remove the 'begin' and 'end' delimiters
sig = MIMEApplication(
    '\n'.join(data.read().split('\n')[1:-2]),
    'pkcs7-signature', encode_noop, name='smime.p7s'
)
sig.add_header('Content-Disposition', 'attachment;filename=smime.p7s')
sig.add_header('Content-Transfer-Encoding', 'base64')

# pack original message and signature
signed = MIMEMultipart('signed', protocol='application/pkcs7-signature', micalg='sha1')
signed.attach(msg)
signed.attach(sig)

# now set the mail headers on the new signed multipart structure

I don't have much experience with email, cryptography, or SMIME, this was all put together by comparing what this built to existing signed emails.

It would be great if there was better integration with Python's email library.

[abhishek-ram]

I think if ASN.1 support(parse/generate) can be provided then that will be a great starting place. As you have rightly said the entire SMIME/CMS/X509 set is too large to implement currently. If we have ASN.1 and a method to create specs(Classes similar to pyasn1) for different X509 types then each dev can contribute to these specs based on their needs and thus speeded up developement of CMS/X509 and inturn SMIME.

[davidism]

While I use SMIME to sign emails, I would not know where to start to create a "spec" for signing emails.

[abhishek-ram]

Yeah I can understand, but to be able to start to sign as per SMIME, we need a way to generate PKCS7 signed/enveloped data and to do that we need ASN.1. So if we can have ASN.1 then we can create the specfication for creating/reading PKCS7 type data as per the RFC. Once this is in place you will be able to pass conent to a function that will build the signature as per the previously defined specs. So this is a long process that starts with ASN.1.

[ttanner]

https://github.com/ttanner/kryptomime supports S/MIME

[davidism]

It appears to use subprocess to call openssl (there are a few of these libs, I just didn't mention them all). That's less ideal than having an actual Python wrapper.

[ttanner]

I was referring to your comment, M2Crypto would be the only Python library providing S/MIME support.
Why do you think having a native wrapper would be ideal?

[davidism]

Speed, as well as a native interface rather than trying to build command line args. As well as not accomplishing many of cryptography's goals, such as "high level APIs", "introspectability and testability", and avoiding "extremely error prone APIs, and bad defaults".

[alex]

subprocess is also problematic when used from large processes, because of
how fork/exec interacts wtih the virtual memory system (tl;dr; COW is not
sufficient)

On Thu, Mar 12, 2015 at 10:49 AM, David Lord notifications@github.com
wrote:

Speed, as well as a native interface rather than trying to build command
line args.

—
Reply to this email directly or view it on GitHub
#1621 (comment).

"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084