[Freeipa-devel] CA certificate renewal, shared store trust settings

[Jan Cholasta]

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