Subject: RE: Huge CRLs

From: "Salz, Rich" <[email-masked]>
Date: Wed, 15 Sep 1999 11:00:52 -0400

>but if anybody ever
>manages to break into your responder and get access to your private
>key, your whole OCSP response system is open to compromise.

Uh yeah, so?  "If the private key of XXX is compromised than the
service that XXX provides becomes suspect."  Without getting into
the whole recent NR thread, this really does verge on a PK tautology,
doesn't it?

Depending on the protection needed, there are a number of approaches,
including tamper-evident hardware, distributed signing using various
key-splitting methods, etc.

>With CRTs, you can acctually have the Tree Issuer be separate from
>the CRT responders. The Tree Issuer has access to your CRT private
>key and can create new CRTs, which it then distributes to one or
>more CRT responders (which don't have the highly trusted private
>key), which actually provide the CRT responses.

A CA can delegate it's CRL signing to another entity by asserting
the crlSign keyUsage bit.  The scheme you describe above might have
efficiencies over CRL's, but it certainly introduces latency. But
most importantly, I don't see how your scheme is different from
crlSign delegation.

Your initial note on this subject said CRT's are better than OCSP,
but from what I've read so far, I conclude that CRT's essentially the
same as CRL's, except that they're proprietary technology.
	/r$

---

From: [email-masked] (Terry Hayes)
Date: Wed, 15 Sep 1999 14:03:46 -0700

> most importantly, I don't see how your scheme is different from

Whoa!  Is this right?  It's my understanding that the CA can delegate CRL
signing only by including a Distribution Point extension in the
certificates that it issues.  This extension may point at another subject
name that may create and sign CRLs for the CA.

Setting the crlSign bit is normal for creating subordinate CAs, and does
not usually indicate that the original CA means to delegate CRL creation
and signing.

Terry