Hi Alex, Thanks for the quick response. I think in general it would probably be ok to have Certificates immutable, however, if you want to support signing of a Certificate it can't be completely immutable. Unless you come up with a workflow which requires to generate a CSR first and after signing you get your cert and can't change it anymore. I might be just spoiled because in pyOpenSSL you can basically do whatever you want with a certificate instance, which took me a while to wrap my head around when I first started using it.
Something to think about. Erik On Thu, Apr 30, 2015 at 2:47 PM, Alex Gaynor <alex.gay...@gmail.com> wrote: > 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 > _______________________________________________ Cryptography-dev mailing list Cryptography-dev@python.org https://mail.python.org/mailman/listinfo/cryptography-dev
