Subject: Offline Root CA with valid CRL hierachie

From: "Haaino Beljaars" <[email-masked]>
Date: Sun, 22 Dec 2002 14:47:58 +0100

Hi,

Hopefully somebody can help me out.

I want to create the following hierarchie:

An offline Root CA and 2 intermediate CA's which are directly issues by the
Root CA.

The following is the problem. Since the Root CA is offline, it can not CRL's
on a frequent base.
How can I then revoke one of the intermediate CA's?
As far as I know there are at least two possible scenarios.

1) The intermediate CA revokes itself. But that could be difficult in case
of a key compromise. And
I wonder whether or not it is possible for a CA to revoke itself????

2) The Root CA revokes the intermediate CA's.
But since this is a offline CA, this could be difficult. I cannot create a
constantly valid CRL as far as I know?
Solution a) could be that I create a CRL when an enormous time to live,
which I think is not the
way to go because no application sees any reason to retrieve a new CRL.
Solution b) could be that
I let a different CA issue the CRL for the Root CA. But this solution also
have some probles,
according to RFC 3280, par. 5.0 "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."
And what if the CRL issuing CA is the CA that has to be revoked?

Could anybody help me out? How can I create a hierachie with an offline Root
CA, which has a valid CRL structure?

Best regards,
Haaino

---

From: Mark Scherling <[email-masked]>
Date: Sun, 22 Dec 2002 11:10:43 -0800

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.

---

From: "Haaino Beljaars" <[email-masked]>
Date: Mon, 23 Dec 2002 12:36:29 +0100

> the onus is on the relying party to verify that an intermediary CA is
still

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

Best regards,
Haaino

---

From: Al Arsenault <[email-masked]>
Date: Mon, 23 Dec 2002 08:40:56 -0500

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" <[email-masked]>
To: "Mark Scherling" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, December 23, 2002 6:36 AM
Subject: Re: Offline Root CA with valid CRL hierachie

> > the onus is on the relying party to verify that an intermediary CA is

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?

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

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.

> Haaino

Hope this helps.

                    Al Arsenault
                    Chief Security Architect
                    Diversinet Corp.

---

From: "Joel S. Kazin" <[email-masked]>
Date: Mon, 23 Dec 2002 09:27:51 -0500

This works fine in practice. Last year I was involved in the implementation 
of a three tiered PKI for a major oil and gas company. Both the top tier 
(one CA) and intermediate tier (two CAs) are off line. Only the issuing 
level (3 CAs) is on line. The CP for the issuing level states that the 
relying party must check the entire chain - three CRLs. The nesting of the 
CRL expiration dates requires some advance planning.

>with a scope other than all certificates issued by one CA"?

Senior Consultant
Technical Consulting Practice, Northeast Region
Schlumberger Network Solutions

[email-masked]
www.slb.com/nws

35 Waterview Blvd.
Suite 210
Parsippany, NJ 07054-1200
USA

Phone  +1 914-769-8780
Mobile  +1 914-645-5598

---

From: "David P. Kemp" <[email-masked]>
Date: Mon, 30 Dec 2002 11:01:04 -0500

Because revocation of a signing CA should be very rare event, the
offline root can take advantage of a "long pipeline" to minimize
the human effort required to transport disks of CRLs to an online
repository.  The root could pre-generate, say, one week's worth of
empty daily CRLs (where nextUpdate = thisUpdate + 1 day) and put
the 7 CRLs on media.  The repository would then be responsible
for doling out the correct CRL each day and not publishing any
CRL for which thisUpdate is in the future.

In the event of a CA compromise, the pipeline would need to be
flushed - future CRLs in the repository would be destroyed and
the root CA would generate a new batch of CRLs on media.

This assumes that compromise of the online repository (allowing
access to CRLs up to 7 days in the future) is a much less serious
event than compromise of the offline root CA.  I believe that
assumption is valid and supportable.

Dave

---

From: "Joel S. Kazin" <[email-masked]>
Date: Mon, 30 Dec 2002 12:57:26 -0500

What would the CRL contain in the thisUpdate and nextUpdate attribute 
fields? There are at least two different approaches -  thisUpdate is the 
same in all the CRLs and  nextUpdate changes the other thisUpdate and 
netUpdate get incremented by say a week for each CRL. For the latter you 
would need to change the root CA's clock.

Senior Consultant

35 Waterview Blvd.
Suite 210

Phone  +1 914-769-8780
Mobile  +1 914-645-5598

---

From: Mitchell Arnone <[email-masked]>
Date: Mon, 30 Dec 2002 20:13:26 -0500

Dave,

This sounds like a very complex technical solution that circumvents proper 
procedures designed to maintain a significantly high level of 
assurance.  The Root CA is the root of trust and therefore must live up to 
the highest level of assurance attested to by a particular PKI.

CRLs must be generated on the date and at the time they become 
effective.  Predicting contents of a CRL and generating them in advance 
leaves much room and opportunity to render a PKI untrustworthy.

