[Cryptography-dev] Concern over x509 interface design

[Erik Trauschke]

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
>