[Cryptography-dev] Concern over x509 interface design

Alex Gaynor alex.gaynor at gmail.com
Thu Apr 30 23:47:34 CEST 2015


Hi Erik,

So far we've been focussed on the "read-only" side, we haven't really
discussed the "create a certificate" workflow.

That said:

IMO Certificate should always be immutable, when we get to creation, the
API should either go through a distinct CertificateBuilder or make_cert()
API.

Alex

On Thu, Apr 30, 2015 at 5:44 PM, Erik Trauschke <erik.trauschke at gmail.com>
wrote:

> 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
>
>
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev
>
>


-- 
"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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20150430/d2fe5d8e/attachment-0001.html>


More information about the Cryptography-dev mailing list