Re: Offline Root CA with valid CRL hierachie

[Al Arsenault <awa1@xxxxxxxxxxx>]

Mitch,

     While I'm not a big fan of the scheme Dave Kemp suggested, there are a
couple of things useful about it.  Comments in-line, prefaced by my
initials, "AWA".


----- Original Message -----
From: "Mitchell Arnone" <marnone@xxxxxxxxxxxxxxxxxxxxxx>
To: "Santosh Chokhani" <chokhani@xxxxxxxxxxxx>; <ietf-pkix@xxxxxxx>
Sent: Friday, January 03, 2003 10:57 AM
Subject: RE: Offline Root CA with valid CRL hierachie


>
> Santosh,
>
> In todays world, CRL publication is very straight forward.  The idea
> presented by Dave would require additional functionality built into the CA
to:
>
> 1-publish not only the current CRL but many others in advance then
> 2-procedures must be developed on who, how, when and where those CRLs will
> be stored and managed and then
> 3-some other process/procedure must put into place to replace expired CRLs
> with the "current" one and
> 4-there must be even more procedures describing what to do if there is a
CA
> revocation... like destroying all existing CRLs and generating a list of
> new ones.
>
> The complexity comes in adding numerous new procedures which simply may
not
> be necessary.  These procedures, as described below, are manual and if we
> are to support a secure and reliable infrastructure, the human element
must
> be reduced if not eliminated and to do so, major revisions to CA system
> could be required.

AWA: (I firmly believe, based on about 15 years of working with PKIs, that)
The human element can *never* be eliminated from a secure and reliable
infrastructure.  Yes, the human element can be reduced to lower certain
types of security risks, and it can certainly be reduced in many places to
lower operational costs, but designing a system where an event such as
revocation of an intermediate CA can be done with no level of human review
at any point is sheer folly.  It leads to some really sweet denial of
service and other attacks (well, they're sweet from the attacker's view).



>
> I am struggling to see how publishing 30 one-day CRLs and storing them on
> some off-line media is more secure than publishing a single 30 day
> CRL.  The reaction to a CA revocation will be the same in both scenarios
> because the ROOT CA will have to be brought on-line to execute the
> revocation process and produce new updated CRLs before going back
off-line.
>

AWA:  The difference is the expiration date.  With one 30-day CRL, when you
have to revoke an intermediate CA on day 10, there is nothing to indicate to
any RP that it can't continue to rely on the original CRL, which says that
the intermediate CA is good.  So for 20 days, you've got RPs believing that
a certificate path is good based on checking a "current" CRL, when the cert
path is invalid.

With 30 one-day CRLs, the CRL expires at the end of each day.  When you have
to revoke an intermediate CA on day 10, you destroy all the pre-generated
CRLs (saying that the intermediate CA is good), and generate new one-day
CRLs saying that the intermediate CA is bad. Thus, there's no-way a
well-behaved RP could find and use a CRL that says the intermediate CA is
good after the date of revocation.  Your window of vulnerability is reduced
to the rest of that day.

Now, that being said, I'm still not a big fan of Dave's proposal.  First, I
don't know of an auditor anywhere in the world who would allow the root CA's
clock to be advanced to pre-generate one-day CRLs for the future, so that
approach is pretty much out - you'd have to have all the "thisUpdate" dates
being the same.  But since revocation of an intermediate CA is (I hope :-)
an extremely rare  event, it seems to me to be much more efficient to put
out a notice using OCSP or some other mechanism when the revocation occurs.

I'm not saying Dave's approach couldn't work; it certainly could.  And it
wouldn't significantly reduce security if the pre-generated CRLs were
properly controlled through physical/procedural means.  I'm just saying that
I don't see any real big advantage to it.

> Mitch
>

        Al Arsenault
        Chief Security Architect
        Diversinet Corp.