Re: [Freeipa-devel] CA certificate renewal, shared store trust settings
On 30.5.2014 16:11, Nalin Dahyabhai wrote: On Fri, May 30, 2014 at 09:09:46AM +0200, Jan Cholasta wrote: On 29.5.2014 19:44, Nalin Dahyabhai wrote: I'm working on adding to certmonger the ability to read the IPA root certificate from the server and store it locally, and I'm looking at the V4 shared certificate store feature [1] with an eye toward also pulling down and processing those certificates. Before I head down that path, I've got a few questions about the schema that the page describes for storing trust information. So, you want to fetch the certificates directly from LDAP? Shouldn't they rather be fetched using IPA API (in ipa-submit) or Dogtag API (in dogtag-ipa-renew-agent-submit)? Yes, that's something the daemon is farming out to the enrollment helpers. As a start, though, I'm only looking at teaching ipa-submit to fetch this information. The IPA interfaces run over HTTPS, so I thought that having ipa-submit search LDAP using GSSAPI would avoid complications that could arise if the CA certificate had become invalid before we went to fetch things. Right, that might be a problem. The request for the read the root certificate functionality is to have something that works against servers running IPA on EL6, so the ability to fetch the v3 root information is dictated by needing to work against what we're already storing and offering there. Accessing the additional information that's coming in v4 could be done differently, but I'd also lean toward looking at the directory directly. The design page mentions asking SSSD for it, which I guess would work. Well, both will work. In the past few months that I worked on the CA certificate renewal feature the shared certificate store design has evolved into something more about certificate trust policy rather than simple storage of CA certificates. My plan is to integrate it with p11-kit in the forthcoming months to provide the policy to IPA clients. SSSD is going to be used as the component between IPA and p11-kit. A PKCS#11 module will be provided for (not only) that. (This is what http://www.freeipa.org/page/V4/CA_certificate_renewal_(2) is going to be about.) I can imagine you might as well talk to the module to fetch the CA certificates. Are there any plans to support PKCS#11 as a storage backend in certmonger? Only notionally, as it it's only ever been one of those would be cool, but we don't need it in the short-term things. I also wasn't looking forward to dealing with cases where a removable token isn't inserted right when we intend to access it, but if we need to make that work, then okay. This does not make me nervous at all. Take a look at other similar attributes in IPA, they all use directory string syntax. I'm open to suggestions, though. The first thing that comes to mind is an enumerated syntax like the one for booleans, but I understand that enforcing that would require help from the server itself. The docs tell me that syntax plugins are a thing we can supply, but that might be more than we want to bite off. My thoughts exactly. The ipaKeyExtUsage attribute, along with ipaKeyTrust values of 'trusted' and 'distrusted', appears to map pretty directly to the sort of information that OpenSSL stores in trusted certificates [2], but going through the man pages for x509(1) and verify(1), I don't see anything that obviously corresponds to an ipaKeyTrust value of 'unknown'. What's that value intended to signify, and how would consumers of the certificates be expected to treat certificates from entries with that ipaKeyTrust value? Actually it is designed to map to p11-kit-style trust policy (http://p11-glue.freedesktop.org/doc/storing-trust-policy/index.html), which is a superset of OpenSSL's. What's the planned schedule for teaching NSS and OpenSSL to consume trust information supplied in this format? It's all available in Fedora since F19, see http://fedoraproject.org/wiki/Features/SharedSystemCertificates. The unknown value means the trust is not explicitly given and that if there is other source of trust information for the key/certificate, it should be used. In p11-kit terms, it is for certificates which are neither in the anchors nor the blacklist set. In NSS terms, it's for certificates without any of the C, T, P or p trust flags. Okay, that makes sense -- they're around for building chains, but not much else. Are there examples of what the ipaKeyUsage attribute should contain? It's the purpose bit names from the key usage certificate extension (http://tools.ietf.org/html/rfc5280#section-4.2.1.3) or none. So, enumerated values represented as directory strings? Yes. Is there a recommended method for mapping from this representation to the form that we'd pass to certutil(1)'s '-t' option when storing the certificates in NSS databases, or is the intent that it be translated into NSS-specific PKCS#11 attributes set on those certificates? Well, it can be both. But as I said
Re: [Freeipa-devel] CA certificate renewal, shared store trust settings
Hi, On 29.5.2014 19:44, Nalin Dahyabhai wrote: I'm working on adding to certmonger the ability to read the IPA root certificate from the server and store it locally, and I'm looking at the V4 shared certificate store feature [1] with an eye toward also pulling down and processing those certificates. Before I head down that path, I've got a few questions about the schema that the page describes for storing trust information. So, you want to fetch the certificates directly from LDAP? Shouldn't they rather be fetched using IPA API (in ipa-submit) or Dogtag API (in dogtag-ipa-renew-agent-submit)? In the past few months that I worked on the CA certificate renewal feature the shared certificate store design has evolved into something more about certificate trust policy rather than simple storage of CA certificates. My plan is to integrate it with p11-kit in the forthcoming months to provide the policy to IPA clients. SSSD is going to be used as the component between IPA and p11-kit. A PKCS#11 module will be provided for (not only) that. (This is what http://www.freeipa.org/page/V4/CA_certificate_renewal_(2) is going to be about.) I can imagine you might as well talk to the module to fetch the CA certificates. Are there any plans to support PKCS#11 as a storage backend in certmonger? Is the ipaKeyTrust attribute meant to be a part of the ipaKeyPolicy object class? Yes. Looking at the ipaKeyTrust attribute, the description suggests that it's a directoryString that should contain one of 'unknown', 'trusted', or 'distrusted' as its value. The syntax doesn't guarantee that, and that ambiguity makes me a little nervous. Any chance of tweaking the schema to remove that possibility? This does not make me nervous at all. Take a look at other similar attributes in IPA, they all use directory string syntax. I'm open to suggestions, though. The ipaKeyExtUsage attribute, along with ipaKeyTrust values of 'trusted' and 'distrusted', appears to map pretty directly to the sort of information that OpenSSL stores in trusted certificates [2], but going through the man pages for x509(1) and verify(1), I don't see anything that obviously corresponds to an ipaKeyTrust value of 'unknown'. What's that value intended to signify, and how would consumers of the certificates be expected to treat certificates from entries with that ipaKeyTrust value? Actually it is designed to map to p11-kit-style trust policy (http://p11-glue.freedesktop.org/doc/storing-trust-policy/index.html), which is a superset of OpenSSL's. The unknown value means the trust is not explicitly given and that if there is other source of trust information for the key/certificate, it should be used. In p11-kit terms, it is for certificates which are neither in the anchors nor the blacklist set. In NSS terms, it's for certificates without any of the C, T, P or p trust flags. Are there examples of what the ipaKeyUsage attribute should contain? It's the purpose bit names from the key usage certificate extension (http://tools.ietf.org/html/rfc5280#section-4.2.1.3) or none. Is there a recommended method for mapping from this representation to the form that we'd pass to certutil(1)'s '-t' option when storing the certificates in NSS databases, or is the intent that it be translated into NSS-specific PKCS#11 attributes set on those certificates? Well, it can be both. But as I said above, I'm not sure if reading from LDAP directly is the best thing to do in this case. Thanks, Nalin [1] http://www.freeipa.org/page/V4/CA_certificate_renewal#Shared_certificate_store [2] http://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-existing.html#openssl-trusted (Yes, I will update the design page.) Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] CA certificate renewal, shared store trust settings
On Fri, May 30, 2014 at 09:09:46AM +0200, Jan Cholasta wrote: On 29.5.2014 19:44, Nalin Dahyabhai wrote: I'm working on adding to certmonger the ability to read the IPA root certificate from the server and store it locally, and I'm looking at the V4 shared certificate store feature [1] with an eye toward also pulling down and processing those certificates. Before I head down that path, I've got a few questions about the schema that the page describes for storing trust information. So, you want to fetch the certificates directly from LDAP? Shouldn't they rather be fetched using IPA API (in ipa-submit) or Dogtag API (in dogtag-ipa-renew-agent-submit)? Yes, that's something the daemon is farming out to the enrollment helpers. As a start, though, I'm only looking at teaching ipa-submit to fetch this information. The IPA interfaces run over HTTPS, so I thought that having ipa-submit search LDAP using GSSAPI would avoid complications that could arise if the CA certificate had become invalid before we went to fetch things. The request for the read the root certificate functionality is to have something that works against servers running IPA on EL6, so the ability to fetch the v3 root information is dictated by needing to work against what we're already storing and offering there. Accessing the additional information that's coming in v4 could be done differently, but I'd also lean toward looking at the directory directly. The design page mentions asking SSSD for it, which I guess would work. In the past few months that I worked on the CA certificate renewal feature the shared certificate store design has evolved into something more about certificate trust policy rather than simple storage of CA certificates. My plan is to integrate it with p11-kit in the forthcoming months to provide the policy to IPA clients. SSSD is going to be used as the component between IPA and p11-kit. A PKCS#11 module will be provided for (not only) that. (This is what http://www.freeipa.org/page/V4/CA_certificate_renewal_(2) is going to be about.) I can imagine you might as well talk to the module to fetch the CA certificates. Are there any plans to support PKCS#11 as a storage backend in certmonger? Only notionally, as it it's only ever been one of those would be cool, but we don't need it in the short-term things. I also wasn't looking forward to dealing with cases where a removable token isn't inserted right when we intend to access it, but if we need to make that work, then okay. This does not make me nervous at all. Take a look at other similar attributes in IPA, they all use directory string syntax. I'm open to suggestions, though. The first thing that comes to mind is an enumerated syntax like the one for booleans, but I understand that enforcing that would require help from the server itself. The docs tell me that syntax plugins are a thing we can supply, but that might be more than we want to bite off. The ipaKeyExtUsage attribute, along with ipaKeyTrust values of 'trusted' and 'distrusted', appears to map pretty directly to the sort of information that OpenSSL stores in trusted certificates [2], but going through the man pages for x509(1) and verify(1), I don't see anything that obviously corresponds to an ipaKeyTrust value of 'unknown'. What's that value intended to signify, and how would consumers of the certificates be expected to treat certificates from entries with that ipaKeyTrust value? Actually it is designed to map to p11-kit-style trust policy (http://p11-glue.freedesktop.org/doc/storing-trust-policy/index.html), which is a superset of OpenSSL's. What's the planned schedule for teaching NSS and OpenSSL to consume trust information supplied in this format? The unknown value means the trust is not explicitly given and that if there is other source of trust information for the key/certificate, it should be used. In p11-kit terms, it is for certificates which are neither in the anchors nor the blacklist set. In NSS terms, it's for certificates without any of the C, T, P or p trust flags. Okay, that makes sense -- they're around for building chains, but not much else. Are there examples of what the ipaKeyUsage attribute should contain? It's the purpose bit names from the key usage certificate extension (http://tools.ietf.org/html/rfc5280#section-4.2.1.3) or none. So, enumerated values represented as directory strings? Is there a recommended method for mapping from this representation to the form that we'd pass to certutil(1)'s '-t' option when storing the certificates in NSS databases, or is the intent that it be translated into NSS-specific PKCS#11 attributes set on those certificates? Well, it can be both. But as I said above, I'm not sure if reading from LDAP directly is the best thing to do in this case. [shrug] If that's where it's being stored, something's going to have to fetch it from there. Until the SSSD and IPA interfaces are
[Freeipa-devel] CA certificate renewal, shared store trust settings
I'm working on adding to certmonger the ability to read the IPA root certificate from the server and store it locally, and I'm looking at the V4 shared certificate store feature [1] with an eye toward also pulling down and processing those certificates. Before I head down that path, I've got a few questions about the schema that the page describes for storing trust information. Is the ipaKeyTrust attribute meant to be a part of the ipaKeyPolicy object class? Looking at the ipaKeyTrust attribute, the description suggests that it's a directoryString that should contain one of 'unknown', 'trusted', or 'distrusted' as its value. The syntax doesn't guarantee that, and that ambiguity makes me a little nervous. Any chance of tweaking the schema to remove that possibility? The ipaKeyExtUsage attribute, along with ipaKeyTrust values of 'trusted' and 'distrusted', appears to map pretty directly to the sort of information that OpenSSL stores in trusted certificates [2], but going through the man pages for x509(1) and verify(1), I don't see anything that obviously corresponds to an ipaKeyTrust value of 'unknown'. What's that value intended to signify, and how would consumers of the certificates be expected to treat certificates from entries with that ipaKeyTrust value? Are there examples of what the ipaKeyUsage attribute should contain? Is there a recommended method for mapping from this representation to the form that we'd pass to certutil(1)'s '-t' option when storing the certificates in NSS databases, or is the intent that it be translated into NSS-specific PKCS#11 attributes set on those certificates? Thanks, Nalin [1] http://www.freeipa.org/page/V4/CA_certificate_renewal#Shared_certificate_store [2] http://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-existing.html#openssl-trusted ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
