Re: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation
On 3.11.2016 00:18, Ben Lipton wrote: On 10/20/2016 03:52 PM, Ben Lipton wrote: On 10/17/2016 02:16 AM, Jan Cholasta wrote: On 13.10.2016 17:23, Ben Lipton wrote: Thank you, this was a really helpful clarification of your point. Comments below. Once again, I'm sorry I missed the email for so long. Ben On 09/05/2016 06:52 AM, Jan Cholasta wrote: On 27.8.2016 22:40, Ben Lipton wrote: On 08/25/2016 04:11 PM, Rob Crittenden wrote: Ben Lipton wrote: On 08/23/2016 03:54 AM, Jan Cholasta wrote: On 8.8.2016 22:23, Ben Lipton wrote: On 07/25/2016 07:45 AM, Jan Cholasta wrote: On 25.7.2016 13:11, Alexander Bokovoy wrote: On Mon, 25 Jul 2016, Jan Cholasta wrote: On 20.7.2016 16:05, Ben Lipton wrote: Hi, Thanks very much for the feedback! Some responses below; I hope you'll let me know what you think of my reasoning. On 07/20/2016 04:20 AM, Jan Cholasta wrote: Hi, On 17.6.2016 00:06, Ben Lipton wrote: On 06/14/2016 08:27 AM, Ben Lipton wrote: Hello all, I have written up a design proposal for making certificate requests easier to generate when using alternate certificate profiles: http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation. The use case for this is described in https://fedorahosted.org/freeipa/ticket/4899. I will be working on implementing this design over the next couple of months. If you have the time and interest, please take a look and share any comments or concerns that you have. Thanks! Ben Just a quick update to say that I've created a new document that covers the proposed schema additions in a more descriptive way (with diagrams!) I'm very new to developing with LDAP, so some more experienced eyes on the proposal would be very helpful, even if you don't have time to absorb the full design. Please take a look at http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Schema if you have a chance. I finally had a chance to take a look at this, here are some comments: 1) I don't like how transformation rules are tied to a particular helper and have to be duplicated for each of them. They should be generic and work with any helper, as helpers are just an implementation detail and their resulting data is the same. In fact, I think I would prefer if the CSR was generated using python-cryptography's CertificateSigningRequestBuilder [1] rather than openssl or certutil or any other command line tool. There are lots of tools that users might want to use to manage their private keys, so I don't know if we can assume that whatever library we prefer will actually be able to access the private key to sign a CSR, which is why I thought it would be useful to support more than one. python-cryptography has the notion of backends, which allow it to support multiple crypto implementations. Upstream it currently supports only OpenSSL [2], but some work has been done on PKCS#11 backend [3], which provides support for HSMs and soft-tokens (like NSS databases). Alternatively, for NSS databases (and other "simple" cases), you can generate the private key with python-cryptography using the default backend, export it to a file and import the file to the target database, so you don't actually need the PKCS#11 backend for them. So, the only thing that's currently lacking is HSM support, but given that we don't support HSMs in IPA nor in certmonger, I don't think it's an issue for now. The purpose of the mapping rule is to tie together the transformation rules that produce the same data into an object that's implementation-agnostic, so that profiles referencing those rules are automatically compatible with all the helper options. They are implementation-agnostic, as long as you consider `openssl` and `certutil` the only implementations :-) But I don't think this solution scales well to other possible implementations. Anyway, my main grudge is that the transformation rules shouldn't really be stored on and processed by the server. The server should know the *what* (mapping rules), but not the *how* (transformation rules). The *how* is an implementation detail and does not change in time, so there's no benefit in handling it on the server. It should be handled exclusively on the client, which I believe would also make the whole thing more robust (it would not be possible for a bug on the server to break all the clients). This is a good point. However, for the scope of Ben's project can we limit it by openssl and certutil support? Otherwise Ben wouldn't be able to complete the project in time. I'm fine with that, but I don't think it's up to me :-) This is turning out to be a common (and, I think, reasonable) reaction to the proposal. It is rather complex, and I worry that it will be difficult to configure. On the other hand, there is some hidden complexity to enabling a simpler config format, as well. One of the goals of the project as it was presented to me was to allow the creation of profiles that add certificate extensions *that
Re: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation
On 10/20/2016 03:52 PM, Ben Lipton wrote: On 10/17/2016 02:16 AM, Jan Cholasta wrote: On 13.10.2016 17:23, Ben Lipton wrote: Thank you, this was a really helpful clarification of your point. Comments below. Once again, I'm sorry I missed the email for so long. Ben On 09/05/2016 06:52 AM, Jan Cholasta wrote: On 27.8.2016 22:40, Ben Lipton wrote: On 08/25/2016 04:11 PM, Rob Crittenden wrote: Ben Lipton wrote: On 08/23/2016 03:54 AM, Jan Cholasta wrote: On 8.8.2016 22:23, Ben Lipton wrote: On 07/25/2016 07:45 AM, Jan Cholasta wrote: On 25.7.2016 13:11, Alexander Bokovoy wrote: On Mon, 25 Jul 2016, Jan Cholasta wrote: On 20.7.2016 16:05, Ben Lipton wrote: Hi, Thanks very much for the feedback! Some responses below; I hope you'll let me know what you think of my reasoning. On 07/20/2016 04:20 AM, Jan Cholasta wrote: Hi, On 17.6.2016 00:06, Ben Lipton wrote: On 06/14/2016 08:27 AM, Ben Lipton wrote: Hello all, I have written up a design proposal for making certificate requests easier to generate when using alternate certificate profiles: http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation. The use case for this is described in https://fedorahosted.org/freeipa/ticket/4899. I will be working on implementing this design over the next couple of months. If you have the time and interest, please take a look and share any comments or concerns that you have. Thanks! Ben Just a quick update to say that I've created a new document that covers the proposed schema additions in a more descriptive way (with diagrams!) I'm very new to developing with LDAP, so some more experienced eyes on the proposal would be very helpful, even if you don't have time to absorb the full design. Please take a look at http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Schema if you have a chance. I finally had a chance to take a look at this, here are some comments: 1) I don't like how transformation rules are tied to a particular helper and have to be duplicated for each of them. They should be generic and work with any helper, as helpers are just an implementation detail and their resulting data is the same. In fact, I think I would prefer if the CSR was generated using python-cryptography's CertificateSigningRequestBuilder [1] rather than openssl or certutil or any other command line tool. There are lots of tools that users might want to use to manage their private keys, so I don't know if we can assume that whatever library we prefer will actually be able to access the private key to sign a CSR, which is why I thought it would be useful to support more than one. python-cryptography has the notion of backends, which allow it to support multiple crypto implementations. Upstream it currently supports only OpenSSL [2], but some work has been done on PKCS#11 backend [3], which provides support for HSMs and soft-tokens (like NSS databases). Alternatively, for NSS databases (and other "simple" cases), you can generate the private key with python-cryptography using the default backend, export it to a file and import the file to the target database, so you don't actually need the PKCS#11 backend for them. So, the only thing that's currently lacking is HSM support, but given that we don't support HSMs in IPA nor in certmonger, I don't think it's an issue for now. The purpose of the mapping rule is to tie together the transformation rules that produce the same data into an object that's implementation-agnostic, so that profiles referencing those rules are automatically compatible with all the helper options. They are implementation-agnostic, as long as you consider `openssl` and `certutil` the only implementations :-) But I don't think this solution scales well to other possible implementations. Anyway, my main grudge is that the transformation rules shouldn't really be stored on and processed by the server. The server should know the *what* (mapping rules), but not the *how* (transformation rules). The *how* is an implementation detail and does not change in time, so there's no benefit in handling it on the server. It should be handled exclusively on the client, which I believe would also make the whole thing more robust (it would not be possible for a bug on the server to break all the clients). This is a good point. However, for the scope of Ben's project can we limit it by openssl and certutil support? Otherwise Ben wouldn't be able to complete the project in time. I'm fine with that, but I don't think it's up to me :-) This is turning out to be a common (and, I think, reasonable) reaction to the proposal. It is rather complex, and I worry that it will be difficult to configure. On the other hand, there is some hidden complexity to enabling a simpler config format, as well. One of the goals of the project as it was presented to me was to allow the creation of profiles that add certificate extensions *that
Re: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation
On 10/17/2016 02:16 AM, Jan Cholasta wrote: On 13.10.2016 17:23, Ben Lipton wrote: Thank you, this was a really helpful clarification of your point. Comments below. Once again, I'm sorry I missed the email for so long. Ben On 09/05/2016 06:52 AM, Jan Cholasta wrote: On 27.8.2016 22:40, Ben Lipton wrote: On 08/25/2016 04:11 PM, Rob Crittenden wrote: Ben Lipton wrote: On 08/23/2016 03:54 AM, Jan Cholasta wrote: On 8.8.2016 22:23, Ben Lipton wrote: On 07/25/2016 07:45 AM, Jan Cholasta wrote: On 25.7.2016 13:11, Alexander Bokovoy wrote: On Mon, 25 Jul 2016, Jan Cholasta wrote: On 20.7.2016 16:05, Ben Lipton wrote: Hi, Thanks very much for the feedback! Some responses below; I hope you'll let me know what you think of my reasoning. On 07/20/2016 04:20 AM, Jan Cholasta wrote: Hi, On 17.6.2016 00:06, Ben Lipton wrote: On 06/14/2016 08:27 AM, Ben Lipton wrote: Hello all, I have written up a design proposal for making certificate requests easier to generate when using alternate certificate profiles: http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation. The use case for this is described in https://fedorahosted.org/freeipa/ticket/4899. I will be working on implementing this design over the next couple of months. If you have the time and interest, please take a look and share any comments or concerns that you have. Thanks! Ben Just a quick update to say that I've created a new document that covers the proposed schema additions in a more descriptive way (with diagrams!) I'm very new to developing with LDAP, so some more experienced eyes on the proposal would be very helpful, even if you don't have time to absorb the full design. Please take a look at http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Schema if you have a chance. I finally had a chance to take a look at this, here are some comments: 1) I don't like how transformation rules are tied to a particular helper and have to be duplicated for each of them. They should be generic and work with any helper, as helpers are just an implementation detail and their resulting data is the same. In fact, I think I would prefer if the CSR was generated using python-cryptography's CertificateSigningRequestBuilder [1] rather than openssl or certutil or any other command line tool. There are lots of tools that users might want to use to manage their private keys, so I don't know if we can assume that whatever library we prefer will actually be able to access the private key to sign a CSR, which is why I thought it would be useful to support more than one. python-cryptography has the notion of backends, which allow it to support multiple crypto implementations. Upstream it currently supports only OpenSSL [2], but some work has been done on PKCS#11 backend [3], which provides support for HSMs and soft-tokens (like NSS databases). Alternatively, for NSS databases (and other "simple" cases), you can generate the private key with python-cryptography using the default backend, export it to a file and import the file to the target database, so you don't actually need the PKCS#11 backend for them. So, the only thing that's currently lacking is HSM support, but given that we don't support HSMs in IPA nor in certmonger, I don't think it's an issue for now. The purpose of the mapping rule is to tie together the transformation rules that produce the same data into an object that's implementation-agnostic, so that profiles referencing those rules are automatically compatible with all the helper options. They are implementation-agnostic, as long as you consider `openssl` and `certutil` the only implementations :-) But I don't think this solution scales well to other possible implementations. Anyway, my main grudge is that the transformation rules shouldn't really be stored on and processed by the server. The server should know the *what* (mapping rules), but not the *how* (transformation rules). The *how* is an implementation detail and does not change in time, so there's no benefit in handling it on the server. It should be handled exclusively on the client, which I believe would also make the whole thing more robust (it would not be possible for a bug on the server to break all the clients). This is a good point. However, for the scope of Ben's project can we limit it by openssl and certutil support? Otherwise Ben wouldn't be able to complete the project in time. I'm fine with that, but I don't think it's up to me :-) This is turning out to be a common (and, I think, reasonable) reaction to the proposal. It is rather complex, and I worry that it will be difficult to configure. On the other hand, there is some hidden complexity to enabling a simpler config format, as well. One of the goals of the project as it was presented to me was to allow the creation of profiles that add certificate extensions *that FreeIPA doesn't yet know about*. With the current
Re: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation
On 13.10.2016 17:23, Ben Lipton wrote: Thank you, this was a really helpful clarification of your point. Comments below. Once again, I'm sorry I missed the email for so long. Ben On 09/05/2016 06:52 AM, Jan Cholasta wrote: On 27.8.2016 22:40, Ben Lipton wrote: On 08/25/2016 04:11 PM, Rob Crittenden wrote: Ben Lipton wrote: On 08/23/2016 03:54 AM, Jan Cholasta wrote: On 8.8.2016 22:23, Ben Lipton wrote: On 07/25/2016 07:45 AM, Jan Cholasta wrote: On 25.7.2016 13:11, Alexander Bokovoy wrote: On Mon, 25 Jul 2016, Jan Cholasta wrote: On 20.7.2016 16:05, Ben Lipton wrote: Hi, Thanks very much for the feedback! Some responses below; I hope you'll let me know what you think of my reasoning. On 07/20/2016 04:20 AM, Jan Cholasta wrote: Hi, On 17.6.2016 00:06, Ben Lipton wrote: On 06/14/2016 08:27 AM, Ben Lipton wrote: Hello all, I have written up a design proposal for making certificate requests easier to generate when using alternate certificate profiles: http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation. The use case for this is described in https://fedorahosted.org/freeipa/ticket/4899. I will be working on implementing this design over the next couple of months. If you have the time and interest, please take a look and share any comments or concerns that you have. Thanks! Ben Just a quick update to say that I've created a new document that covers the proposed schema additions in a more descriptive way (with diagrams!) I'm very new to developing with LDAP, so some more experienced eyes on the proposal would be very helpful, even if you don't have time to absorb the full design. Please take a look at http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Schema if you have a chance. I finally had a chance to take a look at this, here are some comments: 1) I don't like how transformation rules are tied to a particular helper and have to be duplicated for each of them. They should be generic and work with any helper, as helpers are just an implementation detail and their resulting data is the same. In fact, I think I would prefer if the CSR was generated using python-cryptography's CertificateSigningRequestBuilder [1] rather than openssl or certutil or any other command line tool. There are lots of tools that users might want to use to manage their private keys, so I don't know if we can assume that whatever library we prefer will actually be able to access the private key to sign a CSR, which is why I thought it would be useful to support more than one. python-cryptography has the notion of backends, which allow it to support multiple crypto implementations. Upstream it currently supports only OpenSSL [2], but some work has been done on PKCS#11 backend [3], which provides support for HSMs and soft-tokens (like NSS databases). Alternatively, for NSS databases (and other "simple" cases), you can generate the private key with python-cryptography using the default backend, export it to a file and import the file to the target database, so you don't actually need the PKCS#11 backend for them. So, the only thing that's currently lacking is HSM support, but given that we don't support HSMs in IPA nor in certmonger, I don't think it's an issue for now. The purpose of the mapping rule is to tie together the transformation rules that produce the same data into an object that's implementation-agnostic, so that profiles referencing those rules are automatically compatible with all the helper options. They are implementation-agnostic, as long as you consider `openssl` and `certutil` the only implementations :-) But I don't think this solution scales well to other possible implementations. Anyway, my main grudge is that the transformation rules shouldn't really be stored on and processed by the server. The server should know the *what* (mapping rules), but not the *how* (transformation rules). The *how* is an implementation detail and does not change in time, so there's no benefit in handling it on the server. It should be handled exclusively on the client, which I believe would also make the whole thing more robust (it would not be possible for a bug on the server to break all the clients). This is a good point. However, for the scope of Ben's project can we limit it by openssl and certutil support? Otherwise Ben wouldn't be able to complete the project in time. I'm fine with that, but I don't think it's up to me :-) This is turning out to be a common (and, I think, reasonable) reaction to the proposal. It is rather complex, and I worry that it will be difficult to configure. On the other hand, there is some hidden complexity to enabling a simpler config format, as well. One of the goals of the project as it was presented to me was to allow the creation of profiles that add certificate extensions *that FreeIPA doesn't yet know about*. With the current proposal, one only has to add a rule generating text that the helper will
Re: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation
Thank you, this was a really helpful clarification of your point. Comments below. Once again, I'm sorry I missed the email for so long. Ben On 09/05/2016 06:52 AM, Jan Cholasta wrote: On 27.8.2016 22:40, Ben Lipton wrote: On 08/25/2016 04:11 PM, Rob Crittenden wrote: Ben Lipton wrote: On 08/23/2016 03:54 AM, Jan Cholasta wrote: On 8.8.2016 22:23, Ben Lipton wrote: On 07/25/2016 07:45 AM, Jan Cholasta wrote: On 25.7.2016 13:11, Alexander Bokovoy wrote: On Mon, 25 Jul 2016, Jan Cholasta wrote: On 20.7.2016 16:05, Ben Lipton wrote: Hi, Thanks very much for the feedback! Some responses below; I hope you'll let me know what you think of my reasoning. On 07/20/2016 04:20 AM, Jan Cholasta wrote: Hi, On 17.6.2016 00:06, Ben Lipton wrote: On 06/14/2016 08:27 AM, Ben Lipton wrote: Hello all, I have written up a design proposal for making certificate requests easier to generate when using alternate certificate profiles: http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation. The use case for this is described in https://fedorahosted.org/freeipa/ticket/4899. I will be working on implementing this design over the next couple of months. If you have the time and interest, please take a look and share any comments or concerns that you have. Thanks! Ben Just a quick update to say that I've created a new document that covers the proposed schema additions in a more descriptive way (with diagrams!) I'm very new to developing with LDAP, so some more experienced eyes on the proposal would be very helpful, even if you don't have time to absorb the full design. Please take a look at http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Schema if you have a chance. I finally had a chance to take a look at this, here are some comments: 1) I don't like how transformation rules are tied to a particular helper and have to be duplicated for each of them. They should be generic and work with any helper, as helpers are just an implementation detail and their resulting data is the same. In fact, I think I would prefer if the CSR was generated using python-cryptography's CertificateSigningRequestBuilder [1] rather than openssl or certutil or any other command line tool. There are lots of tools that users might want to use to manage their private keys, so I don't know if we can assume that whatever library we prefer will actually be able to access the private key to sign a CSR, which is why I thought it would be useful to support more than one. python-cryptography has the notion of backends, which allow it to support multiple crypto implementations. Upstream it currently supports only OpenSSL [2], but some work has been done on PKCS#11 backend [3], which provides support for HSMs and soft-tokens (like NSS databases). Alternatively, for NSS databases (and other "simple" cases), you can generate the private key with python-cryptography using the default backend, export it to a file and import the file to the target database, so you don't actually need the PKCS#11 backend for them. So, the only thing that's currently lacking is HSM support, but given that we don't support HSMs in IPA nor in certmonger, I don't think it's an issue for now. The purpose of the mapping rule is to tie together the transformation rules that produce the same data into an object that's implementation-agnostic, so that profiles referencing those rules are automatically compatible with all the helper options. They are implementation-agnostic, as long as you consider `openssl` and `certutil` the only implementations :-) But I don't think this solution scales well to other possible implementations. Anyway, my main grudge is that the transformation rules shouldn't really be stored on and processed by the server. The server should know the *what* (mapping rules), but not the *how* (transformation rules). The *how* is an implementation detail and does not change in time, so there's no benefit in handling it on the server. It should be handled exclusively on the client, which I believe would also make the whole thing more robust (it would not be possible for a bug on the server to break all the clients). This is a good point. However, for the scope of Ben's project can we limit it by openssl and certutil support? Otherwise Ben wouldn't be able to complete the project in time. I'm fine with that, but I don't think it's up to me :-) This is turning out to be a common (and, I think, reasonable) reaction to the proposal. It is rather complex, and I worry that it will be difficult to configure. On the other hand, there is some hidden complexity to enabling a simpler config format, as well. One of the goals of the project as it was presented to me was to allow the creation of profiles that add certificate extensions *that FreeIPA doesn't yet know about*. With the current proposal, one only has to add a rule generating text that the helper will
Re: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation
On 27.8.2016 22:40, Ben Lipton wrote: On 08/25/2016 04:11 PM, Rob Crittenden wrote: Ben Lipton wrote: On 08/23/2016 03:54 AM, Jan Cholasta wrote: On 8.8.2016 22:23, Ben Lipton wrote: On 07/25/2016 07:45 AM, Jan Cholasta wrote: On 25.7.2016 13:11, Alexander Bokovoy wrote: On Mon, 25 Jul 2016, Jan Cholasta wrote: On 20.7.2016 16:05, Ben Lipton wrote: Hi, Thanks very much for the feedback! Some responses below; I hope you'll let me know what you think of my reasoning. On 07/20/2016 04:20 AM, Jan Cholasta wrote: Hi, On 17.6.2016 00:06, Ben Lipton wrote: On 06/14/2016 08:27 AM, Ben Lipton wrote: Hello all, I have written up a design proposal for making certificate requests easier to generate when using alternate certificate profiles: http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation. The use case for this is described in https://fedorahosted.org/freeipa/ticket/4899. I will be working on implementing this design over the next couple of months. If you have the time and interest, please take a look and share any comments or concerns that you have. Thanks! Ben Just a quick update to say that I've created a new document that covers the proposed schema additions in a more descriptive way (with diagrams!) I'm very new to developing with LDAP, so some more experienced eyes on the proposal would be very helpful, even if you don't have time to absorb the full design. Please take a look at http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Schema if you have a chance. I finally had a chance to take a look at this, here are some comments: 1) I don't like how transformation rules are tied to a particular helper and have to be duplicated for each of them. They should be generic and work with any helper, as helpers are just an implementation detail and their resulting data is the same. In fact, I think I would prefer if the CSR was generated using python-cryptography's CertificateSigningRequestBuilder [1] rather than openssl or certutil or any other command line tool. There are lots of tools that users might want to use to manage their private keys, so I don't know if we can assume that whatever library we prefer will actually be able to access the private key to sign a CSR, which is why I thought it would be useful to support more than one. python-cryptography has the notion of backends, which allow it to support multiple crypto implementations. Upstream it currently supports only OpenSSL [2], but some work has been done on PKCS#11 backend [3], which provides support for HSMs and soft-tokens (like NSS databases). Alternatively, for NSS databases (and other "simple" cases), you can generate the private key with python-cryptography using the default backend, export it to a file and import the file to the target database, so you don't actually need the PKCS#11 backend for them. So, the only thing that's currently lacking is HSM support, but given that we don't support HSMs in IPA nor in certmonger, I don't think it's an issue for now. The purpose of the mapping rule is to tie together the transformation rules that produce the same data into an object that's implementation-agnostic, so that profiles referencing those rules are automatically compatible with all the helper options. They are implementation-agnostic, as long as you consider `openssl` and `certutil` the only implementations :-) But I don't think this solution scales well to other possible implementations. Anyway, my main grudge is that the transformation rules shouldn't really be stored on and processed by the server. The server should know the *what* (mapping rules), but not the *how* (transformation rules). The *how* is an implementation detail and does not change in time, so there's no benefit in handling it on the server. It should be handled exclusively on the client, which I believe would also make the whole thing more robust (it would not be possible for a bug on the server to break all the clients). This is a good point. However, for the scope of Ben's project can we limit it by openssl and certutil support? Otherwise Ben wouldn't be able to complete the project in time. I'm fine with that, but I don't think it's up to me :-) This is turning out to be a common (and, I think, reasonable) reaction to the proposal. It is rather complex, and I worry that it will be difficult to configure. On the other hand, there is some hidden complexity to enabling a simpler config format, as well. One of the goals of the project as it was presented to me was to allow the creation of profiles that add certificate extensions *that FreeIPA doesn't yet know about*. With the current proposal, one only has to add a rule generating text that the helper will understand. ... which will be possible only as long as the helper understands the extension. Which it might not, thus the current proposal works only for *some* extensions that FreeIPA doesn't yet support. We can go ad infinitum
Re: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation
On 08/25/2016 04:11 PM, Rob Crittenden wrote: Ben Lipton wrote: On 08/23/2016 03:54 AM, Jan Cholasta wrote: On 8.8.2016 22:23, Ben Lipton wrote: On 07/25/2016 07:45 AM, Jan Cholasta wrote: On 25.7.2016 13:11, Alexander Bokovoy wrote: On Mon, 25 Jul 2016, Jan Cholasta wrote: On 20.7.2016 16:05, Ben Lipton wrote: Hi, Thanks very much for the feedback! Some responses below; I hope you'll let me know what you think of my reasoning. On 07/20/2016 04:20 AM, Jan Cholasta wrote: Hi, On 17.6.2016 00:06, Ben Lipton wrote: On 06/14/2016 08:27 AM, Ben Lipton wrote: Hello all, I have written up a design proposal for making certificate requests easier to generate when using alternate certificate profiles: http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation. The use case for this is described in https://fedorahosted.org/freeipa/ticket/4899. I will be working on implementing this design over the next couple of months. If you have the time and interest, please take a look and share any comments or concerns that you have. Thanks! Ben Just a quick update to say that I've created a new document that covers the proposed schema additions in a more descriptive way (with diagrams!) I'm very new to developing with LDAP, so some more experienced eyes on the proposal would be very helpful, even if you don't have time to absorb the full design. Please take a look at http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Schema if you have a chance. I finally had a chance to take a look at this, here are some comments: 1) I don't like how transformation rules are tied to a particular helper and have to be duplicated for each of them. They should be generic and work with any helper, as helpers are just an implementation detail and their resulting data is the same. In fact, I think I would prefer if the CSR was generated using python-cryptography's CertificateSigningRequestBuilder [1] rather than openssl or certutil or any other command line tool. There are lots of tools that users might want to use to manage their private keys, so I don't know if we can assume that whatever library we prefer will actually be able to access the private key to sign a CSR, which is why I thought it would be useful to support more than one. python-cryptography has the notion of backends, which allow it to support multiple crypto implementations. Upstream it currently supports only OpenSSL [2], but some work has been done on PKCS#11 backend [3], which provides support for HSMs and soft-tokens (like NSS databases). Alternatively, for NSS databases (and other "simple" cases), you can generate the private key with python-cryptography using the default backend, export it to a file and import the file to the target database, so you don't actually need the PKCS#11 backend for them. So, the only thing that's currently lacking is HSM support, but given that we don't support HSMs in IPA nor in certmonger, I don't think it's an issue for now. The purpose of the mapping rule is to tie together the transformation rules that produce the same data into an object that's implementation-agnostic, so that profiles referencing those rules are automatically compatible with all the helper options. They are implementation-agnostic, as long as you consider `openssl` and `certutil` the only implementations :-) But I don't think this solution scales well to other possible implementations. Anyway, my main grudge is that the transformation rules shouldn't really be stored on and processed by the server. The server should know the *what* (mapping rules), but not the *how* (transformation rules). The *how* is an implementation detail and does not change in time, so there's no benefit in handling it on the server. It should be handled exclusively on the client, which I believe would also make the whole thing more robust (it would not be possible for a bug on the server to break all the clients). This is a good point. However, for the scope of Ben's project can we limit it by openssl and certutil support? Otherwise Ben wouldn't be able to complete the project in time. I'm fine with that, but I don't think it's up to me :-) This is turning out to be a common (and, I think, reasonable) reaction to the proposal. It is rather complex, and I worry that it will be difficult to configure. On the other hand, there is some hidden complexity to enabling a simpler config format, as well. One of the goals of the project as it was presented to me was to allow the creation of profiles that add certificate extensions *that FreeIPA doesn't yet know about*. With the current proposal, one only has to add a rule generating text that the helper will understand. ... which will be possible only as long as the helper understands the extension. Which it might not, thus the current proposal works only for *some* extensions that FreeIPA doesn't yet support. We can go ad infinitum here but with any helper
Re: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation
Ben Lipton wrote: On 08/23/2016 03:54 AM, Jan Cholasta wrote: On 8.8.2016 22:23, Ben Lipton wrote: On 07/25/2016 07:45 AM, Jan Cholasta wrote: On 25.7.2016 13:11, Alexander Bokovoy wrote: On Mon, 25 Jul 2016, Jan Cholasta wrote: On 20.7.2016 16:05, Ben Lipton wrote: Hi, Thanks very much for the feedback! Some responses below; I hope you'll let me know what you think of my reasoning. On 07/20/2016 04:20 AM, Jan Cholasta wrote: Hi, On 17.6.2016 00:06, Ben Lipton wrote: On 06/14/2016 08:27 AM, Ben Lipton wrote: Hello all, I have written up a design proposal for making certificate requests easier to generate when using alternate certificate profiles: http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation. The use case for this is described in https://fedorahosted.org/freeipa/ticket/4899. I will be working on implementing this design over the next couple of months. If you have the time and interest, please take a look and share any comments or concerns that you have. Thanks! Ben Just a quick update to say that I've created a new document that covers the proposed schema additions in a more descriptive way (with diagrams!) I'm very new to developing with LDAP, so some more experienced eyes on the proposal would be very helpful, even if you don't have time to absorb the full design. Please take a look at http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Schema if you have a chance. I finally had a chance to take a look at this, here are some comments: 1) I don't like how transformation rules are tied to a particular helper and have to be duplicated for each of them. They should be generic and work with any helper, as helpers are just an implementation detail and their resulting data is the same. In fact, I think I would prefer if the CSR was generated using python-cryptography's CertificateSigningRequestBuilder [1] rather than openssl or certutil or any other command line tool. There are lots of tools that users might want to use to manage their private keys, so I don't know if we can assume that whatever library we prefer will actually be able to access the private key to sign a CSR, which is why I thought it would be useful to support more than one. python-cryptography has the notion of backends, which allow it to support multiple crypto implementations. Upstream it currently supports only OpenSSL [2], but some work has been done on PKCS#11 backend [3], which provides support for HSMs and soft-tokens (like NSS databases). Alternatively, for NSS databases (and other "simple" cases), you can generate the private key with python-cryptography using the default backend, export it to a file and import the file to the target database, so you don't actually need the PKCS#11 backend for them. So, the only thing that's currently lacking is HSM support, but given that we don't support HSMs in IPA nor in certmonger, I don't think it's an issue for now. The purpose of the mapping rule is to tie together the transformation rules that produce the same data into an object that's implementation-agnostic, so that profiles referencing those rules are automatically compatible with all the helper options. They are implementation-agnostic, as long as you consider `openssl` and `certutil` the only implementations :-) But I don't think this solution scales well to other possible implementations. Anyway, my main grudge is that the transformation rules shouldn't really be stored on and processed by the server. The server should know the *what* (mapping rules), but not the *how* (transformation rules). The *how* is an implementation detail and does not change in time, so there's no benefit in handling it on the server. It should be handled exclusively on the client, which I believe would also make the whole thing more robust (it would not be possible for a bug on the server to break all the clients). This is a good point. However, for the scope of Ben's project can we limit it by openssl and certutil support? Otherwise Ben wouldn't be able to complete the project in time. I'm fine with that, but I don't think it's up to me :-) This is turning out to be a common (and, I think, reasonable) reaction to the proposal. It is rather complex, and I worry that it will be difficult to configure. On the other hand, there is some hidden complexity to enabling a simpler config format, as well. One of the goals of the project as it was presented to me was to allow the creation of profiles that add certificate extensions *that FreeIPA doesn't yet know about*. With the current proposal, one only has to add a rule generating text that the helper will understand. ... which will be possible only as long as the helper understands the extension. Which it might not, thus the current proposal works only for *some* extensions that FreeIPA doesn't yet support. We can go ad infinitum here but with any helper implementation, be it python-cryptography or anything else, you
Re: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation
On 08/23/2016 03:54 AM, Jan Cholasta wrote: On 8.8.2016 22:23, Ben Lipton wrote: On 07/25/2016 07:45 AM, Jan Cholasta wrote: On 25.7.2016 13:11, Alexander Bokovoy wrote: On Mon, 25 Jul 2016, Jan Cholasta wrote: On 20.7.2016 16:05, Ben Lipton wrote: Hi, Thanks very much for the feedback! Some responses below; I hope you'll let me know what you think of my reasoning. On 07/20/2016 04:20 AM, Jan Cholasta wrote: Hi, On 17.6.2016 00:06, Ben Lipton wrote: On 06/14/2016 08:27 AM, Ben Lipton wrote: Hello all, I have written up a design proposal for making certificate requests easier to generate when using alternate certificate profiles: http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation. The use case for this is described in https://fedorahosted.org/freeipa/ticket/4899. I will be working on implementing this design over the next couple of months. If you have the time and interest, please take a look and share any comments or concerns that you have. Thanks! Ben Just a quick update to say that I've created a new document that covers the proposed schema additions in a more descriptive way (with diagrams!) I'm very new to developing with LDAP, so some more experienced eyes on the proposal would be very helpful, even if you don't have time to absorb the full design. Please take a look at http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Schema if you have a chance. I finally had a chance to take a look at this, here are some comments: 1) I don't like how transformation rules are tied to a particular helper and have to be duplicated for each of them. They should be generic and work with any helper, as helpers are just an implementation detail and their resulting data is the same. In fact, I think I would prefer if the CSR was generated using python-cryptography's CertificateSigningRequestBuilder [1] rather than openssl or certutil or any other command line tool. There are lots of tools that users might want to use to manage their private keys, so I don't know if we can assume that whatever library we prefer will actually be able to access the private key to sign a CSR, which is why I thought it would be useful to support more than one. python-cryptography has the notion of backends, which allow it to support multiple crypto implementations. Upstream it currently supports only OpenSSL [2], but some work has been done on PKCS#11 backend [3], which provides support for HSMs and soft-tokens (like NSS databases). Alternatively, for NSS databases (and other "simple" cases), you can generate the private key with python-cryptography using the default backend, export it to a file and import the file to the target database, so you don't actually need the PKCS#11 backend for them. So, the only thing that's currently lacking is HSM support, but given that we don't support HSMs in IPA nor in certmonger, I don't think it's an issue for now. The purpose of the mapping rule is to tie together the transformation rules that produce the same data into an object that's implementation-agnostic, so that profiles referencing those rules are automatically compatible with all the helper options. They are implementation-agnostic, as long as you consider `openssl` and `certutil` the only implementations :-) But I don't think this solution scales well to other possible implementations. Anyway, my main grudge is that the transformation rules shouldn't really be stored on and processed by the server. The server should know the *what* (mapping rules), but not the *how* (transformation rules). The *how* is an implementation detail and does not change in time, so there's no benefit in handling it on the server. It should be handled exclusively on the client, which I believe would also make the whole thing more robust (it would not be possible for a bug on the server to break all the clients). This is a good point. However, for the scope of Ben's project can we limit it by openssl and certutil support? Otherwise Ben wouldn't be able to complete the project in time. I'm fine with that, but I don't think it's up to me :-) This is turning out to be a common (and, I think, reasonable) reaction to the proposal. It is rather complex, and I worry that it will be difficult to configure. On the other hand, there is some hidden complexity to enabling a simpler config format, as well. One of the goals of the project as it was presented to me was to allow the creation of profiles that add certificate extensions *that FreeIPA doesn't yet know about*. With the current proposal, one only has to add a rule generating text that the helper will understand. ... which will be possible only as long as the helper understands the extension. Which it might not, thus the current proposal works only for *some* extensions that FreeIPA doesn't yet support. We can go ad infinitum here but with any helper implementation, be it python-cryptography or anything
Re: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation
On 8.8.2016 22:23, Ben Lipton wrote: On 07/25/2016 07:45 AM, Jan Cholasta wrote: On 25.7.2016 13:11, Alexander Bokovoy wrote: On Mon, 25 Jul 2016, Jan Cholasta wrote: On 20.7.2016 16:05, Ben Lipton wrote: Hi, Thanks very much for the feedback! Some responses below; I hope you'll let me know what you think of my reasoning. On 07/20/2016 04:20 AM, Jan Cholasta wrote: Hi, On 17.6.2016 00:06, Ben Lipton wrote: On 06/14/2016 08:27 AM, Ben Lipton wrote: Hello all, I have written up a design proposal for making certificate requests easier to generate when using alternate certificate profiles: http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation. The use case for this is described in https://fedorahosted.org/freeipa/ticket/4899. I will be working on implementing this design over the next couple of months. If you have the time and interest, please take a look and share any comments or concerns that you have. Thanks! Ben Just a quick update to say that I've created a new document that covers the proposed schema additions in a more descriptive way (with diagrams!) I'm very new to developing with LDAP, so some more experienced eyes on the proposal would be very helpful, even if you don't have time to absorb the full design. Please take a look at http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Schema if you have a chance. I finally had a chance to take a look at this, here are some comments: 1) I don't like how transformation rules are tied to a particular helper and have to be duplicated for each of them. They should be generic and work with any helper, as helpers are just an implementation detail and their resulting data is the same. In fact, I think I would prefer if the CSR was generated using python-cryptography's CertificateSigningRequestBuilder [1] rather than openssl or certutil or any other command line tool. There are lots of tools that users might want to use to manage their private keys, so I don't know if we can assume that whatever library we prefer will actually be able to access the private key to sign a CSR, which is why I thought it would be useful to support more than one. python-cryptography has the notion of backends, which allow it to support multiple crypto implementations. Upstream it currently supports only OpenSSL [2], but some work has been done on PKCS#11 backend [3], which provides support for HSMs and soft-tokens (like NSS databases). Alternatively, for NSS databases (and other "simple" cases), you can generate the private key with python-cryptography using the default backend, export it to a file and import the file to the target database, so you don't actually need the PKCS#11 backend for them. So, the only thing that's currently lacking is HSM support, but given that we don't support HSMs in IPA nor in certmonger, I don't think it's an issue for now. The purpose of the mapping rule is to tie together the transformation rules that produce the same data into an object that's implementation-agnostic, so that profiles referencing those rules are automatically compatible with all the helper options. They are implementation-agnostic, as long as you consider `openssl` and `certutil` the only implementations :-) But I don't think this solution scales well to other possible implementations. Anyway, my main grudge is that the transformation rules shouldn't really be stored on and processed by the server. The server should know the *what* (mapping rules), but not the *how* (transformation rules). The *how* is an implementation detail and does not change in time, so there's no benefit in handling it on the server. It should be handled exclusively on the client, which I believe would also make the whole thing more robust (it would not be possible for a bug on the server to break all the clients). This is a good point. However, for the scope of Ben's project can we limit it by openssl and certutil support? Otherwise Ben wouldn't be able to complete the project in time. I'm fine with that, but I don't think it's up to me :-) This is turning out to be a common (and, I think, reasonable) reaction to the proposal. It is rather complex, and I worry that it will be difficult to configure. On the other hand, there is some hidden complexity to enabling a simpler config format, as well. One of the goals of the project as it was presented to me was to allow the creation of profiles that add certificate extensions *that FreeIPA doesn't yet know about*. With the current proposal, one only has to add a rule generating text that the helper will understand. ... which will be possible only as long as the helper understands the extension. Which it might not, thus the current proposal works only for *some* extensions that FreeIPA doesn't yet support. We can go ad infinitum here but with any helper implementation, be it python-cryptography or anything else, you will need to have a support there as well. My point was that the
Re: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation
On 07/25/2016 07:45 AM, Jan Cholasta wrote: On 25.7.2016 13:11, Alexander Bokovoy wrote: On Mon, 25 Jul 2016, Jan Cholasta wrote: On 20.7.2016 16:05, Ben Lipton wrote: Hi, Thanks very much for the feedback! Some responses below; I hope you'll let me know what you think of my reasoning. On 07/20/2016 04:20 AM, Jan Cholasta wrote: Hi, On 17.6.2016 00:06, Ben Lipton wrote: On 06/14/2016 08:27 AM, Ben Lipton wrote: Hello all, I have written up a design proposal for making certificate requests easier to generate when using alternate certificate profiles: http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation. The use case for this is described in https://fedorahosted.org/freeipa/ticket/4899. I will be working on implementing this design over the next couple of months. If you have the time and interest, please take a look and share any comments or concerns that you have. Thanks! Ben Just a quick update to say that I've created a new document that covers the proposed schema additions in a more descriptive way (with diagrams!) I'm very new to developing with LDAP, so some more experienced eyes on the proposal would be very helpful, even if you don't have time to absorb the full design. Please take a look at http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Schema if you have a chance. I finally had a chance to take a look at this, here are some comments: 1) I don't like how transformation rules are tied to a particular helper and have to be duplicated for each of them. They should be generic and work with any helper, as helpers are just an implementation detail and their resulting data is the same. In fact, I think I would prefer if the CSR was generated using python-cryptography's CertificateSigningRequestBuilder [1] rather than openssl or certutil or any other command line tool. There are lots of tools that users might want to use to manage their private keys, so I don't know if we can assume that whatever library we prefer will actually be able to access the private key to sign a CSR, which is why I thought it would be useful to support more than one. python-cryptography has the notion of backends, which allow it to support multiple crypto implementations. Upstream it currently supports only OpenSSL [2], but some work has been done on PKCS#11 backend [3], which provides support for HSMs and soft-tokens (like NSS databases). Alternatively, for NSS databases (and other "simple" cases), you can generate the private key with python-cryptography using the default backend, export it to a file and import the file to the target database, so you don't actually need the PKCS#11 backend for them. So, the only thing that's currently lacking is HSM support, but given that we don't support HSMs in IPA nor in certmonger, I don't think it's an issue for now. The purpose of the mapping rule is to tie together the transformation rules that produce the same data into an object that's implementation-agnostic, so that profiles referencing those rules are automatically compatible with all the helper options. They are implementation-agnostic, as long as you consider `openssl` and `certutil` the only implementations :-) But I don't think this solution scales well to other possible implementations. Anyway, my main grudge is that the transformation rules shouldn't really be stored on and processed by the server. The server should know the *what* (mapping rules), but not the *how* (transformation rules). The *how* is an implementation detail and does not change in time, so there's no benefit in handling it on the server. It should be handled exclusively on the client, which I believe would also make the whole thing more robust (it would not be possible for a bug on the server to break all the clients). This is a good point. However, for the scope of Ben's project can we limit it by openssl and certutil support? Otherwise Ben wouldn't be able to complete the project in time. I'm fine with that, but I don't think it's up to me :-) This is turning out to be a common (and, I think, reasonable) reaction to the proposal. It is rather complex, and I worry that it will be difficult to configure. On the other hand, there is some hidden complexity to enabling a simpler config format, as well. One of the goals of the project as it was presented to me was to allow the creation of profiles that add certificate extensions *that FreeIPA doesn't yet know about*. With the current proposal, one only has to add a rule generating text that the helper will understand. ... which will be possible only as long as the helper understands the extension. Which it might not, thus the current proposal works only for *some* extensions that FreeIPA doesn't yet support. We can go ad infinitum here but with any helper implementation, be it python-cryptography or anything else, you will need to have a support there as well. My point was that the current proposal is
Re: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation
Simo Sorce wrote: On Mon, 2016-07-25 at 18:05 +0300, Alexander Bokovoy wrote: But maybe I'm not seeing the proper priorities here. Perhaps it's more of a problem because clients are easier to update with bugfixes than the server? Or maybe the preference for the client is for scalability reasons? Could you tell me more about why you prefer a client implementation? Making client responsible for generating the certificate signing request serves several purposes where privacy is one of main benefits: access to private key stays at the client side. I would definitely veto any scheme where the client must send the private key to the server. I thought the server would generate the CSR, but then it would be sent to the client for signing ? I doubt any SSL library will let you disconnect CSR generation in this way (fairly certain not in NSS anyway). rob -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation
On Mon, 25 Jul 2016, Simo Sorce wrote: On Mon, 2016-07-25 at 12:13 -0400, Ben Lipton wrote: On 07/25/2016 11:07 AM, Simo Sorce wrote: > On Mon, 2016-07-25 at 11:04 -0400, Simo Sorce wrote: >> On Mon, 2016-07-25 at 10:51 -0400, Ben Lipton wrote: >>> On 07/25/2016 05:07 AM, Simo Sorce wrote: On Mon, 2016-07-25 at 10:50 +0200, Jan Cholasta wrote: > Anyway, my main grudge is that the transformation rules shouldn't > really > be stored on and processed by the server. The server should know the > *what* (mapping rules), but not the *how* (transformation rules). The > *how* is an implementation detail and does not change in time, so > there's no benefit in handling it on the server. It should be handled > exclusively on the client, which I believe would also make the whole > thing more robust (it would not be possible for a bug on the server > to > break all the clients). W/o entering in specific +1 as a general comment on this. If it can be done on the client, probably better be done there. Simo. >>> My thinking was that while the CSR generation must be done on the >>> client, the retrieval and formatting of the data for the CSR should be >>> done on the server, so that the functionality is available to all >>> consumers of the API (ipa command-line, certmonger, Web UI, something >>> else?). I imagine it would be relatively easy to move the formatting >>> stuff into the ipa CLI, but all the other clients would then need an >>> implementation of their own, and so we'd need to worry about >>> interpreting the templates and generating CSRs in multiple different >>> languages. It's true that as it stands a bug on the server could break >>> all the clients, but on the other hand there's only one implementation >>> to maintain, rather than a different one in each client. >>> >>> But maybe I'm not seeing the proper priorities here. Perhaps it's more >>> of a problem because clients are easier to update with bugfixes than the >>> server? Or maybe the preference for the client is for scalability >>> reasons? Could you tell me more about why you prefer a client >>> implementation? >>> >>> (And yeah, everything here carries a disclaimer of "I probably can't >>> make any large changes in the remaining 3 weeks of my internship," but I >>> think it's still good to know and document what the limitations of the >>> current implementation are.) >>> >>> Thanks, >>> Ben >> You do not want to have to upgrade the server because tool foobarx >> became suddenly the most used. Client tools may change over the time as >> well, so if you try to generate stuff on the server you may end up >> having to support multiple version with little way of knowing which >> version that is. >> >> It is true that multiple client would have to implement "something", but >> that something could be a python library+binary that other tools/script >> can call or pipe through as needed. > Note, from my pov the code should be more or less the same except it > would run on the client rather than the server. Templates would be > delivered via the same package that delivers the tool/module and admins > would have the option to add more locally, though I am not against > sharing templates via the server if we think that is a good idea in > general (but the same issue vs tools changing and rendering templates > broken with one or another version remain). > > Simo. > Ok, I definitely see your point here about making it easier to support the shifting versions of the helper utilities. Pulling the formatting out into a standalone binary that could be used by different clients seems achievable. The Web UI wouldn't be able to use it, I guess, but as of now there's no web UI for this feature anyway. I'll make sure this is at least documented as a desirable modification. Note, that the same tool *could* be used server side in the UI, should it be desirable. That was what I commented on -- IPA server is IPA client too, so it can make all the work locally and provide resulted bundle to download. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation
On Mon, 25 Jul 2016, Simo Sorce wrote: On Mon, 2016-07-25 at 12:09 -0400, Ben Lipton wrote: On 07/25/2016 12:03 PM, Simo Sorce wrote: > On Mon, 2016-07-25 at 18:05 +0300, Alexander Bokovoy wrote: >>> But maybe I'm not seeing the proper priorities here. Perhaps it's >> more >>> of a problem because clients are easier to update with bugfixes than >>> the server? Or maybe the preference for the client is for >> scalability >>> reasons? Could you tell me more about why you prefer a client >>> implementation? >> Making client responsible for generating the certificate signing >> request serves several purposes where privacy is one of main benefits: >> access to private key stays at the client side. > I would definitely veto any scheme where the client must send the > private key to the server. I thought the server would generate the CSR, > but then it would be sent to the client for signing ? > > Simo. > The server generates the data and formats it for the helper tool. The helper runs on the client and generates the CSR, with signature. I don't think we were considering signing anything server-side; in this thread I was referring to whether the data should be requested and formatted on the server or client side. This was my understanding as well, but Alexander's comment startled me, thanks for confirming. Correct. I was commenting by also taking into account current Fedora situation where your certificate is generated on the server and that it needs to be provided as well if we want Fedora to use FreeIPA as a replacement for some of their infrastructure. However, this has nothing to do with CSR generation as that mode can be simulated on IPA server locally if really needed (again, because IPA server is own client, so it has access to all the client infra). -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation
On Mon, 2016-07-25 at 12:13 -0400, Ben Lipton wrote: > On 07/25/2016 11:07 AM, Simo Sorce wrote: > > On Mon, 2016-07-25 at 11:04 -0400, Simo Sorce wrote: > >> On Mon, 2016-07-25 at 10:51 -0400, Ben Lipton wrote: > >>> On 07/25/2016 05:07 AM, Simo Sorce wrote: > On Mon, 2016-07-25 at 10:50 +0200, Jan Cholasta wrote: > > Anyway, my main grudge is that the transformation rules shouldn't > > really > > be stored on and processed by the server. The server should know the > > *what* (mapping rules), but not the *how* (transformation rules). The > > *how* is an implementation detail and does not change in time, so > > there's no benefit in handling it on the server. It should be handled > > exclusively on the client, which I believe would also make the whole > > thing more robust (it would not be possible for a bug on the server > > to > > break all the clients). > W/o entering in specific +1 as a general comment on this. > If it can be done on the client, probably better be done there. > > Simo. > > >>> My thinking was that while the CSR generation must be done on the > >>> client, the retrieval and formatting of the data for the CSR should be > >>> done on the server, so that the functionality is available to all > >>> consumers of the API (ipa command-line, certmonger, Web UI, something > >>> else?). I imagine it would be relatively easy to move the formatting > >>> stuff into the ipa CLI, but all the other clients would then need an > >>> implementation of their own, and so we'd need to worry about > >>> interpreting the templates and generating CSRs in multiple different > >>> languages. It's true that as it stands a bug on the server could break > >>> all the clients, but on the other hand there's only one implementation > >>> to maintain, rather than a different one in each client. > >>> > >>> But maybe I'm not seeing the proper priorities here. Perhaps it's more > >>> of a problem because clients are easier to update with bugfixes than the > >>> server? Or maybe the preference for the client is for scalability > >>> reasons? Could you tell me more about why you prefer a client > >>> implementation? > >>> > >>> (And yeah, everything here carries a disclaimer of "I probably can't > >>> make any large changes in the remaining 3 weeks of my internship," but I > >>> think it's still good to know and document what the limitations of the > >>> current implementation are.) > >>> > >>> Thanks, > >>> Ben > >> You do not want to have to upgrade the server because tool foobarx > >> became suddenly the most used. Client tools may change over the time as > >> well, so if you try to generate stuff on the server you may end up > >> having to support multiple version with little way of knowing which > >> version that is. > >> > >> It is true that multiple client would have to implement "something", but > >> that something could be a python library+binary that other tools/script > >> can call or pipe through as needed. > > Note, from my pov the code should be more or less the same except it > > would run on the client rather than the server. Templates would be > > delivered via the same package that delivers the tool/module and admins > > would have the option to add more locally, though I am not against > > sharing templates via the server if we think that is a good idea in > > general (but the same issue vs tools changing and rendering templates > > broken with one or another version remain). > > > > Simo. > > > Ok, I definitely see your point here about making it easier to support > the shifting versions of the helper utilities. Pulling the formatting > out into a standalone binary that could be used by different clients > seems achievable. The Web UI wouldn't be able to use it, I guess, but as > of now there's no web UI for this feature anyway. I'll make sure this is > at least documented as a desirable modification. Note, that the same tool *could* be used server side in the UI, should it be desirable. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation
On Mon, 2016-07-25 at 12:09 -0400, Ben Lipton wrote: > On 07/25/2016 12:03 PM, Simo Sorce wrote: > > On Mon, 2016-07-25 at 18:05 +0300, Alexander Bokovoy wrote: > >>> But maybe I'm not seeing the proper priorities here. Perhaps it's > >> more > >>> of a problem because clients are easier to update with bugfixes than > >>> the server? Or maybe the preference for the client is for > >> scalability > >>> reasons? Could you tell me more about why you prefer a client > >>> implementation? > >> Making client responsible for generating the certificate signing > >> request serves several purposes where privacy is one of main benefits: > >> access to private key stays at the client side. > > I would definitely veto any scheme where the client must send the > > private key to the server. I thought the server would generate the CSR, > > but then it would be sent to the client for signing ? > > > > Simo. > > > The server generates the data and formats it for the helper tool. The > helper runs on the client and generates the CSR, with signature. I don't > think we were considering signing anything server-side; in this thread I > was referring to whether the data should be requested and formatted on > the server or client side. This was my understanding as well, but Alexander's comment startled me, thanks for confirming. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation
On 07/25/2016 11:07 AM, Simo Sorce wrote: On Mon, 2016-07-25 at 11:04 -0400, Simo Sorce wrote: On Mon, 2016-07-25 at 10:51 -0400, Ben Lipton wrote: On 07/25/2016 05:07 AM, Simo Sorce wrote: On Mon, 2016-07-25 at 10:50 +0200, Jan Cholasta wrote: Anyway, my main grudge is that the transformation rules shouldn't really be stored on and processed by the server. The server should know the *what* (mapping rules), but not the *how* (transformation rules). The *how* is an implementation detail and does not change in time, so there's no benefit in handling it on the server. It should be handled exclusively on the client, which I believe would also make the whole thing more robust (it would not be possible for a bug on the server to break all the clients). W/o entering in specific +1 as a general comment on this. If it can be done on the client, probably better be done there. Simo. My thinking was that while the CSR generation must be done on the client, the retrieval and formatting of the data for the CSR should be done on the server, so that the functionality is available to all consumers of the API (ipa command-line, certmonger, Web UI, something else?). I imagine it would be relatively easy to move the formatting stuff into the ipa CLI, but all the other clients would then need an implementation of their own, and so we'd need to worry about interpreting the templates and generating CSRs in multiple different languages. It's true that as it stands a bug on the server could break all the clients, but on the other hand there's only one implementation to maintain, rather than a different one in each client. But maybe I'm not seeing the proper priorities here. Perhaps it's more of a problem because clients are easier to update with bugfixes than the server? Or maybe the preference for the client is for scalability reasons? Could you tell me more about why you prefer a client implementation? (And yeah, everything here carries a disclaimer of "I probably can't make any large changes in the remaining 3 weeks of my internship," but I think it's still good to know and document what the limitations of the current implementation are.) Thanks, Ben You do not want to have to upgrade the server because tool foobarx became suddenly the most used. Client tools may change over the time as well, so if you try to generate stuff on the server you may end up having to support multiple version with little way of knowing which version that is. It is true that multiple client would have to implement "something", but that something could be a python library+binary that other tools/script can call or pipe through as needed. Note, from my pov the code should be more or less the same except it would run on the client rather than the server. Templates would be delivered via the same package that delivers the tool/module and admins would have the option to add more locally, though I am not against sharing templates via the server if we think that is a good idea in general (but the same issue vs tools changing and rendering templates broken with one or another version remain). Simo. Ok, I definitely see your point here about making it easier to support the shifting versions of the helper utilities. Pulling the formatting out into a standalone binary that could be used by different clients seems achievable. The Web UI wouldn't be able to use it, I guess, but as of now there's no web UI for this feature anyway. I'll make sure this is at least documented as a desirable modification. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation
On 07/25/2016 12:03 PM, Simo Sorce wrote: On Mon, 2016-07-25 at 18:05 +0300, Alexander Bokovoy wrote: But maybe I'm not seeing the proper priorities here. Perhaps it's more of a problem because clients are easier to update with bugfixes than the server? Or maybe the preference for the client is for scalability reasons? Could you tell me more about why you prefer a client implementation? Making client responsible for generating the certificate signing request serves several purposes where privacy is one of main benefits: access to private key stays at the client side. I would definitely veto any scheme where the client must send the private key to the server. I thought the server would generate the CSR, but then it would be sent to the client for signing ? Simo. The server generates the data and formats it for the helper tool. The helper runs on the client and generates the CSR, with signature. I don't think we were considering signing anything server-side; in this thread I was referring to whether the data should be requested and formatted on the server or client side. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation
On Mon, 2016-07-25 at 18:05 +0300, Alexander Bokovoy wrote: > >But maybe I'm not seeing the proper priorities here. Perhaps it's > more > >of a problem because clients are easier to update with bugfixes than > >the server? Or maybe the preference for the client is for > scalability > >reasons? Could you tell me more about why you prefer a client > >implementation? > Making client responsible for generating the certificate signing > request serves several purposes where privacy is one of main benefits: > access to private key stays at the client side. I would definitely veto any scheme where the client must send the private key to the server. I thought the server would generate the CSR, but then it would be sent to the client for signing ? Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation
On Mon, 2016-07-25 at 11:04 -0400, Simo Sorce wrote: > On Mon, 2016-07-25 at 10:51 -0400, Ben Lipton wrote: > > On 07/25/2016 05:07 AM, Simo Sorce wrote: > > > On Mon, 2016-07-25 at 10:50 +0200, Jan Cholasta wrote: > > >> Anyway, my main grudge is that the transformation rules shouldn't > > >> really > > >> be stored on and processed by the server. The server should know the > > >> *what* (mapping rules), but not the *how* (transformation rules). The > > >> *how* is an implementation detail and does not change in time, so > > >> there's no benefit in handling it on the server. It should be handled > > >> exclusively on the client, which I believe would also make the whole > > >> thing more robust (it would not be possible for a bug on the server > > >> to > > >> break all the clients). > > > W/o entering in specific +1 as a general comment on this. > > > If it can be done on the client, probably better be done there. > > > > > > Simo. > > > > > My thinking was that while the CSR generation must be done on the > > client, the retrieval and formatting of the data for the CSR should be > > done on the server, so that the functionality is available to all > > consumers of the API (ipa command-line, certmonger, Web UI, something > > else?). I imagine it would be relatively easy to move the formatting > > stuff into the ipa CLI, but all the other clients would then need an > > implementation of their own, and so we'd need to worry about > > interpreting the templates and generating CSRs in multiple different > > languages. It's true that as it stands a bug on the server could break > > all the clients, but on the other hand there's only one implementation > > to maintain, rather than a different one in each client. > > > > But maybe I'm not seeing the proper priorities here. Perhaps it's more > > of a problem because clients are easier to update with bugfixes than the > > server? Or maybe the preference for the client is for scalability > > reasons? Could you tell me more about why you prefer a client > > implementation? > > > > (And yeah, everything here carries a disclaimer of "I probably can't > > make any large changes in the remaining 3 weeks of my internship," but I > > think it's still good to know and document what the limitations of the > > current implementation are.) > > > > Thanks, > > Ben > > You do not want to have to upgrade the server because tool foobarx > became suddenly the most used. Client tools may change over the time as > well, so if you try to generate stuff on the server you may end up > having to support multiple version with little way of knowing which > version that is. > > It is true that multiple client would have to implement "something", but > that something could be a python library+binary that other tools/script > can call or pipe through as needed. Note, from my pov the code should be more or less the same except it would run on the client rather than the server. Templates would be delivered via the same package that delivers the tool/module and admins would have the option to add more locally, though I am not against sharing templates via the server if we think that is a good idea in general (but the same issue vs tools changing and rendering templates broken with one or another version remain). Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation
On Mon, 25 Jul 2016, Ben Lipton wrote: On 07/25/2016 05:07 AM, Simo Sorce wrote: On Mon, 2016-07-25 at 10:50 +0200, Jan Cholasta wrote: Anyway, my main grudge is that the transformation rules shouldn't really be stored on and processed by the server. The server should know the *what* (mapping rules), but not the *how* (transformation rules). The *how* is an implementation detail and does not change in time, so there's no benefit in handling it on the server. It should be handled exclusively on the client, which I believe would also make the whole thing more robust (it would not be possible for a bug on the server to break all the clients). W/o entering in specific +1 as a general comment on this. If it can be done on the client, probably better be done there. Simo. My thinking was that while the CSR generation must be done on the client, the retrieval and formatting of the data for the CSR should be done on the server, so that the functionality is available to all consumers of the API (ipa command-line, certmonger, Web UI, something else?). I imagine it would be relatively easy to move the formatting stuff into the ipa CLI, but all the other clients would then need an implementation of their own, and so we'd need to worry about interpreting the templates and generating CSRs in multiple different languages. It's true that as it stands a bug on the server could break all the clients, but on the other hand there's only one implementation to maintain, rather than a different one in each client. For other clients we would need to worry about CSR, not generating them. For them we *could* make use of the fact that IPA server is IPA client as well and provide some API to create CSR based on a pre-defined request type (e.g. don't support all CSR backends, just one, like python-cryptography). That wouldn't be too flexible but for flexibility we already accept CSRs generated by someone else. But maybe I'm not seeing the proper priorities here. Perhaps it's more of a problem because clients are easier to update with bugfixes than the server? Or maybe the preference for the client is for scalability reasons? Could you tell me more about why you prefer a client implementation? Making client responsible for generating the certificate signing request serves several purposes where privacy is one of main benefits: access to private key stays at the client side. (And yeah, everything here carries a disclaimer of "I probably can't make any large changes in the remaining 3 weeks of my internship," but I think it's still good to know and document what the limitations of the current implementation are.) Agreed. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation
On Mon, 2016-07-25 at 10:51 -0400, Ben Lipton wrote: > On 07/25/2016 05:07 AM, Simo Sorce wrote: > > On Mon, 2016-07-25 at 10:50 +0200, Jan Cholasta wrote: > >> Anyway, my main grudge is that the transformation rules shouldn't > >> really > >> be stored on and processed by the server. The server should know the > >> *what* (mapping rules), but not the *how* (transformation rules). The > >> *how* is an implementation detail and does not change in time, so > >> there's no benefit in handling it on the server. It should be handled > >> exclusively on the client, which I believe would also make the whole > >> thing more robust (it would not be possible for a bug on the server > >> to > >> break all the clients). > > W/o entering in specific +1 as a general comment on this. > > If it can be done on the client, probably better be done there. > > > > Simo. > > > My thinking was that while the CSR generation must be done on the > client, the retrieval and formatting of the data for the CSR should be > done on the server, so that the functionality is available to all > consumers of the API (ipa command-line, certmonger, Web UI, something > else?). I imagine it would be relatively easy to move the formatting > stuff into the ipa CLI, but all the other clients would then need an > implementation of their own, and so we'd need to worry about > interpreting the templates and generating CSRs in multiple different > languages. It's true that as it stands a bug on the server could break > all the clients, but on the other hand there's only one implementation > to maintain, rather than a different one in each client. > > But maybe I'm not seeing the proper priorities here. Perhaps it's more > of a problem because clients are easier to update with bugfixes than the > server? Or maybe the preference for the client is for scalability > reasons? Could you tell me more about why you prefer a client > implementation? > > (And yeah, everything here carries a disclaimer of "I probably can't > make any large changes in the remaining 3 weeks of my internship," but I > think it's still good to know and document what the limitations of the > current implementation are.) > > Thanks, > Ben You do not want to have to upgrade the server because tool foobarx became suddenly the most used. Client tools may change over the time as well, so if you try to generate stuff on the server you may end up having to support multiple version with little way of knowing which version that is. It is true that multiple client would have to implement "something", but that something could be a python library+binary that other tools/script can call or pipe through as needed. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation
On 07/25/2016 05:07 AM, Simo Sorce wrote: On Mon, 2016-07-25 at 10:50 +0200, Jan Cholasta wrote: Anyway, my main grudge is that the transformation rules shouldn't really be stored on and processed by the server. The server should know the *what* (mapping rules), but not the *how* (transformation rules). The *how* is an implementation detail and does not change in time, so there's no benefit in handling it on the server. It should be handled exclusively on the client, which I believe would also make the whole thing more robust (it would not be possible for a bug on the server to break all the clients). W/o entering in specific +1 as a general comment on this. If it can be done on the client, probably better be done there. Simo. My thinking was that while the CSR generation must be done on the client, the retrieval and formatting of the data for the CSR should be done on the server, so that the functionality is available to all consumers of the API (ipa command-line, certmonger, Web UI, something else?). I imagine it would be relatively easy to move the formatting stuff into the ipa CLI, but all the other clients would then need an implementation of their own, and so we'd need to worry about interpreting the templates and generating CSRs in multiple different languages. It's true that as it stands a bug on the server could break all the clients, but on the other hand there's only one implementation to maintain, rather than a different one in each client. But maybe I'm not seeing the proper priorities here. Perhaps it's more of a problem because clients are easier to update with bugfixes than the server? Or maybe the preference for the client is for scalability reasons? Could you tell me more about why you prefer a client implementation? (And yeah, everything here carries a disclaimer of "I probably can't make any large changes in the remaining 3 weeks of my internship," but I think it's still good to know and document what the limitations of the current implementation are.) Thanks, Ben -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation
On 07/25/2016 08:12 AM, Alexander Bokovoy wrote:
On Mon, 25 Jul 2016, Jan Cholasta wrote:
This is turning out to be a common (and, I think, reasonable)
reaction
to the proposal. It is rather complex, and I worry that it will be
difficult to configure. On the other hand, there is some hidden
complexity to enabling a simpler config format, as well. One of the
goals of the project as it was presented to me was to allow the
creation
of profiles that add certificate extensions *that FreeIPA doesn't yet
know about*. With the current proposal, one only has to add a rule
generating text that the helper will understand.
... which will be possible only as long as the helper understands the
extension. Which it might not, thus the current proposal works only
for *some* extensions that FreeIPA doesn't yet support.
We can go ad infinitum here but with any helper implementation, be it
python-cryptography or anything else, you will need to have a support
there as well.
My point was that the current proposal is not any better than my
proposal in this regard, as neither of them allows one to use an
arbitrary extension.
That's true. One of arguments for supporting openssl format was to allow
people to generate CSRs themselves later. E.g. it would be a stepping
stone to some automation around certificates to those who need it.
Turning everything into python-cryptography has less benefit in this
context.
The idea with unknown extensions was to allow mapping
their acceptance to a specific relationship between IPA objects
(optionally) and an input from the CSR. A simplest example would be an
identity rule that would copy an ASN.1 encoded content from the CSR to
the certificate.
That's on the mapping side, not on the CSR generation side, but it
would
go similarly for the CSR if you would be able to enter unknown but
otherwise correct ASN.1 stream. There is no difference at which helper
type we are talking about because all of them support inserting ASN.1
content.
Along similar lines, on the CSR generation side, certutil has an
--extGeneric flag, and openssl also has an "ARBITRARY EXTENSIONS"
feature described in x509v3_config(5). I'm guessing that generating
those configs automatically would be a bit beyond the current feature
set of jinja2, but when we allow the requester to specify contents for
some of the data fields it should be possible to build ok automation
around that.
With your suggestion,
if there's a mapping between "san_directoryname" and the
corresponding
API calls or configuration lines, we need some way for users to
augment
that mapping without changing the code. If there's no mapping, and
it's
just done with text processing, we need enough in the config
format to
be able to generate fairly complex structures:
builder = builder.subject_name(x509.Name(u'CN=user,O=EXAMPLE.COM'))
builder =
builder.add_extension(x509.SubjectAlternativeName([x509.RFC822Name(u'u...@example.com'),
x509.DirectoryName(x509.Name(u'CN=user,O=EXAMPLE.COM'))]), False)
and we need to do it without it being equivalent to calling eval() on
the config attributes. I'm not sure how to achieve this (is it
safe to
call getattr(x509, extensiontype)(value) where extensiontype and
value
are user-specified?) and it definitely would have to be tied to a
particular library/tool.
As I pointed out above, this needs to be figured out for the generic
case for both the current proposal and my suggestion.
OTOH, I think we could use GSER encoding of the extension value:
{ rfc822Name:"u...@example.com",
directoryName:rdnSequence:"CN=user,O=EXAMPLE.COM" }
GSER is not really used widely and does not have standardized encoding
rules beyond its own definition. If you want to allow transformation
rules in GSER that mention existing content in IPA objects, you would
need to deal with templating anyway. At this point it becomes
irrelevant
what you are templating, though.
True, but the goal here is not to avoid templating, but rather to
avoid implementation-specific bits on the server, and GSER is the
only thing that is textual, implementation-neutral and, as a bonus,
standardized.
If we move these bits to the client, the only thing server will need to
deal with is CSR. The client then would definitely need to have ability
to provide alternative CSR sources (e.g. openssl text format) to aid
API users that don't utilize IPA tools directly. At this point GSER use
is irrelevant either.
The GSER format is new to me, but I don't see any particular reason the
existing design would not be able to produce this format. But: is there
an existing library that allows creating a CSR from a GSER description?
If our goal is to provide an easy way to create certificates according
to a particular profile, and the CSR is still our main way to provide
that data to the IPA cert-request feature, we need to be able to build
that CSR. If we have a client that accepts GSER and has at least the CSR
generation features we need, then
Re: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation
On Mon, 25 Jul 2016, Jan Cholasta wrote:
This is turning out to be a common (and, I think, reasonable) reaction
to the proposal. It is rather complex, and I worry that it will be
difficult to configure. On the other hand, there is some hidden
complexity to enabling a simpler config format, as well. One of the
goals of the project as it was presented to me was to allow the creation
of profiles that add certificate extensions *that FreeIPA doesn't yet
know about*. With the current proposal, one only has to add a rule
generating text that the helper will understand.
... which will be possible only as long as the helper understands the
extension. Which it might not, thus the current proposal works only
for *some* extensions that FreeIPA doesn't yet support.
We can go ad infinitum here but with any helper implementation, be it
python-cryptography or anything else, you will need to have a support
there as well.
My point was that the current proposal is not any better than my
proposal in this regard, as neither of them allows one to use an
arbitrary extension.
That's true. One of arguments for supporting openssl format was to allow
people to generate CSRs themselves later. E.g. it would be a stepping
stone to some automation around certificates to those who need it.
Turning everything into python-cryptography has less benefit in this
context.
The idea with unknown extensions was to allow mapping
their acceptance to a specific relationship between IPA objects
(optionally) and an input from the CSR. A simplest example would be an
identity rule that would copy an ASN.1 encoded content from the CSR to
the certificate.
That's on the mapping side, not on the CSR generation side, but it would
go similarly for the CSR if you would be able to enter unknown but
otherwise correct ASN.1 stream. There is no difference at which helper
type we are talking about because all of them support inserting ASN.1
content.
With your suggestion,
if there's a mapping between "san_directoryname" and the corresponding
API calls or configuration lines, we need some way for users to augment
that mapping without changing the code. If there's no mapping, and it's
just done with text processing, we need enough in the config format to
be able to generate fairly complex structures:
builder = builder.subject_name(x509.Name(u'CN=user,O=EXAMPLE.COM'))
builder =
builder.add_extension(x509.SubjectAlternativeName([x509.RFC822Name(u'u...@example.com'),
x509.DirectoryName(x509.Name(u'CN=user,O=EXAMPLE.COM'))]), False)
and we need to do it without it being equivalent to calling eval() on
the config attributes. I'm not sure how to achieve this (is it safe to
call getattr(x509, extensiontype)(value) where extensiontype and value
are user-specified?) and it definitely would have to be tied to a
particular library/tool.
As I pointed out above, this needs to be figured out for the generic
case for both the current proposal and my suggestion.
OTOH, I think we could use GSER encoding of the extension value:
{ rfc822Name:"u...@example.com",
directoryName:rdnSequence:"CN=user,O=EXAMPLE.COM" }
GSER is not really used widely and does not have standardized encoding
rules beyond its own definition. If you want to allow transformation
rules in GSER that mention existing content in IPA objects, you would
need to deal with templating anyway. At this point it becomes irrelevant
what you are templating, though.
True, but the goal here is not to avoid templating, but rather to
avoid implementation-specific bits on the server, and GSER is the only
thing that is textual, implementation-neutral and, as a bonus,
standardized.
If we move these bits to the client, the only thing server will need to
deal with is CSR. The client then would definitely need to have ability
to provide alternative CSR sources (e.g. openssl text format) to aid
API users that don't utilize IPA tools directly. At this point GSER use
is irrelevant either.
--
/ Alexander Bokovoy
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation
On 25.7.2016 13:11, Alexander Bokovoy wrote: On Mon, 25 Jul 2016, Jan Cholasta wrote: On 20.7.2016 16:05, Ben Lipton wrote: Hi, Thanks very much for the feedback! Some responses below; I hope you'll let me know what you think of my reasoning. On 07/20/2016 04:20 AM, Jan Cholasta wrote: Hi, On 17.6.2016 00:06, Ben Lipton wrote: On 06/14/2016 08:27 AM, Ben Lipton wrote: Hello all, I have written up a design proposal for making certificate requests easier to generate when using alternate certificate profiles: http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation. The use case for this is described in https://fedorahosted.org/freeipa/ticket/4899. I will be working on implementing this design over the next couple of months. If you have the time and interest, please take a look and share any comments or concerns that you have. Thanks! Ben Just a quick update to say that I've created a new document that covers the proposed schema additions in a more descriptive way (with diagrams!) I'm very new to developing with LDAP, so some more experienced eyes on the proposal would be very helpful, even if you don't have time to absorb the full design. Please take a look at http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Schema if you have a chance. I finally had a chance to take a look at this, here are some comments: 1) I don't like how transformation rules are tied to a particular helper and have to be duplicated for each of them. They should be generic and work with any helper, as helpers are just an implementation detail and their resulting data is the same. In fact, I think I would prefer if the CSR was generated using python-cryptography's CertificateSigningRequestBuilder [1] rather than openssl or certutil or any other command line tool. There are lots of tools that users might want to use to manage their private keys, so I don't know if we can assume that whatever library we prefer will actually be able to access the private key to sign a CSR, which is why I thought it would be useful to support more than one. python-cryptography has the notion of backends, which allow it to support multiple crypto implementations. Upstream it currently supports only OpenSSL [2], but some work has been done on PKCS#11 backend [3], which provides support for HSMs and soft-tokens (like NSS databases). Alternatively, for NSS databases (and other "simple" cases), you can generate the private key with python-cryptography using the default backend, export it to a file and import the file to the target database, so you don't actually need the PKCS#11 backend for them. So, the only thing that's currently lacking is HSM support, but given that we don't support HSMs in IPA nor in certmonger, I don't think it's an issue for now. The purpose of the mapping rule is to tie together the transformation rules that produce the same data into an object that's implementation-agnostic, so that profiles referencing those rules are automatically compatible with all the helper options. They are implementation-agnostic, as long as you consider `openssl` and `certutil` the only implementations :-) But I don't think this solution scales well to other possible implementations. Anyway, my main grudge is that the transformation rules shouldn't really be stored on and processed by the server. The server should know the *what* (mapping rules), but not the *how* (transformation rules). The *how* is an implementation detail and does not change in time, so there's no benefit in handling it on the server. It should be handled exclusively on the client, which I believe would also make the whole thing more robust (it would not be possible for a bug on the server to break all the clients). This is a good point. However, for the scope of Ben's project can we limit it by openssl and certutil support? Otherwise Ben wouldn't be able to complete the project in time. I'm fine with that, but I don't think it's up to me :-) This is turning out to be a common (and, I think, reasonable) reaction to the proposal. It is rather complex, and I worry that it will be difficult to configure. On the other hand, there is some hidden complexity to enabling a simpler config format, as well. One of the goals of the project as it was presented to me was to allow the creation of profiles that add certificate extensions *that FreeIPA doesn't yet know about*. With the current proposal, one only has to add a rule generating text that the helper will understand. ... which will be possible only as long as the helper understands the extension. Which it might not, thus the current proposal works only for *some* extensions that FreeIPA doesn't yet support. We can go ad infinitum here but with any helper implementation, be it python-cryptography or anything else, you will need to have a support there as well. My point was that the current proposal is not any better than my proposal in this regard, as neither of
Re: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation
On Mon, 25 Jul 2016, Jan Cholasta wrote: On 20.7.2016 16:05, Ben Lipton wrote: Hi, Thanks very much for the feedback! Some responses below; I hope you'll let me know what you think of my reasoning. On 07/20/2016 04:20 AM, Jan Cholasta wrote: Hi, On 17.6.2016 00:06, Ben Lipton wrote: On 06/14/2016 08:27 AM, Ben Lipton wrote: Hello all, I have written up a design proposal for making certificate requests easier to generate when using alternate certificate profiles: http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation. The use case for this is described in https://fedorahosted.org/freeipa/ticket/4899. I will be working on implementing this design over the next couple of months. If you have the time and interest, please take a look and share any comments or concerns that you have. Thanks! Ben Just a quick update to say that I've created a new document that covers the proposed schema additions in a more descriptive way (with diagrams!) I'm very new to developing with LDAP, so some more experienced eyes on the proposal would be very helpful, even if you don't have time to absorb the full design. Please take a look at http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Schema if you have a chance. I finally had a chance to take a look at this, here are some comments: 1) I don't like how transformation rules are tied to a particular helper and have to be duplicated for each of them. They should be generic and work with any helper, as helpers are just an implementation detail and their resulting data is the same. In fact, I think I would prefer if the CSR was generated using python-cryptography's CertificateSigningRequestBuilder [1] rather than openssl or certutil or any other command line tool. There are lots of tools that users might want to use to manage their private keys, so I don't know if we can assume that whatever library we prefer will actually be able to access the private key to sign a CSR, which is why I thought it would be useful to support more than one. python-cryptography has the notion of backends, which allow it to support multiple crypto implementations. Upstream it currently supports only OpenSSL [2], but some work has been done on PKCS#11 backend [3], which provides support for HSMs and soft-tokens (like NSS databases). Alternatively, for NSS databases (and other "simple" cases), you can generate the private key with python-cryptography using the default backend, export it to a file and import the file to the target database, so you don't actually need the PKCS#11 backend for them. So, the only thing that's currently lacking is HSM support, but given that we don't support HSMs in IPA nor in certmonger, I don't think it's an issue for now. The purpose of the mapping rule is to tie together the transformation rules that produce the same data into an object that's implementation-agnostic, so that profiles referencing those rules are automatically compatible with all the helper options. They are implementation-agnostic, as long as you consider `openssl` and `certutil` the only implementations :-) But I don't think this solution scales well to other possible implementations. Anyway, my main grudge is that the transformation rules shouldn't really be stored on and processed by the server. The server should know the *what* (mapping rules), but not the *how* (transformation rules). The *how* is an implementation detail and does not change in time, so there's no benefit in handling it on the server. It should be handled exclusively on the client, which I believe would also make the whole thing more robust (it would not be possible for a bug on the server to break all the clients). This is a good point. However, for the scope of Ben's project can we limit it by openssl and certutil support? Otherwise Ben wouldn't be able to complete the project in time. This is turning out to be a common (and, I think, reasonable) reaction to the proposal. It is rather complex, and I worry that it will be difficult to configure. On the other hand, there is some hidden complexity to enabling a simpler config format, as well. One of the goals of the project as it was presented to me was to allow the creation of profiles that add certificate extensions *that FreeIPA doesn't yet know about*. With the current proposal, one only has to add a rule generating text that the helper will understand. ... which will be possible only as long as the helper understands the extension. Which it might not, thus the current proposal works only for *some* extensions that FreeIPA doesn't yet support. We can go ad infinitum here but with any helper implementation, be it python-cryptography or anything else, you will need to have a support there as well. The idea with unknown extensions was to allow mapping their acceptance to a specific relationship between IPA objects (optionally) and an input from the CSR. A simplest example would be an
Re: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation
On Mon, 2016-07-25 at 10:50 +0200, Jan Cholasta wrote: > Anyway, my main grudge is that the transformation rules shouldn't > really > be stored on and processed by the server. The server should know the > *what* (mapping rules), but not the *how* (transformation rules). The > *how* is an implementation detail and does not change in time, so > there's no benefit in handling it on the server. It should be handled > exclusively on the client, which I believe would also make the whole > thing more robust (it would not be possible for a bug on the server > to > break all the clients). W/o entering in specific +1 as a general comment on this. If it can be done on the client, probably better be done there. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation
On 20.7.2016 16:05, Ben Lipton wrote:
Hi,
Thanks very much for the feedback! Some responses below; I hope you'll
let me know what you think of my reasoning.
On 07/20/2016 04:20 AM, Jan Cholasta wrote:
Hi,
On 17.6.2016 00:06, Ben Lipton wrote:
On 06/14/2016 08:27 AM, Ben Lipton wrote:
Hello all,
I have written up a design proposal for making certificate requests
easier to generate when using alternate certificate profiles:
http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation.
The use case for this is described in
https://fedorahosted.org/freeipa/ticket/4899. I will be working on
implementing this design over the next couple of months. If you have
the time and interest, please take a look and share any comments or
concerns that you have.
Thanks!
Ben
Just a quick update to say that I've created a new document that covers
the proposed schema additions in a more descriptive way (with diagrams!)
I'm very new to developing with LDAP, so some more experienced eyes on
the proposal would be very helpful, even if you don't have time to
absorb the full design. Please take a look at
http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Schema
if you have a chance.
I finally had a chance to take a look at this, here are some comments:
1) I don't like how transformation rules are tied to a particular
helper and have to be duplicated for each of them. They should be
generic and work with any helper, as helpers are just an
implementation detail and their resulting data is the same.
In fact, I think I would prefer if the CSR was generated using
python-cryptography's CertificateSigningRequestBuilder [1] rather than
openssl or certutil or any other command line tool.
There are lots of tools that users might want to use to manage their
private keys, so I don't know if we can assume that whatever library we
prefer will actually be able to access the private key to sign a CSR,
which is why I thought it would be useful to support more than one.
python-cryptography has the notion of backends, which allow it to
support multiple crypto implementations. Upstream it currently supports
only OpenSSL [2], but some work has been done on PKCS#11 backend [3],
which provides support for HSMs and soft-tokens (like NSS databases).
Alternatively, for NSS databases (and other "simple" cases), you can
generate the private key with python-cryptography using the default
backend, export it to a file and import the file to the target database,
so you don't actually need the PKCS#11 backend for them.
So, the only thing that's currently lacking is HSM support, but given
that we don't support HSMs in IPA nor in certmonger, I don't think it's
an issue for now.
The
purpose of the mapping rule is to tie together the transformation rules
that produce the same data into an object that's
implementation-agnostic, so that profiles referencing those rules are
automatically compatible with all the helper options.
They are implementation-agnostic, as long as you consider `openssl` and
`certutil` the only implementations :-) But I don't think this solution
scales well to other possible implementations.
Anyway, my main grudge is that the transformation rules shouldn't really
be stored on and processed by the server. The server should know the
*what* (mapping rules), but not the *how* (transformation rules). The
*how* is an implementation detail and does not change in time, so
there's no benefit in handling it on the server. It should be handled
exclusively on the client, which I believe would also make the whole
thing more robust (it would not be possible for a bug on the server to
break all the clients).
I do agree that it would be preferable to target APIs rather than
command-line tools. When looking at the openSSL and NSS APIs I came to
the conclusion that they would be more difficult than the command-line
tools to target, as a first implementation. However, I haven't really
looked at python-cryptography, and maybe it would have been a good choice.
The current trend is to port all crypto code to python-cryptography, so
it is indeed a good choice :-)
2) The schema seems unnecessarily complex. I think all we need is a
single new multi-value attribute in certprofile. For your S/MIME
example, it could be something like:
attr: subjectname=CN={subject.cn},{subject_base}
attr: san_rfc822name={subject.email}
attr: san_directoryname={subject.dn}
This is turning out to be a common (and, I think, reasonable) reaction
to the proposal. It is rather complex, and I worry that it will be
difficult to configure. On the other hand, there is some hidden
complexity to enabling a simpler config format, as well. One of the
goals of the project as it was presented to me was to allow the creation
of profiles that add certificate extensions *that FreeIPA doesn't yet
know about*. With the current proposal, one only has to add a rule
generating text that the helper will
Re: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation
Hi,
On 17.6.2016 00:06, Ben Lipton wrote:
On 06/14/2016 08:27 AM, Ben Lipton wrote:
Hello all,
I have written up a design proposal for making certificate requests
easier to generate when using alternate certificate profiles:
http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation.
The use case for this is described in
https://fedorahosted.org/freeipa/ticket/4899. I will be working on
implementing this design over the next couple of months. If you have
the time and interest, please take a look and share any comments or
concerns that you have.
Thanks!
Ben
Just a quick update to say that I've created a new document that covers
the proposed schema additions in a more descriptive way (with diagrams!)
I'm very new to developing with LDAP, so some more experienced eyes on
the proposal would be very helpful, even if you don't have time to
absorb the full design. Please take a look at
http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Schema
if you have a chance.
I finally had a chance to take a look at this, here are some comments:
1) I don't like how transformation rules are tied to a particular helper
and have to be duplicated for each of them. They should be generic and
work with any helper, as helpers are just an implementation detail and
their resulting data is the same.
In fact, I think I would prefer if the CSR was generated using
python-cryptography's CertificateSigningRequestBuilder [1] rather than
openssl or certutil or any other command line tool.
2) The schema seems unnecessarily complex. I think all we need is a
single new multi-value attribute in certprofile. For your S/MIME
example, it could be something like:
attr: subjectname=CN={subject.cn},{subject_base}
attr: san_rfc822name={subject.email}
attr: san_directoryname={subject.dn}
Honza
[1]
--
Jan Cholasta
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation
On 06/14/2016 08:27 AM, Ben Lipton wrote: Hello all, I have written up a design proposal for making certificate requests easier to generate when using alternate certificate profiles: http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation. The use case for this is described in https://fedorahosted.org/freeipa/ticket/4899. I will be working on implementing this design over the next couple of months. If you have the time and interest, please take a look and share any comments or concerns that you have. Thanks! Ben Just a quick update to say that I've created a new document that covers the proposed schema additions in a more descriptive way (with diagrams!) I'm very new to developing with LDAP, so some more experienced eyes on the proposal would be very helpful, even if you don't have time to absorb the full design. Please take a look at http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Schema if you have a chance. Thanks, Ben -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation
Hello all, I have written up a design proposal for making certificate requests easier to generate when using alternate certificate profiles: http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation. The use case for this is described in https://fedorahosted.org/freeipa/ticket/4899. I will be working on implementing this design over the next couple of months. If you have the time and interest, please take a look and share any comments or concerns that you have. Thanks! Ben -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
