[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Certificate Cancellation Notices (CCN)



	 Marc Branchaud wrote:
	 | On Sat, 5 Apr 1997, Carl Ellison wrote:
	 | > At 03:11 PM 4/5/97 -0500, Steven Bellovin wrote:
	 | > >The point of CRLs is to avoid the need for online services.  It's
	 not so
	 | > >much the replication of the database that concerns me; rather, it
	's the
	 | > >requirement that all possible acceptors of certificates be online
	 to do
	 | > >any processing whatsoever.
	 
	 | > We already have an even simpler mechanism for processing certifica
	tes
	 | > offline -- certificates with no online tests and no CRLs -- just t
	heir
	 | > own validity intervals.
	 
	 | > Offline CRLs don't magically make offline certs suddenly any more 
	precise
	 | > than certs alone whose dates are the intersection of the cert plus
	 CRL.
	 
	 | Alternatively, one could create a local CRCert with the result of ev
	ery
	 | validation.  Then when you're using your laptop on an airplane and w
	ant to
	 | verify a cert/signature, you could check your local CRCert from your
	 last
	 | verification.  If that CRCert is too old for your tastes, then you
	 | shouldn't consider the signature valid.  What makes a CRCert "too ol
	d"
	 | depends on the context -- e.g. is the message just someone wishing y
	ou a
	 | happy birthday, or is it something more important.
	 
	 	I expect that putting tests like this in front of the user
	 will lead to the default action happening every time.  So we need to
	 consider carefully what the default action should be.
	 
	 	Since certificates are not revokable, we should avoid thinking
	 that we need to look for CCNs or wandering anti-certificates.  If all
	 the useful information you have says the certificate is good, then you
	 should treat the cert as good.  If the CA is not available, then the
	 cert should stand.  The fact that the cert is older than it was when
	 you last used it is only relevant if the cert has now expired.

Very often, the real issue is the ratio of certificate holders to certificate
checkers.  Consider the case of credit cards, where there are very many
more people who have credit cards than accept them.  Given that -- and
hence given the expense of frequent reissues of cards (certificates), a
CRL-like solution is much more attractive; CRLs need only be distributed to
the much smaller set that accepts certificates (cards).

Put another way, we have an engineering tradeoff.  I strongly suspect that
there are no global solutions; too much depends on context.