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