[Cryptography-dev] Keys/Certificates/CRLs/x509 in pyOpenSSL

[Dominic Chen]

To add on to the existing discussion, I agree with deprecating cryptography in favor of pyopenssl, although personally I’d prefer to see pyopenssl continue providing an updated low-level OpenSSL interface.

As a bit of background, I originally started using pyopenssl when I was writing a research tool to parse a bunch of cryptography-related file formats (e.g. PEM/DER encoded X509, PKCS12, PKCS7, etc), and dump them into a SQL database for easy searching and filtering. I settled on pyopenssl after trying a number of other Python cryptography libraries, and discovering that they lacked support for features like elliptic curve cryptography, all of PCKS7/12, etc.

But after discovering that pyopenssl was somewhat deprecated in favor of cryptography, I ended up switching to cryptography, since it appeared to better maintained, and I believe I encountered some bugs. However, I was annoyed to find out that cryptography only provided a higher-level interface, and there was a lack of feature parity between the two projects.

This was a couple of months ago, so I don’t remember the exact details, but I recall that at the time, there was limited CRL parsing support, no parsing of unsupported OID’s in certificates, and no support for PKCS7. Additionally, the checks for standards compliance were frustrating to deal with, because I was only interested in parsing and dumping a bunch of certificates, not whether they were standards compliant, or whether the library would pars known OID’s into objects. Additionally, I also encountered some more bugs as well, which I believe are now fixed.

As a result, I ended up implementing my own wrapper interface around both libraries.


Thanks,

Dominic Chen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160104/f35f98dc/attachment.sig>