<div dir="ltr">Hi Erik,<div><br></div><div>We'll support constructing a certificate in memory and signing it, but I suspect the API will look a bit like:</div><div><br></div><div>x509.CertificateBuilder().set_issuer(...).add_extension(...).sign(parent_certificate)</div><div><br></div><div>Alex</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 30, 2015 at 6:00 PM, Erik Trauschke <span dir="ltr"><<a href="mailto:erik.trauschke@gmail.com" target="_blank">erik.trauschke@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Alex,<br>
<br>
Thanks for the quick response. I think in general it would probably be<br>
ok to have Certificates immutable, however, if you want to support<br>
signing of a Certificate it can't be completely immutable. Unless you<br>
come up with a workflow which requires to generate a CSR first and<br>
after signing you get your cert and can't change it anymore.<br>
I might be just spoiled because in pyOpenSSL you can basically do<br>
whatever you want with a certificate instance, which took me a while<br>
to wrap my head around when I first started using it.<br>
<br>
Something to think about.<br>
<span class="HOEnZb"><font color="#888888"><br>
Erik<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Thu, Apr 30, 2015 at 2:47 PM, Alex Gaynor <<a href="mailto:alex.gaynor@gmail.com">alex.gaynor@gmail.com</a>> wrote:<br>
> Hi Erik,<br>
><br>
> So far we've been focussed on the "read-only" side, we haven't really<br>
> discussed the "create a certificate" workflow.<br>
><br>
> That said:<br>
><br>
> IMO Certificate should always be immutable, when we get to creation, the API<br>
> should either go through a distinct CertificateBuilder or make_cert() API.<br>
><br>
> Alex<br>
><br>
> On Thu, Apr 30, 2015 at 5:44 PM, Erik Trauschke <<a href="mailto:erik.trauschke@gmail.com">erik.trauschke@gmail.com</a>><br>
> wrote:<br>
>><br>
>> Hi all,<br>
>><br>
>> First of all I'd like to express how happy I am about this unified<br>
>> approach to crypto mechanisms in Python and how active this project is.<br>
>><br>
>> I'm currently in the process of migrating a project from M2Crypto to<br>
>> cryptography which will require a few additional things which are not in the<br>
>> code yet but which I plan to add (and contribute to the project).<br>
>><br>
>> I'm a bit concerned about the interface decisions for things like the<br>
>> Certificate() class in that it doesn't seem to lead in a direction that I<br>
>> will easily be able to instantiate Certifcate objects in the future.<br>
>> I'd think that it should be possible to do this:<br>
>><br>
>> c = x509.Certificate()<br>
>> c.issuer = issuer_object<br>
>>   or<br>
>> c.set_issuer(issuer_object)<br>
>> ...<br>
>><br>
>> At the moment I don't see how the current architecture will allow that in<br>
>> the future. Even if I instantiate a _Certificate object from the backend<br>
>> (which I shouldn't have to) I would still have to pass an x509 object<br>
>> (talking about the OpenSSL backend here) to the constructor. I don't say<br>
>> that this is wrong but it should be at least a keyword argument. Since you<br>
>> are laying the ground work for an interface which probably shouldn't be<br>
>> changed all the time, it seems dangerous to have required arguments which<br>
>> are complicated for an user to pass. With a keyword argument you can have it<br>
>> work right now without writing additional code but in the future the object<br>
>> might be instantiated much easier without changing the interface<br>
>> incompatibly.<br>
>><br>
>> But even then there is still the problem that the x509.Certificate class<br>
>> can not be instantiated by itself. I guess one could have a make_cert()<br>
>> function in x509.py which creates a proper cert for the user based on the<br>
>> selected backend. Or maybe another class which inherits from Certificate but<br>
>> I don't know how one would be able to associate it with the right backend.<br>
>> I know what you are trying to do with the abstract base classes, I'm just<br>
>> wondering if that creates an interface which is complicated to consume.<br>
>><br>
>> I haven't found any information about what the final goal for the<br>
>> interface design is so maybe the current state is just the groundwork and<br>
>> you already have a plan in mind on how this all is supposed to be used once<br>
>> it's done. So please don't see this as criticism and more as a general<br>
>> question.<br>
>><br>
>> Thanks<br>
>> Erik<br>
>><br>
>><br>
>> _______________________________________________<br>
>> Cryptography-dev mailing list<br>
>> <a href="mailto:Cryptography-dev@python.org">Cryptography-dev@python.org</a><br>
>> <a href="https://mail.python.org/mailman/listinfo/cryptography-dev" target="_blank">https://mail.python.org/mailman/listinfo/cryptography-dev</a><br>
>><br>
><br>
><br>
><br>
> --<br>
> "I disapprove of what you say, but I will defend to the death your right to<br>
> say it." -- Evelyn Beatrice Hall (summarizing Voltaire)<br>
> "The people's good is the highest law." -- Cicero<br>
> GPG Key fingerprint: 125F 5C67 DFE9 4084<br>
><br>
> _______________________________________________<br>
> Cryptography-dev mailing list<br>
> <a href="mailto:Cryptography-dev@python.org">Cryptography-dev@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/cryptography-dev" target="_blank">https://mail.python.org/mailman/listinfo/cryptography-dev</a><br>
><br>
_______________________________________________<br>
Cryptography-dev mailing list<br>
<a href="mailto:Cryptography-dev@python.org">Cryptography-dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/cryptography-dev" target="_blank">https://mail.python.org/mailman/listinfo/cryptography-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">"I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)<br>"The people's good is the highest law." -- Cicero<br><div>GPG Key fingerprint: 125F 5C67 DFE9 4084</div></div></div>
</div>