On May 12, 2015 6:04:10 AM PDT, Paul Kehrer <paul.l.keh...@gmail.com> wrote:
>Some thoughts inline.
>On May 11, 2015 at 3:49:20 PM, Erik Trauschke
>(erik.trausc...@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))
>
Ok, fair enough.
>
>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.
The nice thing about the SAN class is that is has a method to get a certain
type of GeneralName. That's why I thought it would be beneficial to use here.
I'll make the change and see if someone complains during code review.
Thanks
Erik
>
>
>
>Let me know if you think that's a good idea.
>
>Erik
>
>On Mon, May 11, 2015 at 12:43 PM, Erik Trauschke
><erik.trausc...@gmail.com> wrote:
>> Ok, I'll get on that then.
>>
>> Erik
>>
>>
>> On May 11, 2015 11:50:48 AM PDT, Paul Kehrer
><paul.l.keh...@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.trausc...@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.ca...@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.trausc...@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.ca...@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.trausc...@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.keh...@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.trausc...@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@python.org
>>> >> >> > https://mail.python.org/mailman/listinfo/cryptography-dev
>>> >> >> >
>>> >> >> >
>>> >> >> > _______________________________________________
>>> >> >> > Cryptography-dev mailing list
>>> >> >> > Cryptography-dev@python.org
>>> >> >> > https://mail.python.org/mailman/listinfo/cryptography-dev
>>> >> >> >
>>> >> >> _______________________________________________
>>> >> >> Cryptography-dev mailing list
>>> >> >> Cryptography-dev@python.org
>>> >> >> https://mail.python.org/mailman/listinfo/cryptography-dev
>>> >> >
>>> >> >
>>> >> >
>>> >> > _______________________________________________
>>> >> > Cryptography-dev mailing list
>>> >> > Cryptography-dev@python.org
>>> >> > https://mail.python.org/mailman/listinfo/cryptography-dev
>>> >> >
>>> >> _______________________________________________
>>> >> Cryptography-dev mailing list
>>> >> Cryptography-dev@python.org
>>> >> https://mail.python.org/mailman/listinfo/cryptography-dev
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > Cryptography-dev mailing list
>>> > Cryptography-dev@python.org
>>> > https://mail.python.org/mailman/listinfo/cryptography-dev
>>> >
>>> _______________________________________________
>>> Cryptography-dev mailing list
>>> Cryptography-dev@python.org
>>> https://mail.python.org/mailman/listinfo/cryptography-dev
>>>
>>> ________________________________
>>>
>>> Cryptography-dev mailing list
>>> Cryptography-dev@python.org
>>> https://mail.python.org/mailman/listinfo/cryptography-dev
_______________________________________________
Cryptography-dev mailing list
Cryptography-dev@python.org
https://mail.python.org/mailman/listinfo/cryptography-dev
