From aowtea at gmail.com Thu Dec 8 09:13:35 2016 From: aowtea at gmail.com (Aow Tea) Date: Thu, 8 Dec 2016 22:13:35 +0800 Subject: [Cryptography-dev] How to add the extension 'subject directory attributes' to a certificate using Python? Message-ID: Dear everyone, I have a trouble in adding the extension 'subject directory attributes' to a certificate using Python. I have tried to use 'subjectDirAttrs' and 'subjectDirectoryAttributes', but neither of them can work. The error is 'OpenSSL.crypto.Error: [('X509 V3 routines', 'DO_EXT_NCONF', 'unknown extension name'), ('X509 V3 routines', 'X509V3_EXT_nconf', 'error in extension')]'. I have installed PyOpenSSL v16.1.0 and imported crypto from OpenSSL as the code below shows. My programming environment is Ubuntu 16.04.1 x64 and Python 2.7.12. Can anyone give a practical solution? In addition, when I want to add another extension 'certificate policies', the error is 'OpenSSL.crypto.Error: [('X509 V3 routines', 'DO_EXT_NCONF', 'no config database'), ('X509 V3 routines', 'X509V3_EXT_nconf', 'error in extension')]'. Can anyone tell me how to add this extension to a certificate? Thanks in advance! # My code #! /usr/bin/env python from OpenSSL import crypto newSubject=crypto.X509Name(crypto.X509().get_subject()) newSubject.C='US' newSubject.ST='California' newSubject.O='University of California, Davis' newSubject.OU='Computer Science, UCDavis' newSubject.CN='www.cs.ucdavis.edu' newCert=crypto.X509() newCert.set_version(2) newCert.set_serial_number(2016120711) newCert.set_notBefore('20161207125959Z') newCert.set_notAfter('20171207125959Z') newCert.set_issuer(newSubject) newCert.set_subject(newSubject) pkObject=crypto.PKey() pkObject.generate_key(crypto.TYPE_RSA,2048) newCert.set_pubkey(pkObject) newExt=crypto.X509Extension('basicConstraints', True, 'CA:true') newCert.add_extensions([newExt]) newExt=crypto.X509Extension('subjectDirAttrs', True, 'something') newCert.add_extensions([newExt]) newCert.sign(pkObject,'sha256') with open('sample.pem','w') as f: f.write(crypto.dump_certificate(crypto.FILETYPE_PEM,newCert)) -------------- next part -------------- An HTML attachment was scrubbed... URL: From aragwitz.lists at pobox.com Fri Dec 9 13:28:39 2016 From: aragwitz.lists at pobox.com (Augustina Ragwitz) Date: Fri, 09 Dec 2016 10:28:39 -0800 Subject: [Cryptography-dev] Interested in your CI Experience Message-ID: <1481308119.3679775.814044321.3109F708@webmail.messagingengine.com> I'm working on a project with a group of folks from the Openstack community called BonnyCI. In a nutshell, we're making the Openstack Infra CI environment work with Github and making it available for non-Openstack projects. I've spoken with Donald Stufft privately to see if you all might want to chat further about your current CI workflow and he suggested I reach out to the mailing list. Our big challenge with BonnyCI is while we know the Openstack needs and use cases, we have little knowledge outside of that, and we want to make sure what we're building is actually going to help address any issues folks might be having wih their current setup. As BonnyCI gets more stable, we'll also be looking for projects who would be willing to try it out! If anyone would be interested in talking to me further, I'm happy to talk on this list, via direct email, IRC, hangouts/skype/etc. I've been lurking in your IRC channel, so feel free to ping me or message me directly there (nick: auggy). I don't want this to take too much of your time (or energy) so I'm open to whatever works for anyone who is interested in talking to me further. -- Augustina Ragwitz Se?ora Software Engineer --- irc: auggy From paul.l.kehrer at gmail.com Fri Dec 9 15:51:13 2016 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Fri, 9 Dec 2016 15:51:13 -0500 Subject: [Cryptography-dev] Interested in your CI Experience In-Reply-To: <1481308119.3679775.814044321.3109F708@webmail.messagingengine.com> References: <1481308119.3679775.814044321.3109F708@webmail.messagingengine.com> Message-ID: Hi Augustina, cryptography's needs are a bit unusual. Since we depend on the underlying OS/distribution to provide us with OpenSSL (or commoncrypto on the macOS side) and we compile against a library that has a somewhat checkered past with versioning we have to test against numerous configurations. To achieve the coverage we want we currently use two different CI systems and aggregate coverage across them. == Travis CI == Recent CI build: https://travis-ci.org/pyca/cryptography/builds/181337155 Travis CI gives us configuration-as-code, reasonable concurrency (we have 10 simultaneous builders, which is a godsend with the number of jobs we run), and support for both linux and macOS (multiple versions). == Jenkins == Recent CI build: https://jenkins.cryptography.io/job/cryptography-master/1879/ Jenkins (using github pull request builder and multiconfiguration jobs) allows us to test unusual configs (like random test order) as well as against the set of configurations not supported by Travis. This includes Windows, FreeBSD, various linux distributions, and additional versions of macOS. Jenkins also lets us build wheels for distribution during releases using the same infrastructure. We currently ship 21 wheels, but that number will grow shortly with Python 3.6. Our current config is not using jenkinsfile (which has proven challenging to implement due to a variety of bugs) so the configs are not checked into CI and we commonly have to spend time working on the cluster since it's managed by us. However, an advantage this does offer is that our concurrency scales with our willingness to boot more VMs... So, in an ideal world what we want out of CI is: * Many OSes/distributions * configuration as code * high concurrency to minimize total CI time * integration with github for status reporting * fast and reliable booting of test instances (whether they're full VMs or containers) As part of the "we want it to be fast" requirement being able to cache artifacts we may re-use repeatedly (like Python runtimes) can be extremely valuable in lowering total CI runtime. If BonnyCI can offer this to us in the future then we'll be happy to take a close look! -Paul Kehrer (reaperhulk) On December 9, 2016 at 12:28:52 PM, Augustina Ragwitz ( aragwitz.lists at pobox.com) wrote: I'm working on a project with a group of folks from the Openstack community called BonnyCI. In a nutshell, we're making the Openstack Infra CI environment work with Github and making it available for non-Openstack projects. I've spoken with Donald Stufft privately to see if you all might want to chat further about your current CI workflow and he suggested I reach out to the mailing list. Our big challenge with BonnyCI is while we know the Openstack needs and use cases, we have little knowledge outside of that, and we want to make sure what we're building is actually going to help address any issues folks might be having wih their current setup. As BonnyCI gets more stable, we'll also be looking for projects who would be willing to try it out! If anyone would be interested in talking to me further, I'm happy to talk on this list, via direct email, IRC, hangouts/skype/etc. I've been lurking in your IRC channel, so feel free to ping me or message me directly there (nick: auggy). I don't want this to take too much of your time (or energy) so I'm open to whatever works for anyone who is interested in talking to me further. -- Augustina Ragwitz Se?ora Software Engineer --- irc: auggy _______________________________________________ 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 Fri Dec 9 16:28:10 2016 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Fri, 9 Dec 2016 16:28:10 -0500 Subject: [Cryptography-dev] How to add the extension 'subject directory attributes' to a certificate using Python? In-Reply-To: References: Message-ID: The error you're seeing is because OpenSSL doesn't have a shortname mapping to an extension type for that (unusual) extension. I believe you can create it using the OpenSSL conf ASN.1 syntax but help with that is outside the scope of this mailing list, sorry! On December 8, 2016 at 8:13:54 AM, Aow Tea (aowtea at gmail.com) wrote: Dear everyone, I have a trouble in adding the extension 'subject directory attributes' to a certificate using Python. I have tried to use 'subjectDirAttrs' and 'subjectDirectoryAttributes', but neither of them can work. The error is 'OpenSSL.crypto.Error: [('X509 V3 routines', 'DO_EXT_NCONF', 'unknown extension name'), ('X509 V3 routines', 'X509V3_EXT_nconf', 'error in extension')]'. I have installed PyOpenSSL v16.1.0 and imported crypto from OpenSSL as the code below shows. My programming environment is Ubuntu 16.04.1 x64 and Python 2.7.12. Can anyone give a practical solution? In addition, when I want to add another extension 'certificate policies', the error is 'OpenSSL.crypto.Error: [('X509 V3 routines', 'DO_EXT_NCONF', 'no config database'), ('X509 V3 routines', 'X509V3_EXT_nconf', 'error in extension')]'. Can anyone tell me how to add this extension to a certificate? Thanks in advance! # My code #! /usr/bin/env python from OpenSSL import crypto newSubject=crypto.X509Name(crypto.X509().get_subject()) newSubject.C='US' newSubject.ST='California' newSubject.O='University of California, Davis' newSubject.OU='Computer Science, UCDavis' newSubject.CN='www.cs.ucdavis.edu' newCert=crypto.X509() newCert.set_version(2) newCert.set_serial_number(2016120711) newCert.set_notBefore('20161207125959Z') newCert.set_notAfter('20171207125959Z') newCert.set_issuer(newSubject) newCert.set_subject(newSubject) pkObject=crypto.PKey() pkObject.generate_key(crypto.TYPE_RSA,2048) newCert.set_pubkey(pkObject) newExt=crypto.X509Extension('basicConstraints', True, 'CA:true') newCert.add_extensions([newExt]) newExt=crypto.X509Extension('subjectDirAttrs', True, 'something') newCert.add_extensions([newExt]) newCert.sign(pkObject,'sha256') with open('sample.pem','w') as f: f.write(crypto.dump_certificate(crypto.FILETYPE_PEM,newCert)) _______________________________________________ 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 eranm at google.com Mon Dec 12 06:43:05 2016 From: eranm at google.com (Eran Messeri) Date: Mon, 12 Dec 2016 11:43:05 +0000 Subject: [Cryptography-dev] Generating deterministic ECDSA signatures Message-ID: Hi, Is there a way to generate deterministic ECDSA signatures? With the following code I get a different signature each time: eckey = default_backend().load_pem_private_key(pkey_pem, password=None) eckey.sign('test', ec.ECDSA(hashes.SHA256())) But to implement signing code compliant with RFC6962-bis (section 12.4, draft 21: https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-21#section-12.4) the signature produced has to be the same every time. Thanks, Eran -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.gaynor at gmail.com Mon Dec 12 07:34:32 2016 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Mon, 12 Dec 2016 07:34:32 -0500 Subject: [Cryptography-dev] Generating deterministic ECDSA signatures In-Reply-To: References: Message-ID: Hi Eran, At the moment, no. Right now we simply use whatever OpenSSL does for generating `k`. Alex On Mon, Dec 12, 2016 at 6:43 AM, Eran Messeri via Cryptography-dev < cryptography-dev at python.org> wrote: > Hi, > > Is there a way to generate deterministic ECDSA signatures? > With the following code I get a different signature each time: > eckey = default_backend().load_pem_private_key(pkey_pem, password=None) > eckey.sign('test', ec.ECDSA(hashes.SHA256())) > > But to implement signing code compliant with RFC6962-bis (section 12.4, > draft 21: https://tools.ietf.org/html/draft-ietf-trans-rfc6962- > bis-21#section-12.4) the signature produced has to be the same every time. > > Thanks, > Eran > > _______________________________________________ > 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: D1B3 ADC0 E023 8CA6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.l.kehrer at gmail.com Mon Dec 12 13:37:39 2016 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Mon, 12 Dec 2016 10:37:39 -0800 Subject: [Cryptography-dev] PyCA/cryptography 1.7 released Message-ID: PyCA cryptography 1.7 has been released to PyPI. cryptography is a package which provides cryptographic recipes and primitives to Python developers. Our goal is for it to be your "cryptographic standard library". We support Python 2.6-2.7, Python 3.3+, and PyPy. Changelog (https://cryptography.io/en/latest/changelog/#id1): * Support for OpenSSL 1.0.0 has been removed. Users on older version of OpenSSL will need to upgrade. * Added support for Diffie-Hellman key exchange using exchange() * The OS random engine for OpenSSL has been rewritten to improve compatibility with embedded Python and other edge cases. More information about this change can be found in the pull request. Thanks to everyone who helped with this release! The upcoming cryptography 1.8 will (among other features) switch our static wheels to link against OpenSSL 1.1.0. -Paul Kehrer (reaperhulk) -------------- next part -------------- An HTML attachment was scrubbed... URL: From aragwitz.lists at pobox.com Mon Dec 12 14:23:23 2016 From: aragwitz.lists at pobox.com (Augustina Ragwitz) Date: Mon, 12 Dec 2016 11:23:23 -0800 Subject: [Cryptography-dev] Interested in your CI Experience In-Reply-To: References: <1481308119.3679775.814044321.3109F708@webmail.messagingengine.com> Message-ID: <1481570603.3216355.816617961.6FE2DA55@webmail.messagingengine.com> Thanks so much for the detailed response!! I will check out your TravisCI and Jenkins setup and follow up with further questions. Again, I really appreciate your time and look forward to hopefully working with you all more! Augustina From paul.l.kehrer at gmail.com Tue Dec 13 18:03:39 2016 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Tue, 13 Dec 2016 17:03:39 -0600 Subject: [Cryptography-dev] PyCA cryptography 1.7.1 Message-ID: PyCA cryptography 1.7.1 has been released to PyPI. This is a small bug fix release. Changelog: * Fixed a regression in int_from_bytes where it failed to accept bytearray. -Paul Kehrer (reaperhulk) -------------- next part -------------- An HTML attachment was scrubbed... URL: From frank.siebenlist at gmail.com Wed Dec 14 12:37:31 2016 From: frank.siebenlist at gmail.com (Frank Siebenlist) Date: Wed, 14 Dec 2016 09:37:31 -0800 Subject: [Cryptography-dev] LibreSSL support? Message-ID: It's not mentioned in the manual, but I can see people discussing LibreSSL related patches and such... Could you please comment on pyca/cryptography's support for LibreSSL as a backend? Thanks, Frank. From paul.l.kehrer at gmail.com Wed Dec 14 23:15:39 2016 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Wed, 14 Dec 2016 23:15:39 -0500 Subject: [Cryptography-dev] LibreSSL support? In-Reply-To: References: Message-ID: Since I accidentally replied to this off list replying one more time to capture the entire conversation for others. -Paul On December 14, 2016 at 10:14:34 PM, Frank Siebenlist ( frank.siebenlist at gmail.com) wrote: Hi Paul - no problem replying back to the list - didn?t noice it either - thanks again for reply - feels a little tricky with all those libs that have the same name, different code bases, and different so version# - guess ldconfig will chose the one first found in the paths - regards, Frank. "From a security perspective, if you're connected, you're screwed." - Daniel J. Bernstein > On Dec 14, 2016, at 5:41 PM, Paul Kehrer wrote: > > Oops, I realize I replied to you off-list! Do you mind if I reply back to list after this so everyone can see the replies? > > Anyway, if the libressl shared objects have a different soversion than the openssl shared objects (I don't know, but I sure hope so), then you'll just need to set CFLAGS and LDFLAGS during compile and make sure the libraries are in your ldconfig. > > -Paul > > On December 14, 2016 at 2:55:57 PM, Frank Siebenlist ( frank.siebenlist at gmail.com) wrote: > >> Thanks for the quick reply - good to know that option is available! >> >> Any guidelines how to configure pyca/cryptography to use LibreSSL when >> OpenSSL is the default install? >> How do you point to the lib you want? >> >> - Frank. >> >> On Wed, Dec 14, 2016 at 12:16 PM, Paul Kehrer wrote: >> > We test against LibreSSL 2.4.x right now and it is supported (although it >> > doesn't appear that we document that). There's currently an issue with 2.5.x >> > but that's a development release and the issue is on their side. >> > >> > -Paul >> > >> > On December 14, 2016 at 11:37:51 AM, Frank Siebenlist >> > (frank.siebenlist at gmail.com) wrote: >> > >> > It's not mentioned in the manual, but I can see people discussing >> > LibreSSL related patches and such... >> > >> > Could you please comment on pyca/cryptography's support for LibreSSL >> > as a backend? >> > >> > Thanks, Frank. >> > _______________________________________________ >> > 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 readthedocs at readthedocs.org Sun Dec 18 18:05:50 2016 From: readthedocs at readthedocs.org (Read the Docs) Date: Sun, 18 Dec 2016 23:05:50 -0000 Subject: [Cryptography-dev] Failed: Cryptography (latest) Message-ID: <20161218230550.11329.2360@web03.servers.readthedocs.org> Build Failed for Cryptography (latest) Error: Version locked, retrying in 5 minutes. You can find out more about this failure here: https://readthedocs.org/projects/cryptography/builds/4801661/ If you have questions, a good place to start is the FAQ: https://docs.readthedocs.org/en/latest/faq.html Keep documenting, Read the Docs -- http://readthedocs.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From readthedocs at readthedocs.org Sun Dec 18 18:58:19 2016 From: readthedocs at readthedocs.org (Read the Docs) Date: Sun, 18 Dec 2016 23:58:19 -0000 Subject: [Cryptography-dev] Failed: Cryptography (latest) Message-ID: <20161218235819.17558.63277@web04.servers.readthedocs.org> Build Failed for Cryptography (latest) Error: Version locked, retrying in 5 minutes. You can find out more about this failure here: https://readthedocs.org/projects/cryptography/builds/4805965/ If you have questions, a good place to start is the FAQ: https://docs.readthedocs.org/en/latest/faq.html Keep documenting, Read the Docs -- http://readthedocs.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From readthedocs at readthedocs.org Sun Dec 18 18:05:47 2016 From: readthedocs at readthedocs.org (Read the Docs) Date: Sun, 18 Dec 2016 23:05:47 -0000 Subject: [Cryptography-dev] Failed: Cryptography (latest) Message-ID: <20161218230547.12311.95689@web02.servers.readthedocs.org> Build Failed for Cryptography (latest) Error: Version locked, retrying in 5 minutes. You can find out more about this failure here: https://readthedocs.org/projects/cryptography/builds/4801660/ If you have questions, a good place to start is the FAQ: https://docs.readthedocs.org/en/latest/faq.html Keep documenting, Read the Docs -- http://readthedocs.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From bbobrov at mirantis.com Mon Dec 19 16:17:11 2016 From: bbobrov at mirantis.com (Boris Bobrov) Date: Tue, 20 Dec 2016 00:17:11 +0300 Subject: [Cryptography-dev] Key storages Message-ID: <3adafdab-a644-cd20-6d06-743f19a2b28b@mirantis.com> Hi! I work on OpenStack Keystone. We use Fernet keys for our tokens. A token is a basically a tuple encrypted with fernet key. Fernet keys need to be rotated once in a while. Now we store them on disk. But it is problematic to rotate them in containers, because containers are supposed to be immutable. So idea of key storages came up. For example, we could store the keys in a database. Or in OpenStack Barbican, which is a REST API designed for the secure storage, provisioning and management of secrets such as encryption keys. Or in Custodia, https://github.com/latchset/custodia However, it doesn't sound like this should be in Keystone. It is not keystone-specific and all Fernet keys users will probably benefit of that. What do you think about adding this sort of functionality to cryptography? The idea is to define an abstract class in cryptography for a storage. An instance of storage will be passed to MultiFernet, which will read the keys from there, create individual instances of fernet.Fernet and perform all the usual stuff. Storage classes can be implemented inside cryptography or outside of it. What do you think about this? From alex.gaynor at gmail.com Mon Dec 19 16:18:55 2016 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Mon, 19 Dec 2016 16:18:55 -0500 Subject: [Cryptography-dev] Key storages In-Reply-To: <3adafdab-a644-cd20-6d06-743f19a2b28b@mirantis.com> References: <3adafdab-a644-cd20-6d06-743f19a2b28b@mirantis.com> Message-ID: I'm opposed -- there's no benefit to this being in cryptography itself; this API can be totally implemented outside of it. Alex On Mon, Dec 19, 2016 at 4:17 PM, Boris Bobrov wrote: > Hi! > > I work on OpenStack Keystone. We use Fernet keys for our tokens. A > token is a basically a tuple encrypted with fernet key. > > Fernet keys need to be rotated once in a while. Now we store them on > disk. But it is problematic to rotate them in containers, because > containers are supposed to be immutable. > > So idea of key storages came up. For example, we could store the > keys in a database. Or in OpenStack Barbican, which is a REST API > designed for the secure storage, provisioning and management of > secrets such as encryption keys. Or in Custodia, > https://github.com/latchset/custodia > > However, it doesn't sound like this should be in Keystone. It is > not keystone-specific and all Fernet keys users will probably > benefit of that. What do you think about adding this sort of > functionality to cryptography? > > The idea is to define an abstract class in cryptography for a storage. > An instance of storage will be passed to MultiFernet, which will > read the keys from there, create individual instances of > fernet.Fernet and perform all the usual stuff. Storage classes can > be implemented inside cryptography or outside of it. > > What do you think about this? > _______________________________________________ > 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: D1B3 ADC0 E023 8CA6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.l.kehrer at gmail.com Mon Dec 19 18:18:36 2016 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Tue, 20 Dec 2016 00:18:36 +0100 Subject: [Cryptography-dev] Key storages In-Reply-To: References: <3adafdab-a644-cd20-6d06-743f19a2b28b@mirantis.com> Message-ID: This sounds like a good idea for a package that depends on cryptography, but not in cryptography itself. If you decide to do that please let me know as I'd love to see it! -Paul Kehrer (reaperhulk) On December 19, 2016 at 3:19:08 PM, Alex Gaynor (alex.gaynor at gmail.com) wrote: I'm opposed -- there's no benefit to this being in cryptography itself; this API can be totally implemented outside of it. Alex On Mon, Dec 19, 2016 at 4:17 PM, Boris Bobrov wrote: > Hi! > > I work on OpenStack Keystone. We use Fernet keys for our tokens. A > token is a basically a tuple encrypted with fernet key. > > Fernet keys need to be rotated once in a while. Now we store them on > disk. But it is problematic to rotate them in containers, because > containers are supposed to be immutable. > > So idea of key storages came up. For example, we could store the > keys in a database. Or in OpenStack Barbican, which is a REST API > designed for the secure storage, provisioning and management of > secrets such as encryption keys. Or in Custodia, > https://github.com/latchset/custodia > > However, it doesn't sound like this should be in Keystone. It is > not keystone-specific and all Fernet keys users will probably > benefit of that. What do you think about adding this sort of > functionality to cryptography? > > The idea is to define an abstract class in cryptography for a storage. > An instance of storage will be passed to MultiFernet, which will > read the keys from there, create individual instances of > fernet.Fernet and perform all the usual stuff. Storage classes can > be implemented inside cryptography or outside of it. > > What do you think about this? > _______________________________________________ > 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: D1B3 ADC0 E023 8CA6 _______________________________________________ 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 sigmavirus24 at gmail.com Tue Dec 20 07:16:23 2016 From: sigmavirus24 at gmail.com (Ian Cordasco) Date: Tue, 20 Dec 2016 06:16:23 -0600 Subject: [Cryptography-dev] Key storages In-Reply-To: References: <3adafdab-a644-cd20-6d06-743f19a2b28b@mirantis.com> Message-ID: I tend to agree with Alex. There's nothing dealing with persistence in Cryptography at the moment (whether that be persisting to disk or elsewhere). This doesn't belong in Cryptography. On Mon, Dec 19, 2016 at 3:18 PM, Alex Gaynor wrote: > I'm opposed -- there's no benefit to this being in cryptography itself; this > API can be totally implemented outside of it. > > Alex > > On Mon, Dec 19, 2016 at 4:17 PM, Boris Bobrov wrote: >> >> Hi! >> >> I work on OpenStack Keystone. We use Fernet keys for our tokens. A >> token is a basically a tuple encrypted with fernet key. >> >> Fernet keys need to be rotated once in a while. Now we store them on >> disk. But it is problematic to rotate them in containers, because >> containers are supposed to be immutable. >> >> So idea of key storages came up. For example, we could store the >> keys in a database. Or in OpenStack Barbican, which is a REST API >> designed for the secure storage, provisioning and management of >> secrets such as encryption keys. Or in Custodia, >> https://github.com/latchset/custodia >> >> However, it doesn't sound like this should be in Keystone. It is >> not keystone-specific and all Fernet keys users will probably >> benefit of that. What do you think about adding this sort of >> functionality to cryptography? >> >> The idea is to define an abstract class in cryptography for a storage. >> An instance of storage will be passed to MultiFernet, which will >> read the keys from there, create individual instances of >> fernet.Fernet and perform all the usual stuff. Storage classes can >> be implemented inside cryptography or outside of it. >> >> What do you think about this? >> _______________________________________________ >> 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: D1B3 ADC0 E023 8CA6 > > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev > -- Ian Cordasco