Real-time Certificate Status Facility for OCSP - (RTCS)
draft-gutmann-ocsp-rtcs-00
| Document | Type | Expired Internet-Draft (individual) | |
|---|---|---|---|
| Author | Peter Gutmann | ||
| Last updated | 2003-01-13 | ||
| Stream | (None) | ||
| Formats |
Expired & archived
plain text
htmlized
pdfized
bibtex
|
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
https://www.ietf.org/archive/id/draft-gutmann-ocsp-rtcs-00.txt
Abstract
When the OCSP protocol was defined, the design was based on full compatibility with CRL-based mechanisms. This requires the use of a complex means of certificate identification that has resulted in interoperability problems among implementations, a design unsuited for high-throughput, real-time operation, the inability to provide an unambiguous certificate status response (the only thing that a CRL can say with certainty is 'revoked'), and an online responder tied to an offline mechanism (some CAs issue CRLs only once or twice a day, even though they have an online, real- time certificate store available). A more practical problem is that it makes it impossible to implement an OCSP responder not based on CRLs, for example one that consults a certificate database or in-memory hash table to determine the presence or absence of a valid certificate.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)