From erik.trauschke at gmail.com Fri May 1 00:00:38 2015 From: erik.trauschke at gmail.com (Erik Trauschke) Date: Thu, 30 Apr 2015 15:00:38 -0700 Subject: [Cryptography-dev] Concern over x509 interface design In-Reply-To: References: Message-ID: 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 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 > 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 > From alex.gaynor at gmail.com Fri May 1 00:44:35 2015 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Thu, 30 Apr 2015 18:44:35 -0400 Subject: [Cryptography-dev] Concern over x509 interface design In-Reply-To: References: Message-ID: 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 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 > 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 > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.trauschke at gmail.com Fri May 1 01:15:31 2015 From: erik.trauschke at gmail.com (Erik Trauschke) Date: Thu, 30 Apr 2015 16:15:31 -0700 Subject: [Cryptography-dev] Concern over x509 interface design In-Reply-To: References: Message-ID: 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 > 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 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 >> 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 >> > >> > 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 >> > >> _______________________________________________ >> 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 > From jerryguitarist at gmail.com Sat May 2 16:30:59 2015 From: jerryguitarist at gmail.com (Eeshan Garg) Date: Sat, 2 May 2015 20:00:59 +0530 Subject: [Cryptography-dev] Need advice on how to get started contributing to pyca/cryptography In-Reply-To: References: Message-ID: Hi! So I took a look at #1863 and I think none of the methods mentioned in the ticket are bound (except the one that is already crossed out in the list, SSL_CTX_set_tlsext_status_cb). Also, I haven't learned much C yet, is that going to be a problem while working on this issue? :-) Thanks a lot for answering my questions! It means a lot! :-) Warm regards, Eeshan Garg On Thu, Apr 30, 2015 at 9:41 PM, Paul Kehrer wrote: > Take a look at 1863 and 1864 for some discussion about what needs to be > bound. It looks like a first pass might be excluding any of the OCSP > methods listed in 1863. You'll also want to verify that the items listed > aren't already bound. > > > On April 29, 2015 at 9:34:38 AM, Eeshan Garg (jerryguitarist at gmail.com) > wrote: > > Hi! > > So I submitted two pull requests for < > https://github.com/pyca/cryptography/issues/1870>. And both have them > have been merged and the issue has been closed. :-) > > I have a couple of questions. So, you said that < > https://github.com/pyca/cryptography/issues/1863> is challenging and > requires some discussion; in the meantime, is there anything I should read > or go through (code or documentation) before working on this issue? Also, > is it necessary to leave a comment on an issue indicating that you are > working on it or plan on working on it? :-) > > Thanks & regards, > Eeshan Garg > > On Wed, Apr 29, 2015 at 9:28 AM, Eeshan Garg > wrote: > >> Hey Paul! >> >> I am working on the first one right now and I'll submit a PR for it soon! >> I'll ask on IRC or on the mailing list if I have any questions. :-) >> >> Thanks & regards, >> Eeshan Garg >> >> On Wed, Apr 29, 2015 at 3:13 AM, Paul Kehrer >> wrote: >> >>> Hey Eeshan, good to hear from you again. Take a look at >>> https://github.com/pyca/cryptography/issues/1870 and >>> https://github.com/pyca/cryptography/issues/1863. The latter is more >>> challenging and requires some discussion so starting with 1870 might >>> be a good idea. >>> >>> -Paul >>> >>> On Tue, Apr 28, 2015 at 12:46 PM, Eeshan Garg >>> wrote: >>> > Hello! >>> > >>> > I really want to contribute to pyca/cryptography. I already have a >>> > development environment setup and I have run the tests. At the PyCon >>> sprints >>> > I worked on , and I >>> also >>> > submitted a PR for it , >>> but >>> > it was decided that we won't be moving forward with what I was working >>> on. >>> > >>> > It would mean a lot to me if someone could give me some guidance and >>> help me >>> > find something to work on and get started. :-) >>> > >>> > Thanks, >>> > Eeshan Garg >>> > >>> > _______________________________________________ >>> > 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: From erik.trauschke at gmail.com Thu May 7 18:56:24 2015 From: erik.trauschke at gmail.com (Erik Trauschke) Date: Thu, 7 May 2015 09:56:24 -0700 Subject: [Cryptography-dev] Interfaces for CRL handling Message-ID: 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-adding-CRL-interfaces.patch Type: application/octet-stream Size: 41614 bytes Desc: not available URL: From paul.l.kehrer at gmail.com Thu May 7 21:05:27 2015 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Thu, 7 May 2015 14:05:27 -0500 Subject: [Cryptography-dev] Interfaces for CRL handling In-Reply-To: References: Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.trauschke at gmail.com Thu May 7 22:19:37 2015 From: erik.trauschke at gmail.com (Erik Trauschke) Date: Thu, 7 May 2015 13:19:37 -0700 Subject: [Cryptography-dev] Interfaces for CRL handling In-Reply-To: References: Message-ID: 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 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 > From andre.l.caron at gmail.com Sat May 9 06:33:52 2015 From: andre.l.caron at gmail.com (=?UTF-8?B?QW5kcsOpIENhcm9u?=) Date: Sat, 9 May 2015 00:33:52 -0400 Subject: [Cryptography-dev] Interfaces for CRL handling In-Reply-To: References: Message-ID: 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 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 > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.trauschke at gmail.com Sat May 9 07:18:22 2015 From: erik.trauschke at gmail.com (Erik Trauschke) Date: Fri, 8 May 2015 22:18:22 -0700 Subject: [Cryptography-dev] Interfaces for CRL handling In-Reply-To: References: Message-ID: 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 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 > 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 >> 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 > From andre.l.caron at gmail.com Sat May 9 22:50:36 2015 From: andre.l.caron at gmail.com (=?UTF-8?B?QW5kcsOpIENhcm9u?=) Date: Sat, 9 May 2015 16:50:36 -0400 Subject: [Cryptography-dev] Interfaces for CRL handling In-Reply-To: References: Message-ID: 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 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 > 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 > > > 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 > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.trauschke at gmail.com Mon May 11 19:11:59 2015 From: erik.trauschke at gmail.com (Erik Trauschke) Date: Mon, 11 May 2015 10:11:59 -0700 Subject: [Cryptography-dev] Interfaces for CRL handling In-Reply-To: References: Message-ID: 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 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 > 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 >> 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 >> > >> > 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 >> >> 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 > From paul.l.kehrer at gmail.com Mon May 11 20:50:48 2015 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Mon, 11 May 2015 13:50:48 -0500 Subject: [Cryptography-dev] Interfaces for CRL handling In-Reply-To: References: Message-ID: 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 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 > 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 >> 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 >> > >> > 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 >> >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.trauschke at gmail.com Mon May 11 21:43:46 2015 From: erik.trauschke at gmail.com (Erik Trauschke) Date: Mon, 11 May 2015 12:43:46 -0700 Subject: [Cryptography-dev] Interfaces for CRL handling In-Reply-To: References: Message-ID: <78826c6f-b6d6-4f9c-badd-8624d337a502@email.android.com> Ok, I'll get on that then. Erik On May 11, 2015 11:50:48 AM PDT, Paul Kehrer 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 >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 > >> 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 > >>> 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 >>> > >>> > 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 > >>> >> 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: From erik.trauschke at gmail.com Mon May 11 22:49:19 2015 From: erik.trauschke at gmail.com (Erik Trauschke) Date: Mon, 11 May 2015 13:49:19 -0700 Subject: [Cryptography-dev] Interfaces for CRL handling In-Reply-To: <78826c6f-b6d6-4f9c-badd-8624d337a502@email.android.com> References: <78826c6f-b6d6-4f9c-badd-8624d337a502@email.android.com> Message-ID: 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.) 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. Let me know if you think that's a good idea. Erik On Mon, May 11, 2015 at 12:43 PM, Erik Trauschke wrote: > Ok, I'll get on that then. > > Erik > > > On May 11, 2015 11:50:48 AM PDT, Paul Kehrer > 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 >> 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 >> > >> > 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 >> >> 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 >> >> > >> >> > 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 >> >> >> >> >> >> 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 From erik.trauschke at gmail.com Tue May 12 15:10:54 2015 From: erik.trauschke at gmail.com (Erik Trauschke) Date: Tue, 12 May 2015 06:10:54 -0700 Subject: [Cryptography-dev] Interfaces for CRL handling In-Reply-To: References: <78826c6f-b6d6-4f9c-badd-8624d337a502@email.android.com> Message-ID: On May 12, 2015 6:04:10 AM PDT, Paul Kehrer wrote: >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)) > 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? > wrote:? >> Ok, I'll get on that then.? >>? >> Erik? >>? >>? >> On May 11, 2015 11:50:48 AM PDT, Paul Kehrer >? >> 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 >? >>> 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? >>> > ? >>> > 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 >? >>> >> 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? >>> >> > ? >>> >> > 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? >>> >> >> ? >>> >> >> 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? From paul.l.kehrer at gmail.com Tue May 12 15:04:10 2015 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Tue, 12 May 2015 08:04:10 -0500 Subject: [Cryptography-dev] Interfaces for CRL handling In-Reply-To: References: <78826c6f-b6d6-4f9c-badd-8624d337a502@email.android.com> Message-ID: 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? wrote:? > Ok, I'll get on that then.? >? > Erik? >? >? > On May 11, 2015 11:50:48 AM PDT, Paul Kehrer ? > 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 ? >> 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? >> > ? >> > 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 ? >> >> 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? >> >> > ? >> >> > 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? >> >> >> ? >> >> >> 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: From paul.l.kehrer at gmail.com Thu May 14 03:45:41 2015 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Wed, 13 May 2015 20:45:41 -0500 Subject: [Cryptography-dev] PyCA cryptography 0.9 released Message-ID: On behalf of all the contributors I am pleased to announce the release of PyCA/cryptography (https://github.com/pyca/cryptography) 0.9! Changelog: * Removed support for Python 3.2. This version of Python is rarely used and caused support headaches. Users affected by this should upgrade to 3.3+. * Deprecated support for Python 2.6. At the time there is no time table for actually dropping support, however we strongly encourage all users to upgrade their Python, as Python 2.6 no longer receives support from the Python core team. * Add support for the SECP256K1 elliptic curve. * Fixed compilation when using an OpenSSL which was compiled with the no-comp (OPENSSL_NO_COMP) option. * Support DER serialization of public keys using the public_bytes method of RSAPublicKeyWithSerialization, DSAPublicKeyWithSerialization, and EllipticCurvePublicKeyWithSerialization. * Support DER serialization of private keys using the private_bytes method of RSAPrivateKeyWithSerialization, DSAPrivateKeyWithSerialization, and EllipticCurvePrivateKeyWithSerialization. * Add support for parsing X.509 certificate signing requests (CSRs) with load_pem_x509_csr() and load_der_x509_csr(). * Moved cryptography.exceptions.InvalidToken to cryptography.hazmat.primitives.twofactor.InvalidToken and deprecated the old location. This was moved to minimize confusion between this exception and cryptography.fernet.InvalidToken. * Added support for X.509 extensions in Certificate objects. The following extensions are supported as of this release: - BasicConstraints - AuthorityKeyIdentifier - SubjectKeyIdentifier - KeyUsage - SubjectAlternativeName - ExtendedKeyUsage - CRLDistributionPoints - AuthorityInformationAccess - CertificatePolicies Note that unsupported extensions with the critical flag raise UnsupportedExtension while unsupported extensions set to non-critical are silently ignored. Read the X.509 documentation for more information. You can also view a more attractive version of the changelog here:?https://cryptography.io/en/latest/changelog/ Master will be reopening for development of the tenth release shortly. -Paul Kehrer (reaperhulk) -------------- next part -------------- An HTML attachment was scrubbed... URL: From dariosn at gmail.com Thu May 14 10:20:51 2015 From: dariosn at gmail.com (Dario Sneidermanis) Date: Thu, 14 May 2015 05:20:51 -0300 Subject: [Cryptography-dev] ECPrivateKey form private_value Message-ID: Hi, I'm trying to compute an EllipticCurvePrivateKey from a private_value (d). It seems that the only way to achieve this is to create an EllipticCurvePrivateNumbers object, but the constructor takes both the private_value and the public_numbers. Why does it need the public_numbers, when it could compute them (knowing the curve), by doing d*G (G being the curve generator)? Is there any way to go from d to the ECPrivKey without doing d*G by myself? Thanks, Dario -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.l.kehrer at gmail.com Thu May 14 18:11:12 2015 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Thu, 14 May 2015 11:11:12 -0500 Subject: [Cryptography-dev] ECPrivateKey form private_value In-Reply-To: References: Message-ID: Hi Dario, The creation of an EllipticCurvePrivateNumbers object does require you to do d*G yourself at this time. There is some precedent for us adding functions to compute other elements (see:?https://cryptography.io/en/latest/hazmat/primitives/asymmetric/rsa/#handling-partial-rsa-private-keys) so a function to do this makes sense to me. -Paul On May 14, 2015 at 3:21:29 AM, Dario Sneidermanis (dariosn at gmail.com) wrote: Hi, I'm trying to compute an EllipticCurvePrivateKey from a private_value (d). It seems that the only way to achieve this is to create an EllipticCurvePrivateNumbers object, but the constructor takes both the private_value and the public_numbers. Why does it need the public_numbers, when it could compute them (knowing the curve), by doing d*G (G being the curve generator)? Is there any way to go from d to the ECPrivKey without doing d*G by myself? Thanks, Dario _______________________________________________ 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: From alex.gaynor at gmail.com Thu May 14 19:45:15 2015 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Thu, 14 May 2015 13:45:15 -0400 Subject: [Cryptography-dev] ECPrivateKey form private_value In-Reply-To: References: Message-ID: Perhaps an EllipticCurvePrivateNumbers.from_private_number_and_curve() would be appropriate to automatically compute the public key? Alex On Thu, May 14, 2015 at 12:11 PM, Paul Kehrer wrote: > Hi Dario, > > The creation of an EllipticCurvePrivateNumbers object does require you to > do d*G yourself at this time. There is some precedent for us adding > functions to compute other elements (see: > https://cryptography.io/en/latest/hazmat/primitives/asymmetric/rsa/#handling-partial-rsa-private-keys) > so a function to do this makes sense to me. > > -Paul > > On May 14, 2015 at 3:21:29 AM, Dario Sneidermanis (dariosn at gmail.com) > wrote: > > Hi, > > I'm trying to compute an EllipticCurvePrivateKey from a private_value (d). > It seems that the only way to achieve this is to create an > EllipticCurvePrivateNumbers object, but the constructor takes both the > private_value and the public_numbers. > > Why does it need the public_numbers, when it could compute them (knowing > the curve), by doing d*G (G being the curve generator)? > > Is there any way to go from d to the ECPrivKey without doing d*G by myself? > > Thanks, > Dario > _______________________________________________ > 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 > > -- "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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dariosn at gmail.com Sat May 16 00:25:45 2015 From: dariosn at gmail.com (Dario Sneidermanis) Date: Fri, 15 May 2015 19:25:45 -0300 Subject: [Cryptography-dev] ECPrivateKey form private_value In-Reply-To: References: Message-ID: That'd be perfect. If you need a hand I can make a first draft over the weekend. Dario On Thu, May 14, 2015 at 2:45 PM, Alex Gaynor wrote: > Perhaps an EllipticCurvePrivateNumbers.from_private_number_and_curve() > would be appropriate to automatically compute the public key? > > Alex > > On Thu, May 14, 2015 at 12:11 PM, Paul Kehrer > wrote: > >> Hi Dario, >> >> The creation of an EllipticCurvePrivateNumbers object does require you to >> do d*G yourself at this time. There is some precedent for us adding >> functions to compute other elements (see: >> https://cryptography.io/en/latest/hazmat/primitives/asymmetric/rsa/#handling-partial-rsa-private-keys) >> so a function to do this makes sense to me. >> >> -Paul >> >> On May 14, 2015 at 3:21:29 AM, Dario Sneidermanis (dariosn at gmail.com) >> wrote: >> >> Hi, >> >> I'm trying to compute an EllipticCurvePrivateKey from a private_value >> (d). It seems that the only way to achieve this is to create an >> EllipticCurvePrivateNumbers object, but the constructor takes both the >> private_value and the public_numbers. >> >> Why does it need the public_numbers, when it could compute them (knowing >> the curve), by doing d*G (G being the curve generator)? >> >> Is there any way to go from d to the ECPrivKey without doing d*G by >> myself? >> >> Thanks, >> Dario >> _______________________________________________ >> 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 >> >> > > > -- > "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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.l.kehrer at gmail.com Sat May 16 06:23:33 2015 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Fri, 15 May 2015 21:23:33 -0700 Subject: [Cryptography-dev] ECPrivateKey form private_value In-Reply-To: References: Message-ID: Help is always appreciated; if you'd like to submit a PR we'll be happy to review it! -Paul On May 15, 2015 at 3:26:29 PM, Dario Sneidermanis (dariosn at gmail.com) wrote: That'd be perfect. If you need a hand I can make a first draft over the weekend. Dario On Thu, May 14, 2015 at 2:45 PM, Alex Gaynor wrote: Perhaps an EllipticCurvePrivateNumbers.from_private_number_and_curve() would be appropriate to automatically compute the public key? Alex On Thu, May 14, 2015 at 12:11 PM, Paul Kehrer wrote: Hi Dario, The creation of an EllipticCurvePrivateNumbers object does require you to do d*G yourself at this time. There is some precedent for us adding functions to compute other elements (see:?https://cryptography.io/en/latest/hazmat/primitives/asymmetric/rsa/#handling-partial-rsa-private-keys) so a function to do this makes sense to me. -Paul On May 14, 2015 at 3:21:29 AM, Dario Sneidermanis (dariosn at gmail.com) wrote: Hi, I'm trying to compute an EllipticCurvePrivateKey from a private_value (d). It seems that the only way to achieve this is to create an EllipticCurvePrivateNumbers object, but the constructor takes both the private_value and the public_numbers. Why does it need the public_numbers, when it could compute them (knowing the curve), by doing d*G (G being the curve generator)? Is there any way to go from d to the ECPrivKey without doing d*G by myself? Thanks, Dario _______________________________________________ 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 -- "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 _______________________________________________ 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: From dariosn at gmail.com Mon May 18 07:35:53 2015 From: dariosn at gmail.com (Dario Sneidermanis) Date: Mon, 18 May 2015 02:35:53 -0300 Subject: [Cryptography-dev] ECPrivateKey form private_value In-Reply-To: References: Message-ID: I just created a PR: https://github.com/pyca/cryptography/pull/1973. It'd be great to have some feedback on the interface and general approach before adding some tests and doc. Thanks! Dario On Sat, May 16, 2015 at 1:23 AM, Paul Kehrer wrote: > Help is always appreciated; if you'd like to submit a PR we'll be happy to > review it! > > -Paul > > On May 15, 2015 at 3:26:29 PM, Dario Sneidermanis (dariosn at gmail.com) > wrote: > > That'd be perfect. If you need a hand I can make a first draft over the > weekend. > > Dario > > > On Thu, May 14, 2015 at 2:45 PM, Alex Gaynor > wrote: > >> Perhaps an EllipticCurvePrivateNumbers.from_private_number_and_curve() >> would be appropriate to automatically compute the public key? >> >> Alex >> >> On Thu, May 14, 2015 at 12:11 PM, Paul Kehrer >> wrote: >> >>> Hi Dario, >>> >>> The creation of an EllipticCurvePrivateNumbers object does require you >>> to do d*G yourself at this time. There is some precedent for us adding >>> functions to compute other elements (see: >>> https://cryptography.io/en/latest/hazmat/primitives/asymmetric/rsa/#handling-partial-rsa-private-keys) >>> so a function to do this makes sense to me. >>> >>> -Paul >>> >>> On May 14, 2015 at 3:21:29 AM, Dario Sneidermanis (dariosn at gmail.com) >>> wrote: >>> >>> Hi, >>> >>> I'm trying to compute an EllipticCurvePrivateKey from a private_value >>> (d). It seems that the only way to achieve this is to create an >>> EllipticCurvePrivateNumbers object, but the constructor takes both the >>> private_value and the public_numbers. >>> >>> Why does it need the public_numbers, when it could compute them (knowing >>> the curve), by doing d*G (G being the curve generator)? >>> >>> Is there any way to go from d to the ECPrivKey without doing d*G by >>> myself? >>> >>> Thanks, >>> Dario >>> _______________________________________________ >>> 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 >>> >>> >> >> >> -- >> "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 >> >> > _______________________________________________ > 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: