[Freeipa-devel] Multiple CA certificates in LDAP, questions

[Stef Walter]

On 02.10.2013 13:10, Simo Sorce wrote:
> 
> 
> ----- Original Message -----
>> On 1.10.2013 22:08, Rob Crittenden wrote:
>>> Simo Sorce wrote:
>>>> ----- Original Message -----
>>>>> On 13.9.2013 11:05, Jan Cholasta wrote:
>>>>>> On 13.9.2013 10:53, Martin Kosek wrote:
>>>>>>> On 09/13/2013 10:51 AM, Jan Cholasta wrote:
>>>>>>>> On 5.9.2013 10:28, Jan Cholasta wrote:
>>>>>>>>> On 3.9.2013 18:16, Dmitri Pal wrote:
>>>>>>>>>> On 09/02/2013 04:49 AM, Petr Spacek wrote:
>>>>>>>>>>> It reminds me problems with key-rotation for DNSSEC.
>>>>>>>>>>>
>>>>>>>>>>> Could we find common problems and use the same/similar solution
>>>>>>>>>>> for
>>>>>>>>>>> both problems?
>>>>>>>>>>>
>>>>>>>>>>> An extension for certmonger? Oddjob? Or a completely new daemon?
>>>>>>>>>>>
>>>>>>>>>> Certmonger already has a way to:
>>>>>>>>>> 1) Check things periodically
>>>>>>>>>> 2) Hand certs in different places
>>>>>>>>>> 3) Run post op scripts
>>>>>>>>>>
>>>>>>>>>> IMO it is a good candidate but I would leave it to Nalin to
>>>>>>>>>> chime in.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I would expect more things that require periodic checking on clients
>>>>>>>>> beyond certificates to come in the future, so I'm not sure if doing
>>>>>>>>> this
>>>>>>>>> in certmonger is the right thing to do. Also, SSSD already does a
>>>>>>>>> similar thing for realm domains, right?
>>>>>>>
>>>>>>> Are you suggesting extending SSSD to handle that?
>>>>>>
>>>>>> Yes.
>>>>>>
>>>>>>>
>>>>>>>>>
>>>>>>>>> Honza
>>>>>>>>>
>>>>>>>>
>>>>>>>> So, does anyone have any strong opinions on this?
>>>>>>>
>>>>>>> Not at this point. BTW, is there any reason why we cannot go the
>>>>>>> simple way and
>>>>>>> just utilize cron and a script? Previously we just dropped conf to
>>>>>>> /etc/cron.d
>>>>>>> for ipa-compliance script and it worked quite well.
>>>>>>
>>>>>> Hmm, that's so simple it might just work. At least until there is a
>>>>>> better way.
>>>>>
>>>>> I have been thinking about this for some time now and came up with this
>>>>> solution:
>>>>>
>>>>> Write a library implementing the PKCS#11 API (Cryptoki), which would
>>>>> provide the shared CA certificates and associated information
>>>>> (nicknames, trust flags). The library would get the certificates from
>>>>> SSSD, which in turn would get them from IPA (and do the usual stuff like
>>>>> caching).
>>>>>
>>>>> This library could then be used by IPA NSS databases as a source of
>>>>> trust information for IPA services (see modutil). It could also be used
>>>>> by p11-glue to provide the trust information to the rest of the system.
>>>>>
>>>>> Pros:
>>>>>     * Automatic support for getting trust information stored in IPA in
>>>>> all the applications that understand PKCS#11.
>>>>>     * Certificates are fetched from IPA on-demand, not periodically like
>>>>> in the previous solutions.
>>>>>
>>>>> Cons:
>>>>>     * Complexity of implementation? (I don't know about this one, I
>>>>> briefly looked at the source code of the p11-kit PKCS#11 module and it
>>>>> looked manageable to me.)
>>>>>
>>>>> Does this sound reasonable?
>>>>
>>>>
>>>> Sounds reasonable to me, however I assume you will do some caching,
>>>> both to avoid lenghty waits and to handle offline cases, so I'd like
>>>> to know more how/when you are going to use the caches vs fetching the
>>>> cert chains from the server.
>>
>> I was thinking about using algorithm like this when SSSD receives the
>> request:
>>
>>      if certs in cache:
>>          if cache last update time + delta < now:
>>              if certs were update on server: # lastUSN check
>>                  remove certs from cache
>>              else:
>>                  cache last update time = now
>>      if certs not in cache:
>>          get certs from server
>>          store certs in cache
>>          cache last update time = now
>>      return certs in cache
>>
>> The delta would be a configurable option, defaulting to some reasonable
>> value (1 hour? more? less?)
>>
>>>
>>> For on-demand, what are we talking about, fetching the cert when the
>>> module is loaded? Or whenever someone wants to use (e.g. validate) the
>>> cert?
>>
>> Something in between - the module would request the certificates from
>> SSSD when a PKCS#11 session is opened and keep them in memory until the
>> session is closed. The point is to always have the same data between
>> PKCS#11 object management calls.
>>
>>>
>>> How often will this cert change, after all?
>>
>> Not often. Why?
>>
>>>
>>> What would the load be like? Is it fatal if the cert can't be obtained?
>>
>> The module could either return an error to the user when the certs can't
>> be obtained, or return whatever is in the cache. I'm not sure which is
>> better, but I'm leaning towards returning whatever is in the cache,
>> since this must work even when the client system is offline.
> 
> I think the cache should just be ca.crt files though, in this case, not the
> ldb modules cache. As some people wipe it out for various reasons.
> The main issue here is a chicken-egg issue if you are using LDAP(S) to
> connect to the server and you ned the CA cert to validate the server cert.
> You do not want to lock yourself out by wiping valid ca certs.

Then you can just add them to the p11-kit-trust module using the trust
tool (or I could build an API for that):

# trust anchor --store /path/to/ca.crt

By the way, even with PKCS#11, just having the certificates in place,
it's also necessary to add the appropriate trust flags and so on so that
these are trusted as anchors.

The above also handles callers that don't yet support PKCS#11 for
accessing trusted anchors.

Cheers,

Stef