Thinking about the DNP3 use case, it would be nice to have some way of specifying how to generate the appropriate certificate request for a particular profile based on information stored in LDAP (including from plugins).
For example, DNP3 SAv5 uses the IEC 62351-8 extension which includes domain-specific authorization data about a user entity. If that custom information is stored in LDAP via a plugin, it would be nice to have a way for admins to define how to map that info into a certificate request (and then go on to request the certificate, etc).
Profile support (4.2) is the prerequisite for this enhancement.
abokovoy suggested a "template" feature:
Some profiles require a bit of trickery to generate a suitable CSR for use with that profile.
Add the ability to store along with each profile a config template for `openssl req' that can be retrieved by (or for) a user (filled out to the extent possible specifically for that user).
Investigate whether provision should be made for templates for tools other than `openssl'.
Some mores notes:
a Q&A user interaction (or answers file) can be used to supply information that cannot be gleaned from the directory
This command could a) generate an openssl req' config file, or b) generate a CSR (either also generating key or using a nominated key, or c) be made part of theipa cert-request' process so that the whole process can be done in a single command.
openssl req' config file, or b) generate a CSR (either also generating key or using a nominated key, or c) be made part of the
My preference is for (c).
Addition information from mail discussion:
I agree that it is a good intern project. However, the value of interpreting the Dogtag profile configuration is debatable; e.g. knowing that the profile supports SAN doesn't help in knowing what names to put in it. I see this "mapping" as being FreeIPA-specific profile configuration (i.e., defined in the IPA certprofile object but not part of the Dogtag profile configuration). The very fact that you have to write down ASN.1-friendly description of the Dogtag profile, feed it to openssl or other tool, produce request file, upload it via IPA CLI/Web UI, is just too much complication for users. Automatically producing config file based on the Dogtag profile is already a way better than what we have right now. Naturally extending that to have the process of 'create request config; ask for parameters; create request; submit request' automated as part of a simple IPA CLI command would be good. Clearly showing a user that this or that parameter is optional to enter is good too. Overall, UXD of issuing certificates is poor. Improvements like the above move us quite ahead on this road. Not only right now creation of request config is not documented well, but search engines full of incomprehensible blog articles that only cover what their respective authors were interested in. This also leads to creation of cert requests which are incorrect, like using SAN field to record IP addresses in OpenStack Director. Your worry about interpretation of the values in the request is valid. However, all the above is also done in IPA. I'm not asking right now for Dogtag-based tool to create cert request files, input values and so on. This is domain of IPA and partially should be done on server side, partially at the client side. Thus, if we need to augment Dogtag's profile with a mapping table defining that a certain cert extension actually means host or service name, or user, or group attribute's value -- that's fine. The simplification of the user workflow needs to be done nevertheless, and what I outline above is part of it, way beyond defining Dogtag cert profile <-> IPA object property mapping. Hopefully, this is something we agree on. For sure; all of the above can be accomplished without IPA having to understand the Dogtag profile configuration, or implement anything equivalent. How can we remove manual generation of CSR config in the example in your blog article: http://blog-ftweedal.rhcloud.com/2015/08/user-certificates-and-custom-profiles-with-freeipa-4-2/ ? This CSR config part is what puzzles majority of users as there is no documentation on how to do it and given that it should correspond to a profile at CA in most cases, we can automate the manual work and copy/paste work done by users. If we removed that (made automatic), we can also remove use of openssl to generate request on the client side, by producing csr ourselves on the client side without user being forced to do so. Right now we have achieved it with user of certutil from NSS which doesn't require CSR config but requires explicit values specified as its command line options. I'd prefer to remove that obscure knowledge too, just ask the values via IPA CLI as our primary user interface. The only thing user is left with, is to enter the values that should be part of the CSR. Is that possible already? Yes; someone just needs to write the feature :) This is exactly what we want to have done as an internship project. I'm a bit surprised your insistence on crude and awkward user interface that CSR config + openssl CLI represent here. We want a simple rule-driven data retrieval system to acquire needed data from the user interactively and/or from the directory automatically to construct the CSR. Then construct the CSR and issue the request. Yes, exactly. We want to avoid exposing technical details of how profile and CSR are constructed to allow automation of most common use cases based on the contextual knowledge already available in FreeIPA and Dogtag. I bet users would rather have something like ipa certrequest-add-<profilename> <request_name> [profile options, or interactive input] than learning how to create all the manual work outlined above. This 'certrequest-add-<profilename>' command can be purely virtual, based on the list of profiles that can be obtained under current user credentials. Are you envisaging this command to integrate with Certmonger? I envisaged this feature as an (optional) enhancement to `ipa cert-request'. In the simple case where no user interrogation is required this means that either a public key input or public key output filename argument is needed. e.g. ipa cert-request --profile-id=ID --principal=NAME \ --auto --private-key=FILENAME Or --private-key-out=FILENAME to cause the ipa program to generate the keypair and write the private key to a file. And an (optional; sensible default) argument to specify they key type and size. The cert-request-<profilename> flow maps nicely to certmonger use. Sometimes you actually don't need that, though, so it needs to be conditional. For example, for user certificates being able to request certificate with little technicalities is important but forcing it to be tracked by certmonger is probably not so important due to the fact that the same certificate can be used on multiple machines. What is highly relevant to this thread however are the prerequisites on the FreeIPA side to let Intern work on this project. I know for example that FreeIPA Thin Client work should be done before, so that the interface with FreeIPA does not have to be redone later. Any other requirements?
I agree that it is a good intern project. However, the value of interpreting the Dogtag profile configuration is debatable; e.g. knowing that the profile supports SAN doesn't help in knowing what names to put in it. I see this "mapping" as being FreeIPA-specific profile configuration (i.e., defined in the IPA certprofile object but not part of the Dogtag profile configuration). The very fact that you have to write down ASN.1-friendly description of the Dogtag profile, feed it to openssl or other tool, produce request file, upload it via IPA CLI/Web UI, is just too much complication for users. Automatically producing config file based on the Dogtag profile is already a way better than what we have right now. Naturally extending that to have the process of 'create request config; ask for parameters; create request; submit request' automated as part of a simple IPA CLI command would be good. Clearly showing a user that this or that parameter is optional to enter is good too. Overall, UXD of issuing certificates is poor. Improvements like the above move us quite ahead on this road. Not only right now creation of request config is not documented well, but search engines full of incomprehensible blog articles that only cover what their respective authors were interested in. This also leads to creation of cert requests which are incorrect, like using SAN field to record IP addresses in OpenStack Director. Your worry about interpretation of the values in the request is valid. However, all the above is also done in IPA. I'm not asking right now for Dogtag-based tool to create cert request files, input values and so on. This is domain of IPA and partially should be done on server side, partially at the client side. Thus, if we need to augment Dogtag's profile with a mapping table defining that a certain cert extension actually means host or service name, or user, or group attribute's value -- that's fine. The simplification of the user workflow needs to be done nevertheless, and what I outline above is part of it, way beyond defining Dogtag cert profile <-> IPA object property mapping. Hopefully, this is something we agree on. For sure; all of the above can be accomplished without IPA having to understand the Dogtag profile configuration, or implement anything equivalent. How can we remove manual generation of CSR config in the example in your blog article: http://blog-ftweedal.rhcloud.com/2015/08/user-certificates-and-custom-profiles-with-freeipa-4-2/ ? This CSR config part is what puzzles majority of users as there is no documentation on how to do it and given that it should correspond to a profile at CA in most cases, we can automate the manual work and copy/paste work done by users. If we removed that (made automatic), we can also remove use of openssl to generate request on the client side, by producing csr ourselves on the client side without user being forced to do so. Right now we have achieved it with user of certutil from NSS which doesn't require CSR config but requires explicit values specified as its command line options. I'd prefer to remove that obscure knowledge too, just ask the values via IPA CLI as our primary user interface. The only thing user is left with, is to enter the values that should be part of the CSR. Is that possible already? Yes; someone just needs to write the feature :) This is exactly what we want to have done as an internship project. I'm a bit surprised your insistence on crude and awkward user interface that CSR config + openssl CLI represent here. We want a simple rule-driven data retrieval system to acquire needed data from the user interactively and/or from the directory automatically to construct the CSR. Then construct the CSR and issue the request. Yes, exactly. We want to avoid exposing technical details of how profile and CSR are constructed to allow automation of most common use cases based on the contextual knowledge already available in FreeIPA and Dogtag. I bet users would rather have something like ipa certrequest-add-<profilename> <request_name> [profile options, or interactive input] than learning how to create all the manual work outlined above. This 'certrequest-add-<profilename>' command can be purely virtual, based on the list of profiles that can be obtained under current user credentials. Are you envisaging this command to integrate with Certmonger? I envisaged this feature as an (optional) enhancement to `ipa cert-request'. In the simple case where no user interrogation is required this means that either a public key input or public key output filename argument is needed. e.g. ipa cert-request --profile-id=ID --principal=NAME \ --auto --private-key=FILENAME Or --private-key-out=FILENAME to cause the ipa program to generate the keypair and write the private key to a file. And an (optional; sensible default) argument to specify they key type and size. The cert-request-<profilename> flow maps nicely to certmonger use. Sometimes you actually don't need that, though, so it needs to be conditional. For example, for user certificates being able to request certificate with little technicalities is important but forcing it to be tracked by certmonger is probably not so important due to the fact that the same certificate can be used on multiple machines.
I agree that it is a good intern project. However, the value of interpreting the Dogtag profile configuration is debatable; e.g. knowing that the profile supports SAN doesn't help in knowing what names to put in it. I see this "mapping" as being FreeIPA-specific profile configuration (i.e., defined in the IPA certprofile object but not part of the Dogtag profile configuration). The very fact that you have to write down ASN.1-friendly description of the Dogtag profile, feed it to openssl or other tool, produce request file, upload it via IPA CLI/Web UI, is just too much complication for users. Automatically producing config file based on the Dogtag profile is already a way better than what we have right now. Naturally extending that to have the process of 'create request config; ask for parameters; create request; submit request' automated as part of a simple IPA CLI command would be good. Clearly showing a user that this or that parameter is optional to enter is good too. Overall, UXD of issuing certificates is poor. Improvements like the above move us quite ahead on this road. Not only right now creation of request config is not documented well, but search engines full of incomprehensible blog articles that only cover what their respective authors were interested in. This also leads to creation of cert requests which are incorrect, like using SAN field to record IP addresses in OpenStack Director. Your worry about interpretation of the values in the request is valid. However, all the above is also done in IPA. I'm not asking right now for Dogtag-based tool to create cert request files, input values and so on. This is domain of IPA and partially should be done on server side, partially at the client side. Thus, if we need to augment Dogtag's profile with a mapping table defining that a certain cert extension actually means host or service name, or user, or group attribute's value -- that's fine. The simplification of the user workflow needs to be done nevertheless, and what I outline above is part of it, way beyond defining Dogtag cert profile <-> IPA object property mapping. Hopefully, this is something we agree on. For sure; all of the above can be accomplished without IPA having to understand the Dogtag profile configuration, or implement anything equivalent. How can we remove manual generation of CSR config in the example in your blog article: http://blog-ftweedal.rhcloud.com/2015/08/user-certificates-and-custom-profiles-with-freeipa-4-2/ ? This CSR config part is what puzzles majority of users as there is no documentation on how to do it and given that it should correspond to a profile at CA in most cases, we can automate the manual work and copy/paste work done by users. If we removed that (made automatic), we can also remove use of openssl to generate request on the client side, by producing csr ourselves on the client side without user being forced to do so. Right now we have achieved it with user of certutil from NSS which doesn't require CSR config but requires explicit values specified as its command line options. I'd prefer to remove that obscure knowledge too, just ask the values via IPA CLI as our primary user interface. The only thing user is left with, is to enter the values that should be part of the CSR. Is that possible already? Yes; someone just needs to write the feature :) This is exactly what we want to have done as an internship project. I'm a bit surprised your insistence on crude and awkward user interface that CSR config + openssl CLI represent here.
I agree that it is a good intern project. However, the value of interpreting the Dogtag profile configuration is debatable; e.g. knowing that the profile supports SAN doesn't help in knowing what names to put in it. I see this "mapping" as being FreeIPA-specific profile configuration (i.e., defined in the IPA certprofile object but not part of the Dogtag profile configuration). The very fact that you have to write down ASN.1-friendly description of the Dogtag profile, feed it to openssl or other tool, produce request file, upload it via IPA CLI/Web UI, is just too much complication for users. Automatically producing config file based on the Dogtag profile is already a way better than what we have right now. Naturally extending that to have the process of 'create request config; ask for parameters; create request; submit request' automated as part of a simple IPA CLI command would be good. Clearly showing a user that this or that parameter is optional to enter is good too. Overall, UXD of issuing certificates is poor. Improvements like the above move us quite ahead on this road. Not only right now creation of request config is not documented well, but search engines full of incomprehensible blog articles that only cover what their respective authors were interested in. This also leads to creation of cert requests which are incorrect, like using SAN field to record IP addresses in OpenStack Director. Your worry about interpretation of the values in the request is valid. However, all the above is also done in IPA. I'm not asking right now for Dogtag-based tool to create cert request files, input values and so on. This is domain of IPA and partially should be done on server side, partially at the client side. Thus, if we need to augment Dogtag's profile with a mapping table defining that a certain cert extension actually means host or service name, or user, or group attribute's value -- that's fine. The simplification of the user workflow needs to be done nevertheless, and what I outline above is part of it, way beyond defining Dogtag cert profile <-> IPA object property mapping. Hopefully, this is something we agree on. For sure; all of the above can be accomplished without IPA having to understand the Dogtag profile configuration, or implement anything equivalent. How can we remove manual generation of CSR config in the example in your blog article: http://blog-ftweedal.rhcloud.com/2015/08/user-certificates-and-custom-profiles-with-freeipa-4-2/
I agree that it is a good intern project. However, the value of interpreting the Dogtag profile configuration is debatable; e.g. knowing that the profile supports SAN doesn't help in knowing what names to put in it. I see this "mapping" as being FreeIPA-specific profile configuration (i.e., defined in the IPA certprofile object but not part of the Dogtag profile configuration). The very fact that you have to write down ASN.1-friendly description of the Dogtag profile, feed it to openssl or other tool, produce request file, upload it via IPA CLI/Web UI, is just too much complication for users.
Automatically producing config file based on the Dogtag profile is already a way better than what we have right now. Naturally extending that to have the process of 'create request config; ask for parameters; create request; submit request' automated as part of a simple IPA CLI command would be good. Clearly showing a user that this or that parameter is optional to enter is good too.
Overall, UXD of issuing certificates is poor. Improvements like the above move us quite ahead on this road. Not only right now creation of request config is not documented well, but search engines full of incomprehensible blog articles that only cover what their respective authors were interested in. This also leads to creation of cert requests which are incorrect, like using SAN field to record IP addresses in OpenStack Director.
Your worry about interpretation of the values in the request is valid. However, all the above is also done in IPA. I'm not asking right now for Dogtag-based tool to create cert request files, input values and so on. This is domain of IPA and partially should be done on server side, partially at the client side. Thus, if we need to augment Dogtag's profile with a mapping table defining that a certain cert extension actually means host or service name, or user, or group attribute's value -- that's fine. The simplification of the user workflow needs to be done nevertheless, and what I outline above is part of it, way beyond defining Dogtag cert profile <-> IPA object property mapping. Hopefully, this is something we agree on.
For sure; all of the above can be accomplished without IPA having to understand the Dogtag profile configuration, or implement anything equivalent. How can we remove manual generation of CSR config in the example in your blog article: http://blog-ftweedal.rhcloud.com/2015/08/user-certificates-and-custom-profiles-with-freeipa-4-2/
?
This CSR config part is what puzzles majority of users as there is no documentation on how to do it and given that it should correspond to a profile at CA in most cases, we can automate the manual work and copy/paste work done by users.
If we removed that (made automatic), we can also remove use of openssl to generate request on the client side, by producing csr ourselves on the client side without user being forced to do so. Right now we have achieved it with user of certutil from NSS which doesn't require CSR config but requires explicit values specified as its command line options. I'd prefer to remove that obscure knowledge too, just ask the values via IPA CLI as our primary user interface.
The only thing user is left with, is to enter the values that should be part of the CSR.
Is that possible already?
Yes; someone just needs to write the feature :) This is exactly what we want to have done as an internship project.
I'm a bit surprised your insistence on crude and awkward user interface that CSR config + openssl CLI represent here.
We want a simple rule-driven data retrieval system to acquire needed data from the user interactively and/or from the directory automatically to construct the CSR. Then construct the CSR and issue the request. Yes, exactly. We want to avoid exposing technical details of how profile and CSR are constructed to allow automation of most common use cases based on the contextual knowledge already available in FreeIPA and Dogtag.
I bet users would rather have something like ipa certrequest-add-<profilename> <request_name> [profile options, or interactive input] than learning how to create all the manual work outlined above. This 'certrequest-add-<profilename>' command can be purely virtual, based on the list of profiles that can be obtained under current user credentials. Are you envisaging this command to integrate with Certmonger?
I bet users would rather have something like
ipa certrequest-add-<profilename> <request_name> [profile options, or interactive input]
than learning how to create all the manual work outlined above. This 'certrequest-add-<profilename>' command can be purely virtual, based on the list of profiles that can be obtained under current user credentials.
Are you envisaging this command to integrate with Certmonger?
I envisaged this feature as an (optional) enhancement to `ipa cert-request'. In the simple case where no user interrogation is required this means that either a public key input or public key output filename argument is needed. e.g.
ipa cert-request --profile-id=ID --principal=NAME \ --auto --private-key=FILENAME
Or --private-key-out=FILENAME to cause the ipa program to generate the keypair and write the private key to a file. And an (optional; sensible default) argument to specify they key type and size. The cert-request-<profilename> flow maps nicely to certmonger use. Sometimes you actually don't need that, though, so it needs to be conditional. For example, for user certificates being able to request certificate with little technicalities is important but forcing it to be tracked by certmonger is probably not so important due to the fact that the same certificate can be used on multiple machines.
--private-key-out=FILENAME
ipa
What is highly relevant to this thread however are the prerequisites on the FreeIPA side to let Intern work on this project. I know for example that FreeIPA Thin Client work should be done before, so that the interface with FreeIPA does not have to be redone later. Any other requirements?
master:
Metadata Update from @ftweedal: - Issue assigned to benlipton - Issue set to the milestone: FreeIPA 4.5 backlog
Metadata Update from @jcholast: - Issue close_status updated to: None
Login to comment on this ticket.