Sounds good to me. The CertificateBuilder just needs to be able to consume CSR objects as well. But that wouldn't change the interface a lot.
Erik On Thu, Apr 30, 2015 at 3:44 PM, Alex Gaynor <alex.gay...@gmail.com> wrote: > Hi Erik, > > We'll support constructing a certificate in memory and signing it, but I > suspect the API will look a bit like: > > x509.CertificateBuilder().set_issuer(...).add_extension(...).sign(parent_certificate) > > Alex > > On Thu, Apr 30, 2015 at 6:00 PM, Erik Trauschke <erik.trausc...@gmail.com> > wrote: >> >> 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 > > > > > -- > "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
