[Cryptography-dev] Interfaces for CRL handling
Paul Kehrer
paul.l.kehrer at gmail.com
Tue May 12 15:04:10 CEST 2015
Some thoughts inline.
On May 11, 2015 at 3:49:20 PM, Erik Trauschke (erik.trauschke at gmail.com) wrote:
Hi all,
I'm trying to find a good way to model the extensions for the Revoked
object (crl_reason, crl_issuer, invalidity_date) into the current
interface.
Currently it seems we already have a lot of layers you'd have to
unwrap to get to an actual extension value and I don't think we want
to have an object abstraction for every single thing the x509 standard
supports.
So I was thinking of returning the crl_reason directly:
if code == 1:
return ReasonFlags.key_compromise
...
(I'm still thinking we should have the numerical value in there
somewhere. Right now, if someone writes code using this interface
she'd have to test against a string representation. If someone ever
changes these strings in cryptography, this code will break. Also,
someone would have to look up what the string representation in
cryptography actually is because it's not exactly the same as in the
RFC.)
Why couldn't we just assert that all comparisons must be done using the enum? Even if we change the "value" in the enum (which would be an API break so we're more likely to create a new object and deprecate the old one if that is ever required) you can still do an identity check using the enum:
for revoked in crl:
if revoked.code is x509.ReasonFlags.key_compromise:
print("{} is revoked due to key compromise".format(revoked.serial_number))
The invalidity date returns just a datetime object, like other date functions.
For the crl_issuer (which is of type GENERAL_NAMES) I was thinking of
renaming x509.SubjectAlternativeName() to x509.GeneralNames and make
it multi-use. To be honest, the SubjectAlternativeName() doesn't do
anything specific which wouldn't be appropriate for any other usage.
So I think we could just have one class representing multiple general
names.
We've been representing GENERAL_NAMES (outside of SAN obviously) as a list of objects with the GeneralName interface, but this might be a reasonable approach. My primary concern is with documentation, but if the class becomes a GeneralNames class we could still have a SAN section that says it is an instance of GeneralNames. Interested in other opinions here too.
Let me know if you think that's a good idea.
Erik
On Mon, May 11, 2015 at 12:43 PM, Erik Trauschke
<erik.trauschke at gmail.com> wrote:
> Ok, I'll get on that then.
>
> Erik
>
>
> On May 11, 2015 11:50:48 AM PDT, Paul Kehrer <paul.l.kehrer at gmail.com>
> wrote:
>>
>> If you'd like to create a branch for the CRL work that'd be great. Thanks
>> for your help so far!
>>
>> -Paul
>>
>> On May 11, 2015 at 12:12:07 PM, Erik Trauschke (erik.trauschke at gmail.com)
>> wrote:
>>
>> Hi Paul,
>>
>> So I see all the CRLDistributionList extension code got put back. Are
>> you already working on the CRL processing code or do you want me to
>> create my own branch for this and file a pull request?
>>
>> Erik
>>
>> On Sat, May 9, 2015 at 1:50 PM, André Caron <andre.l.caron at gmail.com>
>> wrote:
>> > Hi Erik,
>> >
>> > I update mu pull request to add a basic interface for CRLs. It comes
>> > with
>> > an implementation of the OpenSSL backend for it too.
>> >
>> > I haven't tackled the CRL distribution points extension yet. Since those
>> > interfaces are somewhat independent from mine, I guess Paul's interfaces
>> > can
>> > come independently (obviously, I'll need them at one point to be able to
>> > implement my CA though :-).
>> >
>> > Cheers,
>> >
>> > André
>> >
>> > On Sat, May 9, 2015 at 1:18 AM, Erik Trauschke
>> > <erik.trauschke at gmail.com>
>> > wrote:
>> >>
>> >> The plan is that Paul puts back his interface definitions for
>> >> CRLDistributionPoints first. Then I can add the OpenSSL backend code
>> >> for that. Next are the interfaces for the CRL object and the OpenSSL
>> >> backend code for it.
>> >> It's interesting that it seems like we have a few people working on
>> >> the same thing at the same time, so i guess we just have to coordinate
>> >> things a bit.
>> >>
>> >> Erik
>> >>
>> >> On Fri, May 8, 2015 at 9:33 PM, André Caron <andre.l.caron at gmail.com>
>> >> wrote:
>> >> > Hi Erik,
>> >> >
>> >> > I've put up a pull request with preliminary support for CA
>> >> > operations.
>> >> > My
>> >> > pull request contains a builder for generating CRLs (but not for
>> >> > reading
>> >> > or
>> >> > processing them).
>> >> >
>> >> > I see your patch contains new interfaces for CRL processing. I hope
>> >> > you
>> >> > can
>> >> > get that patch moving forward with a pull request so that I can base
>> >> > my
>> >> > changes on them!
>> >> >
>> >> > Cheers,
>> >> >
>> >> > André
>> >> >
>> >> > On Thu, May 7, 2015 at 4:19 PM, Erik Trauschke
>> >> > <erik.trauschke at gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> Hi Paul,
>> >> >>
>> >> >> Ok, I'll wait until this goes back. Meanwhile there are a few other
>> >> >> interfaces I need and I'll work on them. I'll also have a look at
>> >> >> how
>> >> >> to create my own branch in github.
>> >> >>
>> >> >> Erik
>> >> >>
>> >> >> On Thu, May 7, 2015 at 12:05 PM, Paul Kehrer
>> >> >> <paul.l.kehrer at gmail.com>
>> >> >> wrote:
>> >> >> > Hi Erik,
>> >> >> >
>> >> >> > Thank you for your contribution! Some of your work overlaps with
>> >> >> > the
>> >> >> > interfaces we're currently building
>> >> >> > (https://github.com/pyca/cryptography/pull/1906/), but there is
>> >> >> > implementation work and other interfaces that will be very useful.
>> >> >> > Incidentally, your approach to fullname/relativename is one of the
>> >> >> > discussions underway on that PR right now.
>> >> >> >
>> >> >> > The normal way we do contribution and code review is via pull
>> >> >> > requests
>> >> >> > on
>> >> >> > GitHub. You can put your initial work up for discussion by doing
>> >> >> > the
>> >> >> > following:
>> >> >> >
>> >> >> > * Fork the project to your own account on github and check it out
>> >> >> > * Branch, commit, and push the branch to your own repository
>> >> >> > * Open a pull request against pyca/cryptography by following these
>> >> >> > instructions
>> >> >> > (https://help.github.com/articles/creating-a-pull-request/)
>> >> >> >
>> >> >> > We're also available on freenode in #cryptography-dev to chat any
>> >> >> > time.
>> >> >> >
>> >> >> > I personally would say this work should probably wait on merging
>> >> >> > #1906,
>> >> >> > at
>> >> >> > which point we can pull in the CRLDistributionPoints OpenSSL
>> >> >> > implementation,
>> >> >> > then follow that up with a PR for the CRL object, and finally the
>> >> >> > OpenSSL
>> >> >> > implementation of a parser to build the CRL object.
>> >> >> >
>> >> >> > -Paul
>> >> >> >
>> >> >> >
>> >> >> > On May 7, 2015 at 12:01:15 PM, Erik Trauschke
>> >> >> > (erik.trauschke at gmail.com)
>> >> >> > wrote:
>> >> >> >
>> >> >> > Hi all,
>> >> >> >
>> >> >> > For my project I need cryptography to support basic handling of
>> >> >> > CRLs,
>> >> >> > revoked certificates and CRLDistributionPoints.
>> >> >> >
>> >> >> > I attached a patch which adds these interfaces, including test
>> >> >> > cases
>> >> >> > for it. I have never provided patches to a github project so I'm
>> >> >> > not
>> >> >> > sure how the process works.
>> >> >> > Do you have a separate place for code reviews (I haven't seen code
>> >> >> > review discussions on this list)?
>> >> >> >
>> >> >> > I would appreciate if someone could look at my changes and put
>> >> >> > them
>> >> >> > back to the gate, but let me know if I need to approach this
>> >> >> > differently.
>> >> >> >
>> >> >> > Thanks
>> >> >> > Erik
>> >> >> > ________________________________
>> >> >> > _______________________________________________
>> >> >> > 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
>> >> >> >
>> >> >> _______________________________________________
>> >> >> 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
>> >> >
>> >> _______________________________________________
>> >> 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
>> >
>> _______________________________________________
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20150512/d8433878/attachment-0001.html>
More information about the Cryptography-dev
mailing list