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

serial numbers // push/pull CRL's


Carl made several points about CRL's.  Here are some comments:

(1) Using the hash of a certificate as the name for a certificate works,
    but is very inefficient.  With MD5, this takes at least 128 bits per
    certificate.  If the issuing key gives out sequential serial numbers,
    then referring to a certificate takes space at most 32 bits, assuming
    he hasn't issued more than 2**32 certificates.  This assumes that the
    issuer is already identified, which must be the case since a CRL must
    be signed by the issuer.  Moreover, the scheme I suggested can be
    much more efficient than that, since it uses bit-arrays to say
    "revoked/non-revoked".  Sequential serial numbers make indexing into
    the bit-array possible, whereas hashes of certificates do not.

(2) Perhaps another name is needed than "revocation".  SPKI/SDSI does not,
    as Carl noted, really try to "revoke" certificates.  Anyone holding
    a previously issued certificate may legitimately go ahead and try to
    use it.  But the server he is trying to access may know that the cert
    has been revoked, and fail to honor the access request.  

    Note that it is the server (the certificate chain verifier) who is
    verifying the certificates and granting access (or honoring some
    request) based on the certificates in the chain.  

    My proposed use for CRL's was to notify such servers that some certificates
    had been revoked, so that they might not honor them.  

    I do not expect the servers to try to access the appropriate CRL's for
    each certificate in the chain.  

    Rather, the scenario I imagine is more like the following:

	I am an internet service provider.  I also support the web pages for
        company HotSoft and make access decisions for those pages based on
        certificates issued by HotSoft.  

	HotSoft may want to revoke one of its own certificates and notify
        me of this.  For example, some employee has quit the company, and
        I want to revoke the certificate declaring him to be a member of
        the "hotsoft-employee" group.  This certificate was issued with a
        one year time-out.   But I want him out now, so he can't access
        web pages only meant for employees.  The nice thing about this is
        that I am the only server that hotsoft needs to notify.  

        In this case, a crl issued by hotsoft, for my use, makes sense.  
        Hotsoft may not care to make the crl available to anyone else,   
        since here HotSoft really only cares about access to its own
        web pages (which I manage).  

   Thus the protocol for using these CRL's is different.  That is, you can
   go ahead and honor a certificate, unless it is expired or unless you 
   happen to have a CRL that cancels (revokes) that certificate.  If you don't
   have such a CRL, no one expects you to go out and get one.  It is the
   responsibility of the issuer to push the CRL out to the places he wants
   it to be, instead of expecting the certificate user to pull the latest CRL
   down when he is checking the certificate.
        
   Maybe this is enough different that we should call it something else. 

   How about "push-CRL" instead of the standard "pull-CRL"??

   Anyway, I think that push-CRL's are necessary, once you have setups such
as envisioned above with servers managing databases for clients.

Ron Rivest
Follow-Ups: