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 wrote:
> Hi Erik,
>
> We'll support constructing a certificate in memory and signing it, but I
> suspec
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
wrote:
> Hi Alex,
>
> Thanks for t
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
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
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
