Re: Offline Root CA with valid CRL hierachie

[Steve Hanna <steve.hanna@xxxxxxx>]

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