Subject: RE: Offline Root CA with valid CRL hierachie

From: Mitchell Arnone <[email-masked]>
Date: Fri, 03 Jan 2003 10:34:52 -0500

Ambarish,

I completely agree with you.  This is an ongoing issue when designing and 
building secure and reliable PKI implementations.

How often a client or service provider (both as relying parties) retrieves 
an updated CRL is dependant on the intended use of the PKI.  It all comes 
down to risk mitigation and associated costs.  If you are protecting highly 
sensitive information then maybe you need to support frequent checking of 
CRLs and if this is the case then maybe you need to deploy a LDAP farm 
fronted by some sort of HA device or maybe you deploy a smaller scale LDAP 
deployment and push certificate status checking to an OCSP responder which 
too may be integrated into an HA solution.  However, this can become very 
costly and if the cost outweighs the value of the information being 
protected, then there needs to be a balancing act between cost and risk.

Relying parties, especially service providers, need to be configurable 
allowing an administrator to determine the frequency in which an updated 
CRL is fetched.  There may be a situation where different relying parties 
have different intervals, based on risk.  In addition, administrators must 
be able to issue a command to the service front end (that is responsible 
for CRL checking) telling it to go out and fetch a new CRL 
immediately.  This is important for these cases when there is an emergency 
revocation early in the validity period of a CRL.

In most CP/CPS documents, reference is made to emergency certificate 
revocation and notification of relying parties in such cases.  However, if 
the relying party either cannot or does not effect an immediate retrieval 
of an update CRL, then emergency revocation procedures are useless.

Mitch

At 04:52 PM 12/31/2002, Ambarish Malpani wrote:

>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
>
>
>
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Mitchell Arnone
> > Sent: Monday, December 30, 2002 5:13 PM
> > To: David P. Kemp; [email-masked]
> > Subject: Re: Offline Root CA with valid CRL hierachie
> >
> >
> >
> > 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
> >
> > At 11:01 AM 12/30/2002, David P. Kemp wrote:
> >
> > >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
> > >
> > >
> > >
> > >
> > >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".
> > > >
> > > > ----- 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
> > > >
> > > > >
> > > > > > 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.
> >
> > ***********************************************************
> > Mitchell Arnone
> > Managing Consultant
> > SchlumbergerSema
> > Technical Consulting Practice, Northeast Region
> > Network & Infrastructure Solutions
> >
> > [email-masked]
> > www.slb.com/nws
> >
> > 35 Waterview Blvd.
> > Suite 210
> > Parsippany, NJ 07054-1200
> > USA
> >
> > Phone  +1 410-579-8691
> > Mobile  +1 443-864-1590
> >
> >

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

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

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

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

---

From: Mitchell Arnone <[email-masked]>
Date: Fri, 03 Jan 2003 10:57:28 -0500

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.

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.

Mitch

At 10:57 AM 12/31/2002, Santosh Chokhani wrote:

>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.
>
>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of Mitchell Arnone
>Sent: Monday, December 30, 2002 8:13 PM
>This sounds like a very complex technical solution that circumvents proper
>assurance.  The Root CA is the root of trust and therefore must live up to
>A CRL can be generated by an off-line Root CA where the next update can be
>"thisUpdate".  Depending on this setting, and assuming that no subordinate
>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
>immediately following the revocation, the Root CA can generate and publish
>The burden of obtaining a current CRL is on the Relying Party where it must
> >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".
> > >
> > > > > 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.
> > > >
> > >
> > > 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
> > > > 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
> > >
> > >    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
> > > 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: Steve Hanna <[email-masked]>
Date: Fri, 03 Jan 2003 11:44:39 -0500

Mitchell Arnone wrote:
> 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 difference arises if an attacker can interfere with
the distribution of new CRLs (replacing the new ones with
old ones, etc.). It's generally much easier to compromise
an online web or directory server than it is to compromise
an offline CA, so this is a very real concern.

