[Cryptography-dev] Concern over x509 interface design

Alex Gaynor alex.gaynor at gmail.com
Fri May 1 00:44:35 CEST 2015


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


More information about the Cryptography-dev mailing list