RE: Offline Root CA with valid CRL hierachie

["Santosh Chokhani" <chokhani@xxxxxxxxxxxx>]

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:steve.hanna@xxxxxxx] 
Sent: Friday, January 03, 2003 1:27 PM
To: Santosh Chokhani
Cc: ietf-pkix@xxxxxxx
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.

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.

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.
> 
> -----Original Message-----
> From: Steve Hanna [mailto:steve.hanna@xxxxxxx]
> Sent: Friday, January 03, 2003 11:45 AM
> To: Mitchell Arnone
> Cc: Santosh Chokhani; ietf-pkix@xxxxxxx
> 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.
> 
> 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