In this case, publishing a 30 day CRL allows revoked certs
to continue to work for up to 30 days. Publishing 30 one-day
CRLs (one at a time, ensuring that later ones are not published
prematurely) means that the worst an attacker can do is block
all CRLs (Denial Of Service). They can't make a revoked cert
work for more than 1 day.

As you say, pre-issuing CRLs adds some complexity and is
not supported by most CA software. I suggest two alternative
solutions:

1) Have the offline CA use a separate CRL issuer that can be
   easily activated. The CRL issuer can issue CRLs every day.

2) Use OCSP. Update the OCSP responder promptly when a cert
   is revoked.

Both of these solutions are well supported by the standards
and don't require any special mechanisms.

Steve Hanna

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 3 Jan 2003 11:49:42 -0500

Mitch:

Please see responses in-line in [].

-----Original Message-----
From: Mitchell Arnone [mailto:[email-masked]] 
Sent: Friday, January 03, 2003 10:57 AM
To: Santosh Chokhani; [email-masked]
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
[My scheme calls for publishing CRLs one at a time, not many others]

 then 2-procedures must be developed on who, how, when and where those CRLs
will 
be stored and managed
[My proposal was for those who control the private key and/or cryptographic
module and associated private key activation data will do this]

 and then
3-some other process/procedure must put into place to replace expired CRLs 
with the "current" one
[If the CA is truly off-line, you will need to carry the CRL to network
connected directory any way.  You just take the CRL in the same medium as
you would otherwise]

 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.
[This simple to do.  What you get in return is security and operational
convenience]

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.
[The reason it is more secure is that if you issue a CRL whose nextUpdate is
thirty days later, then if anything happens during those thirty days, you
are vulnerable to old CRL replay attack.  The only way to mitigate that risk
is to trust both the directory and the communication pipe you as RP build to
it.  With the approach I suggest, the window of vulnerability is one day
since the CRL gets to the directory daily.  If any day, a CA needs to be
revoked, you create new CRLS.  Since no one had those pregenerated CRLs, you
are not vulnerable to their use]

Mitch

At 10:57 AM 12/31/2002, Santosh Chokhani wrote:

>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.
>
>[mailto:[email-masked]] On Behalf Of Mitchell Arnone
>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.
>
>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 
>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
>
> >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 
> >flushed
> > > "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 
> > > > I agree that you still publish a valid CRL for an offline Root 
> > > > CA. The problem is the following,
> > > 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.
> > >
> > > > two week period that the intermediate CA is compromised, taking 
> > > > in account:"Conforming applications are NOT REQUIRED to support 
> > > 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 
> > > 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...)
> > >
> > > 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

35 Waterview Blvd.
Suite 210

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

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 3 Jan 2003 11:59:04 -0500

Steve:

While CRL issuer may be well supported by the Standards, many commercial
products do not handle indirect CRL well.

Separately, some RP (client side software) require the CRL to be signed by
the same key as the certificate with no regard for re-key or separate keys
for certificate and CRL signing.

-----Original Message-----
From: Steve Hanna [mailto:[email-masked]] 
Sent: Friday, January 03, 2003 11:45 AM
To: Mitchell Arnone
Cc: Santosh Chokhani; [email-masked]
Subject: Re: Offline Root CA with valid CRL hierachie

Mitchell Arnone wrote:
> 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.

In this case, publishing a 30 day CRL allows revoked certs
to continue to work for up to 30 days. Publishing 30 one-day CRLs (one at a
time, ensuring that later ones are not published
prematurely) means that the worst an attacker can do is block all CRLs
(Denial Of Service). They can't make a revoked cert work for more than 1
day.

Steve Hanna

---

From: Al Arsenault <[email-masked]>
Date: Fri, 03 Jan 2003 13:11:09 -0500

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" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>; <[email-masked]>
Sent: Friday, January 03, 2003 10:57 AM
Subject: RE: Offline Root CA with valid CRL hierachie

> be reduced if not eliminated and to do so, major revisions to CA system

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).

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

        Al Arsenault
        Chief Security Architect
        Diversinet Corp.

---

From: Steve Hanna <[email-masked]>
Date: Fri, 03 Jan 2003 13:27:10 -0500

