Re: Offline Root CA with valid CRL hierachie

[Al Arsenault <awa1@xxxxxxxxxxx>]

Okay, I'm a little confused here.  This problem isn't really all that hard
to solve. My comments/questions are in-line, prefaced by my initials, "AWA".

----- Original Message -----
From: "Haaino Beljaars" <beljaars@xxxxxxxxxxxx>
To: "Mark Scherling" <markscherling@xxxxxxx>
Cc: <ietf-pkix@xxxxxxx>
Sent: Monday, December 23, 2002 6:36 AM
Subject: Re: Offline Root CA with valid CRL hierachie


>
> > You can still publish a CRL for an off-line CA.  You will need to
> establish
> > a fairly long expiry time for the CRL if you do not plan to bring the CA
> > on-line often.  In many cases the Root CA is off-line and only used to
> issue
> > new intermediary CAs or revoke intermediary CAs.  You will need to
> establish
> > a very good procedure for startup and shutdown of the root CA (two
person
> > control, locked in a safe, two person combination on the safe,
documenting
> > each time the CA is removed, etc. )  The reason for documenting the
> process
> > is for audit purposes.
> >
> > You will also need to document in your CP that the CA is off-line and
that
> > the onus is on the relying party to verify that an intermediary CA is
> still
> > valid.
>


AWA:  Let's first clarify terms.  What, exactly, do you mean by "off-line
CA"?  To me, that term means that the CA is not connected to a larger
network (specifically, it's not connected to the Internet or larger telecom
network through which it can be accessed).  It's still running, locked in
its secure facility somewhere.  That is, start-up/shut-down is not an issue;
it's already running.  Is that what you mean, or is there something else?


> I agree that you still publish a valid CRL for an offline Root CA. The
> problem is the following,
> example: I issue an CRL with the Root CA with a validity of for example a
> month, and after
> issuing the CRL I take it offline. During that month, for example after
two
> weeks, one of the
> intermediate CA's is compromised and I have to revoke that CA.
> According to the specs I can only issue a CRL which has a validity time
that
> starts after
> current one.

AWA:  I'm not sure you're interpreting RFC 3280 correctly.  Paragraph
5.1.2.5 starts:

  5.1.2.5  Next Update

   This field indicates the date by which the next CRL will be issued.
   The next CRL could be issued before the indicated date, but it will
   not be issued any later than the indicated date.  CRL issuers SHOULD
   issue CRLs with a nextUpdate time equal to or later than all previous
   CRLs.  nextUpdate may be encoded as UTCTime or GeneralizedTime.

That is, you can only issue a CRL whose "thisUpdate" time is later than the
previous one, and whose nextUpdate time is equal to or later than those on
previous CRLs (although that latter part is not required).  There's no
reason why you have to wait until the current CRL expires to issue the new
one.


>This means in practise that I have a valid intermediate CA for
> over two weeks,
> but in reality that intermediate CA is revoked. How can I let everybody
know
> during that
> two week period that the intermediate CA is compromised, taking in
> account:"Conforming
> applications are NOT REQUIRED to support processing of delta CRLs,
indirect
> CRLs, or CRLs
> with a scope other than all certificates issued by one CA"?
>

AWA:  Okay, here's how I've solved this problem in the past.  The root CA,
while off-line, is running in its secure facility.  When it is necessary to
revoke an intermediate CA, the root CA is accessed to create a new CRL.
This CRL is dumped to some medium, either burned onto a CD or put onto a
floppy.  This medium is then hand-carried (the term we used to use was "sent
via sneaker-net") to a server that is on the network.  It can be either made
available as a CRL from, e.g., an LDAP repository; or it can be provided to
an OCSP responder.

The rest is up to your revocation policy.  If you rely only on CRLs, and you
allow users to cache CRLs until the end of their validity period (e.g.,
until their "nextUpdate" time), then yes, you have in your scenario a
two-week window of vulnerability where users think an intermediate CA is
good but it's really not.  That's a risk you take by relying only on static
CRLs with that long a validity period. (Of course, one would hope that
revocation of an intermediate CA would be an extremely rare event, so the
overall system risk/cost tradeoff may be acceptable, but...)

On the other hand, you can use an OCSP-based system, where users query the
responder and will discover that the intermediate CA has been revoked the
first time they query its status.  OR you can use CRLs with a shorter life
cycle.  Depending on what you're willing to pay in "human capital" costs,
there's no reason you can't have the off-line CA issue a new CRL - generally
identical to the previous one - as often as you want; e.g., every day, every
4 hours, whatever.  It just costs you to have the human move the medium -
floppy, CD - from the off-line CA to the network-connected repository.  It's
not that hard.



> Best regards,
> Haaino
>

Hope this helps.


                    Al Arsenault
                    Chief Security Architect
                    Diversinet Corp.