[Cryptography-dev] Concern over x509 interface design
Erik Trauschke
erik.trauschke at gmail.com
Thu Apr 30 23:44:32 CEST 2015
Hi all,
First of all I'd like to express how happy I am about this unified approach
to crypto mechanisms in Python and how active this project is.
I'm currently in the process of migrating a project from M2Crypto to
cryptography which will require a few additional things which are not in
the code yet but which I plan to add (and contribute to the project).
I'm a bit concerned about the interface decisions for things like the
Certificate() class in that it doesn't seem to lead in a direction that I
will easily be able to instantiate Certifcate objects in the future.
I'd think that it should be possible to do this:
c = x509.Certificate()
c.issuer = issuer_object
or
c.set_issuer(issuer_object)
...
At the moment I don't see how the current architecture will allow that in
the future. Even if I instantiate a _Certificate object from the backend
(which I shouldn't have to) I would still have to pass an x509 object
(talking about the OpenSSL backend here) to the constructor. I don't say
that this is wrong but it should be at least a keyword argument. Since you
are laying the ground work for an interface which probably shouldn't be
changed all the time, it seems dangerous to have required arguments which
are complicated for an user to pass. With a keyword argument you can have
it work right now without writing additional code but in the future the
object might be instantiated much easier without changing the interface
incompatibly.
But even then there is still the problem that the x509.Certificate class
can not be instantiated by itself. I guess one could have a make_cert()
function in x509.py which creates a proper cert for the user based on the
selected backend. Or maybe another class which inherits from Certificate
but I don't know how one would be able to associate it with the right
backend.
I know what you are trying to do with the abstract base classes, I'm just
wondering if that creates an interface which is complicated to consume.
I haven't found any information about what the final goal for the interface
design is so maybe the current state is just the groundwork and you already
have a plan in mind on how this all is supposed to be used once it's done.
So please don't see this as criticism and more as a general question.
Thanks
Erik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20150430/f4840a60/attachment.html>
More information about the Cryptography-dev
mailing list