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

[Nalin Dahyabhai]

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 fleshed out,
LDAP's the only option.  But I understand we're not there yet.

I'm starting to think that attempting to future-proof by learning to
fetch and store the v4 information isn't a good idea at this time, and
sticking to just fetching the data we store in v3 is the better option.

Cheers,

Nalin