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

[Hynek Schlawack]

Hello Dominic,

> Am 05.01.2016 um 06:11 schrieb Dominic Chen <ddchen at andrew.cmu.edu>:
> 
> 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.

I assume that’s a typo?  We intend to add cryptography constructors to pyOpenSSL’s x509 classes; not deprecate cryptography.

> 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.

Thank you for your perspective for that’s what I hoped for.

Would you:

1. agree that our plans are neutral to your situation?
2. support us on making cryptography’s x509 layer more useful?  One of the key problems is that nobody maintaining pyOpenSSL actually fully understands pyOpenSSL.  Using new (but existing) APIs we understand seems like a path forward that causes least pain to everyone involved.

?

Regards,
Hynek
-------------- 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/20160106/968ac282/attachment.sig>