I agree that there are many products (CAs and RPs) that
don't support indirect CRLs yet. That is also true of
policy constraints, name constraints, and many other
features of RFC 3280. In fact, most RPs don't support
revocation checking at all! I hope these deficiencies
will be remedied soon as customers start to require
RFC 3280 compliant path validation in RFPs.

So one of the main advantages of the system you propose
is that it can work with RPs that support revocation
checking by CRL, but not indirect CRLs or OCSP. I wonder
how common that will be. I'm sure there will be some
such RPs.

-Steve

P.S. I see that RFC 3280 RECOMMENDS that RPs support
indirect CRLs, but it doesn't REQUIRE them to do so.
I hope that support for indirect CRLs will be common.
Indirect CRLs have benefits beyond the ability to
issue regular CRLs without having to put the CA online
or pre-issue CRLs. They also allow several CAs to share
a single CRL, which is especially useful for CAs that
rarely revoke certificates. Of course, they do require
more work for the relying party, since they must validate
the CRL issuer's cert.

---

From: Mitchell Arnone <[email-masked]>
Date: Fri, 03 Jan 2003 14:10:51 -0500

All points raised on this issue have been well stated.  I do believe that 
Dave's approach could work but my concern is that I too do not see any real 
advantage to it.  The 30 day CRL might be OK if the directories are secured 
and scaled properly and the 30 1day CRLs might be OK if the stack of 
pre-generated CRLs are secured and published properly.  I just think there 
is a better solution the likes of which others on this list have already 
commented.  Personally I like the OCSP approach but even that does not 
mitigate the need for an effective CRL publishing strategy.

Thanks

Mitch

35 Waterview Blvd.
Suite 210

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

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 3 Jan 2003 14:10:26 -0500

Steve:

I am thoroughly confused.  First, what I am proposing will work if the RP is
using indirect CRL.  I am making a modest assumption that an RP that can
process indirect CRL can also process full and complete CRL.

In terms of OCSP, if your solution is OCSP only, I still think the approach
I suggest will be a good way to supply the revocation information to the
OCSP responders, specially if there are many of them or if you want to the
convenience of distributing the revocation information over untrusted
networks.

Again I am making a modest assumption that the OCSP Responders should get
their revocation information from the issuer.  This being off-line Root, it
is not going to be the OCSP Responder for itself.  

How the OCSP Responder for off-line root revocation should be architected is
a separate topic with its own nuances.    

-----Original Message-----
From: Steve Hanna [mailto:[email-masked]] 
Sent: Friday, January 03, 2003 1:27 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: Offline Root CA with valid CRL hierachie

I agree that there are many products (CAs and RPs) that
don't support indirect CRLs yet. That is also true of
policy constraints, name constraints, and many other
features of RFC 3280. In fact, most RPs don't support revocation checking at
all! I hope these deficiencies will be remedied soon as customers start to
require RFC 3280 compliant path validation in RFPs.

-Steve

Santosh Chokhani wrote:
> 
> Steve:
> 
> While CRL issuer may be well supported by the Standards, many 
> commercial products do not handle indirect CRL well.
> 
> Separately, some RP (client side software) require the CRL to be 
> signed by the same key as the certificate with no regard for re-key or 
> separate keys for certificate and CRL signing.
> 
> > 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.
> 
> to continue to work for up to 30 days. Publishing 30 one-day CRLs (one 
> at a time, ensuring that later ones are not published
> (Denial Of Service). They can't make a revoked cert work for more than 
> 1 day.
> 
> Both of these solutions are well supported by the standards and don't 
> require any special mechanisms.
> 
> Steve Hanna

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 3 Jan 2003 14:15:44 -0500

Mitch:

OCSP for Root raises its own issue in terms of Responder trust and responder
revocation (if a certificate based approach is used (vice trust anchor))
checking.

-----Original Message-----
From: Mitchell Arnone [mailto:[email-masked]] 
Sent: Friday, January 03, 2003 2:11 PM
To: Al Arsenault; Santosh Chokhani; [email-masked]
Subject: Re: Offline Root CA with valid CRL hierachie

Thanks

Mitch

At 01:11 PM 1/3/2003, Al Arsenault wrote:
>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.

35 Waterview Blvd.
Suite 210

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

---

From: Steve Hanna <[email-masked]>
Date: Fri, 03 Jan 2003 14:42:41 -0500

Santosh Chokhani wrote:
> I am thoroughly confused.  First, what I am proposing will work
> if the RP is using indirect CRL.  I am making a modest assumption
> that an RP that can process indirect CRL can also process full and
> complete CRL.

Right. The primary benefit of pre-issued CRLs over indirect
CRLs or OCSP is that pre-issued CRLs work with any RP that
can process CRLs (any RFC 3280 compliant RP) whereas the
others require support for features not required by RFC 3280.

> In terms of OCSP, if your solution is OCSP only, I still
> think the approach I suggest will be a good way to supply the
> revocation information to the OCSP responders, specially if
> there are many of them or if you want to the convenience of
> distributing the revocation information over untrusted networks.

I don't know much about how people generally supply
revocation information to OCSP responders. Certainly,
I expect that your system would work fine. But I expect
that many OCSP responders would support indirect CRLs,
so that might also be a solution. And some people might
just use SSH. I don't know.

> How the OCSP Responder for off-line root revocation should be
> architected is a separate topic with its own nuances.

I didn't think we were discussing how to revoke a root.
As you say, that's a separate topic. Let's leave it aside
for now, unless there's some pressing need to address it.

-Steve

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 3 Jan 2003 15:28:53 -0500

Steve:

The question is not of Root revocation, but of establishing trust in and
checking the revocation status (if the trust is certificate based) of the
OCSP Responder itself.

In the other comments, I do not see an area where you disagree with me.  If
you do, please point that out to me.

-----Original Message-----
From: Steve Hanna [mailto:[email-masked]] 
Sent: Friday, January 03, 2003 2:43 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: Offline Root CA with valid CRL hierachie

Santosh Chokhani wrote:
> I am thoroughly confused.  First, what I am proposing will work if the 
> RP is using indirect CRL.  I am making a modest assumption that an RP 
> that can process indirect CRL can also process full and complete CRL.

Right. The primary benefit of pre-issued CRLs over indirect CRLs or OCSP is
that pre-issued CRLs work with any RP that can process CRLs (any RFC 3280
compliant RP) whereas the others require support for features not required
by RFC 3280.

> In terms of OCSP, if your solution is OCSP only, I still think the 
> approach I suggest will be a good way to supply the revocation 
> information to the OCSP responders, specially if there are many of 
> them or if you want to the convenience of distributing the revocation 
> information over untrusted networks.

-Steve

---

From: "Ambarish Malpani" <[email-masked]>
Date: Fri, 3 Jan 2003 13:20:49 -0800

Hi Mitch,
    With OCSP, you can get around most of the CRL publishing issues.
One of the features I added to the Valicert OCSP responder (VA), was
to allow it (under operator control), to accept expired CRLs for a
fixed amount of time.

If the CA is operating the VA, it can issue a single CRL
and have the VA trust it for as long as he wishes to - for example
issue the CRL for a day, but have the responder trust it for 30. If
a new revocation needs to happen, you publish the new CRL to the VA,
which now starts trusting the new CRL (and no longer depends on the
old one).

It is also perfectly possible to have the VA run on its own data and
not rely on the CA software for revocation data at all - I know at
least one CA that chose to operate in that way (even though they
were operating both the CA and the VA themselves).

Regards,
Ambarish

> Sent: Friday, January 03, 2003 11:11 AM

---

From: Steve Hanna <[email-masked]>
Date: Tue, 07 Jan 2003 12:49:36 -0500

I don't think we disagree substantially. We discussed a few
different ways to provide timely revocation with an offline CA,
pointing out some of the pros and cons of each technique.
We may not agree on which technique is best, but ultimately
that's up to the CA operator.

-Steve