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

Light-weight certificate revocation lists ?


The basic philosophy for SPKI/SDSI is that certificates should have relatively
short expiration times.  Revocation of certificates should be a rare event;
normally one just lets them expire.  Depending on the application, "relatively
short" may mean one year, one month, one week, or even one day, say.  

However, I think we should consider the possibility of supporting
light-weight certificate revocation lists.  That is, provide some
means of allowing an issuer to state that a certificate (or a set of
certificates) is to be considered revoked.  Receiving such a statement
tells any holder of a revoked certificate to discard it.  We do not
guarantee that the holder will receive the revocation message, or that
the holder will discard any such certificates held.  (Or that the
holder will discard any computed certificates that he has derived from
the revoked one.)  However, having the possibility of at least saying
that a certificate is revoked, and causing some amount of "clean-up"
to occur, may assist in achieving a higher level of overall security
than without such messages.  We will not support CRL's to the same
extent that X.509 does.  

I propose the following two additions to SPKI/SDSI:

(1) Allowing a certificate to have a "serial number" chosen by the issuer
    to identify the certificate.  This serial number is optional. It is
    a decimal number.  The issuer is supposed to give each
    certificate a unique number, and it may help efficiency if he
    uses consecutive numbers.  The serial number is relative to the
    *issuing-key* and not the complete issuer.  (I.e. if the issuer
    is {k,name}, then the serial number is for k.)
	( certificate
	  ( issuer I )
          ( serial-no 267 )
	  ( subject S )
          ( tag T )
          ...
        )
    Note that the serial number may be useful both for crls, and for
    on-line validation.  

(2) Have a new "certificate-revocation-list" of the form:
	( certificate-revocation-list
          ( issuer I )
          ( numbers x1 b1 x2 b2 ... xk bk ) 
        )
    Here the issuer is just a key k.
    Here each xi bi pair is used to specify a set of cancelled certificate
    numbers.  xi is the starting point, and bi is a bit-string indicating
    for certificates with serial numbers xi, xi+1, ..., whether they are
    revoked (bit=1) or not (bit=0).  Here xi is given in decimal, and bi
    with each successive byte covering eight values, lsb corresponding
    to the lowest value.  Thus, to cancel numbers 5, 17, and 19, you could
    just have
	  ( numbers 5 &01 17 &05 )
    (recall that & begins hexadecimal values. 
   
    This format allows for reasonably compact encodings, as one million
    certificates can be handled with at most 128K bytes, and the crl can
    broken up into convenient pieces.  
  
The use of consecutive serial numbers makes for reasonably efficient crl
structures.  Without these, our only choice would be to use the hash of
the certificate, and this is considerably less efficient.

Crl's will definitely be useful between a principal and its server
(in the SDSI sense)...

Ron Rivest
Follow-Ups: