Re: [Pki-users] [Freeipa-users] OCSP responses for an external CA

Wednesday, 28 November 2018

Hi Andrew,

Responses inline.

On Wed, Nov 28, 2018 at 05:35:11PM -0800, Andrew C Dingman via FreeIPA-users wrote:
...
 Hi, all

 I'm not sure the following is feasible, but IHAC who may want to use
 IPA in an air-gapped network while relying on smart card authentication
 using certificates from a very large, external CA. Can anyone give me
 an idea of whether the following scenario is feasible, and if so,
 supportable?

 External certificate authority E issues user certificates and
 provisions smart card tokens. (It runs RHCS, if that matters.) Inside
 the isolated network, users are separately maintained in IPA domain P.
 When each user is created in P, a certificate issued by E is added to
 the user's entry. That certificate is used for pkinit and ssl/tls
 client authentication to services in P.

 So far, my understanding is that this should be feasible provided that
 E is added as a trusted authority in various places, but I'm a little
 fuzzy on the pkinit piece. Where it gets really problematic is dealing
 with CRLs.
  Yes, so far so good.  That's all supported.

...
 Because P and its relying parties are isolated, they can't use
OCSP to
 check current validity of a certificate. To avoid the hassles of
 distributing CRLs to all relying systems and services manually, would
 it be possible to add those CRLs to the set served by the OCSP
 responder in P? Obviously the responses would be signed by P rather
 than E, but if P has verified the CRL on which they were based it seems
 at least potentially viable.
 X.509 supports delegating OCSP signing authority to 3rd parties.
But we do not support it in Dogtag or FreeIPA at this time.  It
would be complex to implement.

If they are already using RHCS, they could consider using a
standalone OCSP subsystem to service the OCSP requests.  I'm not
sure about the setup detail, i.e. whether regulary transporting
CRL(s) from the air-gapped CA to the OCSP subsystem is sufficient,
or whether LDAP replication must be used.  I've Cc'd pki-users ML
for input from people who hopefully know more about the OCSP
subsystem than I do.

On the user certificate issuance side, they are using RHCS.  So it
is straightforward to configure a profile that sets the Authority
Information Access extension to point to whatever OCSP responder
they end up using.

...

 As currently envisioned, E would be completely unaware of the existence
 of P,
 Not possible.  E must at least be aware of P to the extent that it
has issued an delegated OCSP signing certificate to P.  Otherwise
the OCSP responses issued by P, pertaining to certificates issued by
E, cannot be trusted by clients, even if they trust P as a CA.

...
 but P would trust certificates issued by E. If that isn't
 feasible, would it make any difference if P's CA were subordinate to E?
  There are some scenarios that conceptually work (e.g. P's CA
certificate, issued by E, contains the id-kp-OCSPSigning Extended
Key Usage OID).  But it is irrelevant because I do not believe there
is a way to configure a Dogtag CA subsystem to service OCSP requests
on behalf of an external CA.

...
 Thanks in advance for any guidance you can offer.
  You're welcome.

Cheers,
Fraser

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008