[Cryptography-dev] Concern over x509 interface design

[Erik Trauschke]

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