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

[Jan Cholasta]

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 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.

I agree. We can work out the details later.

>
> Cheers,
>
> Nalin
>


-- 
Jan Cholasta