[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Offline Root CA with valid CRL hierachie
Mitch:
Please see responses in-line in [].
-----Original Message-----
From: Mitchell Arnone [mailto:marnone@xxxxxxxxxxxxxxxxxxxxxx]
Sent: Friday, January 03, 2003 10:57 AM
To: Santosh Chokhani; ietf-pkix@xxxxxxx
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]
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.
[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:
>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: owner-ietf-pkix@xxxxxxxxxxxx
>[mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf Of Mitchell Arnone
>Sent: Monday, December 30, 2002 8:13 PM
>To: David P. Kemp; ietf-pkix@xxxxxxx
>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" <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.
>
>***********************************************************
>Mitchell Arnone
>Managing Consultant
>SchlumbergerSema
>Technical Consulting Practice, Northeast Region
>Network & Infrastructure Solutions
>
>marnone@xxxxxxxxxxxxxxxxxxxxxx
>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
marnone@xxxxxxxxxxxxxxxxxxxxxx
www.slb.com/nws
35 Waterview Blvd.
Suite 210
Parsippany, NJ 07054-1200
USA
Phone +1 410-579-8691
Mobile +1 443-864-1590