A CRL can be generated by an off-line Root CA where the next update can be 
one day, one month or even one year from the date contained in 
"thisUpdate".  Depending on this setting, and assuming that no subordinate 
CA certificates have been revoked prior to the normally scheduled update 
period, the off-line Root CA can be brought on-line allowing it to generate 
and publish a fresh CRL.  In the event that a subordinate CA certificate is 
revoked, obviously the Root CA must brought on-line to do so and 
immediately following the revocation, the Root CA can generate and publish 
an updated CRL.  This is the proper way to handle an Off-line Root CA.

The burden of obtaining a current CRL is on the Relying Party where it must 
periodically refresh its CRL regardless of whether the "nextUpdate" has 
been reached or not.  A Relying Party can flush its cache at prescribed 
intervals and then retrieve a new (updated) CRL as required.

Mitch

> > floppy, CD - from the off-line CA to the network-connected 

***********************************************************
Mitchell Arnone
Managing Consultant
SchlumbergerSema
Technical Consulting Practice, Northeast Region
Network & Infrastructure Solutions

[email-masked]
www.slb.com/nws

35 Waterview Blvd.
Suite 210

Phone  +1 410-579-8691
Mobile  +1 443-864-1590

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 31 Dec 2002 10:57:02 -0500

Mitch:

What I interpreted from Dave's e-mail is as follows:

1.  For operational security and operational workload reasons, we may not
want to bring the off-line Root on-line to generate the CRL too often.

2.  For security reasons, we also want the Root CRL to have a relatively
current nextUpdate (vice one month or one year from now).

3.  To meet these two, the root CA generates a bunch of CRLs in advance with
thisUpdate not of the current time, but desired times in the future and
nextUpdate also of various desired times in the future.

4.  One can put these CRLs on portable media and control them under the same
physical and procedural controls that Root CA and associated private key
activation is controlled.

5.  Most of the time, a CA will not be revoked and hence the proper portable
medium can be carried to the repository and CRL published.

6.  If a CA is revoked, root CA will be booted up, all  the portable media
will be erased and root CA will generate a bunch of new CRLs using step 3.

This does not sound technically complex to me.  It does require some
procedural controls for additional items, namely portable media for the
future CRLs. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Mitchell Arnone
Sent: Monday, December 30, 2002 8:13 PM
To: David P. Kemp; [email-masked]
Subject: Re: Offline Root CA with valid CRL hierachie

Dave,

Mitch

At 11:01 AM 12/30/2002, David P. Kemp wrote:

>offline root can take advantage of a "long pipeline" to minimize the 
>human effort required to transport disks of CRLs to an online 
>empty daily CRLs (where nextUpdate = thisUpdate + 1 day) and put the 7 
>CRLs on media.  The repository would then be responsible for doling out 
>the correct CRL each day and not publishing any CRL for which 
>thisUpdate is in the future.
>
>In the event of a CA compromise, the pipeline would need to be flushed 
>- future CRLs in the repository would be destroyed and the root CA 
>would generate a new batch of CRLs on media.
>
>This assumes that compromise of the online repository (allowing access 
>to CRLs up to 7 days in the future) is a much less serious event than 
>compromise of the offline root CA.  I believe that assumption is valid 
>and supportable.
>
>Dave
>
>
>
>
>Al Arsenault wrote:
> >
> > 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".
> >
> > > > 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
> > > > 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;
> > > 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
> > > 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
> >
> > 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.
> >
> > >over two weeks,  but in reality that intermediate CA is revoked. 
> > >How can I let everybody
> > know
> > > during that
> > > account:"Conforming applications are NOT REQUIRED to support 
> > > processing of delta CRLs,
> > indirect
> > > CRLs, or CRLs
> > 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.
> >
> > 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.

35 Waterview Blvd.
Suite 210

Phone  +1 410-579-8691
Mobile  +1 443-864-1590

---

From: "Ambarish Malpani" <[email-masked]>
Date: Tue, 31 Dec 2002 13:52:42 -0800

Hi Mitchell,
    As a CA, you can tell the RP (relying party) that it is
responsible for fetching the latest CRL. If you then give it
no way of knowing when to get a new CRL, any serious security
client would keep checking for a new CRL *every* time it needed
to validate a certificate/certification path.

As a root CA, it is very unlikely that your directory could handle
the load you would get from every client trying to get your latest
CRL for every certificate that chains up to you (*distribution* is
the real scalability problem with CRLs - as opposed to OCSP - not
generation).

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani                                         650.759.9045
Malpani Consulting Services                      [email-masked]
http://www.malpani.biz

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Mitchell Arnone
> Sent: Monday, December 30, 2002 5:13 PM
> > > > > on-line often.  In many cases the Root CA is off-line and
> only used to
> > > > issue
> > > > > each time the CA is removed, etc. )  The reason for
> documenting the
> > > > process
> > > > > is for audit purposes.
> > > > >
> > > > > the onus is on the relying party to verify that an
> intermediary CA is
> > > > still
> > > > > valid.
> > > >
> > >
> > > > issuing the CRL I take it offline. During that month, for
> example after
> > > two
> > > > weeks, one of the
> > > > According to the specs I can only issue a CRL which has a
> validity time
> > > that
> > > > starts after
> > > > current one.
> > >
> > > > but in reality that intermediate CA is revoked. How can I
> let everybody
> > > know
> > > > during that
> > > 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
> > > identical to the previous one - as often as you want; e.g.,
> every day,
> > every