[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.