[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Light-weight certificate revocation lists ?
I pointed out some while ago on another list that SSL
is very well suited to the issuance of short-term
or ephemeral certificates.
It would seem, to be practical for a moment, a simple
task to make a SSL implementation which used full-blown
identity certs for its first highly public handshake,
then immediately perform a second handshake under the
negotiated confidentiality service in which both peers exchange
SPKI/SDSI certs with a view to "re"-establishing the private
trust model, agree the reduction algebra and, where necessary,
represent its processing rules programmatically, and then perform
the authorization decision.
Such ephemeral certs convey authorization data in the auth field,
and said fields may be programmatic representations of the
data (e.g. another little java applet) which inherently conveys the
necessary rules to perform whichever reduction algebra
is declared by the auth-field tag(s), for the authorization system(s)
agreed upon by conforming SPKI/SDSI cert validating systems.
To gauge whether Im getting into the SPKI/SDSI spirit, is such
a simple working concept way off course as an example
practical insertion into the existing Internet security
infrastructure of SPKI/SDSI certs?
At 05:17 PM 4/4/97 -0500, Carl Ellison wrote:
>At 10:42 AM 4/2/97 -0500, David P. Kemp wrote:
>>From my POV, the only "interesting" security-related behaviour is
>>deterministic. The non-deterministic case may be interesting from an
>>academic study, intellectual exercise POV, but I wouldn't want to deploy
>>an actual system based on it.
>
>
>Amen!
>
>
>>* But if you assume that certificates will be stored in distributed
>> repositories and local caches, then there are efficiency benefits to
>> using long-term certificates and short-term CRLs.
>
>
>I did a back of the envelope study about 1.5 years ago comparing CRL use to
>short expiration certificates, from a performance point of view. I came up
>with formulas for network traffic, number of signature checks per second,
>number of signature formations per second, etc. as functions of number of
>certificates in the system, frequency of revocation, lifetime on the cert,
>lifetime on the CRL, .... I need to resurrect that computation and post it,
>unless someone beats me to it.
>
> - Carl
>
>
>+------------------------------------------------------------------+
>|Carl M. Ellison cme@cybercash.com http://www.clark.net/pub/cme |
>|CyberCash, Inc. http://www.cybercash.com/ |
>|207 Grindall Street PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 |
>|Baltimore MD 21230-4103 T:(410) 727-4288 F:(410)727-4293 |
>+------------------------------------------------------------------+
>
>
>