@techreport{gutmann-pkix-ocsp-rtcs-00,
    number =    {draft-gutmann-pkix-ocsp-rtcs-00},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-gutmann-pkix-ocsp-rtcs/00/},
    author =    {Peter Gutmann},
    title =     {{X.509 Internet Public Key Infrastructure Real-time Certificate Status Facility for OCSP - (RTCS)}},
    pagetotal = 0,
    year =      2003,
    month =     jan,
    day =       10,
    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, 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, realtime certificate store available). Fortunately, the authors of the OCSP RFC foresaw this situation by allowing a client to specify, and a responder to return, more than one type of response. Just as the original OCSP responses were designed for completely CRL- compatible operation, this document specifies a response type that is designed for real-time status operation, providing a response not from a stored CRL using CRL-only mechanisms but directly from a live certificate store. This allows the responder to provide extended information not possible with CRLs. In abstract terms, the responder is providing an implementation of an authenticated dictionary that responds to membership queries from relying parties. A conventional OCSP responder answers the question 'Is x excluded from D?', while an OCSP responder with RTCS capability answers the question 'Is x present in D?'.},
}