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
