4.3 Mandatory and Optional Cryptographic Algorithms
Clients that request OCSP services SHALL be capable of processing
responses signed used DSA keys identified by the DSA sig-alg-oid
specified in section 7.2.2 of [RFC2459]. Clients SHOULD also be
capable of processing RSA signatures as specified in section 7.2.1 of
[RFC2459]. OCSP responders SHALL support the SHA1 hashing algorithm.
4.4 Extensions
This section defines some standard extensions, based on the extension
model employed in X.509 version 3 certificates see [RFC2459]. Support
for all extensions is optional for both clients and responders. For
RFC 2560 PKIX OCSP June 1999
each extension, the definition indicates its syntax, processing
performed by the OCSP Responder, and any extensions which are
included in the corresponding response.
4.4.1 Nonce
The nonce cryptographically binds a request and a response to prevent
replay attacks. The nonce is included as one of the requestExtensions
in requests, while in responses it would be included as one of the
responseExtensions. In both the request and the response, the nonce
will be identified by the object identifier id-pkix-ocsp-nonce, while
the extnValue is the value of the nonce.
id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }
4.4.2 CRL References
It may be desirable for the OCSP responder to indicate the CRL on
which a revoked or onHold certificate is found. This can be useful
where OCSP is used between repositories, and also as an auditing
mechanism. The CRL may be specified by a URL (the URL at which the
CRL is available), a number (CRL number) or a time (the time at which
the relevant CRL was created). These extensions will be specified as
singleExtensions. The identifier for this extension will be id-pkix-
ocsp-crl, while the value will be CrlID.
id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 }
CrlID ::= SEQUENCE {
crlUrl [0] EXPLICIT IA5String OPTIONAL,
crlNum [1] EXPLICIT INTEGER OPTIONAL,
crlTime [2] EXPLICIT GeneralizedTime OPTIONAL }
For the choice crlUrl, the IA5String will specify the URL at which
the CRL is available. For crlNum, the INTEGER will specify the value
of the CRL number extension of the relevant CRL. For crlTime, the
GeneralizedTime will indicate the time at which the relevant CRL was
issued.
4.4.3 Acceptable Response Types
An OCSP client MAY wish to specify the kinds of response types it
understands. To do so, it SHOULD use an extension with the OID id-
pkix-ocsp-response, and the value AcceptableResponses. This
extension is included as one of the requestExtensions in requests.
The OIDs included in AcceptableResponses are the OIDs of the various
response types this client can accept (e.g., id-pkix-ocsp-basic).
RFC 2560 PKIX OCSP June 1999
id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 }
AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER
As noted in section 4.2.1, OCSP responders SHALL be capable of
responding with responses of the id-pkix-ocsp-basic response type.
Correspondingly, OCSP clients SHALL be capable of receiving and
processing responses of the id-pkix-ocsp-basic response type.
4.4.4 Archive Cutoff
An OCSP responder MAY choose to retain revocation information beyond
a certificate's expiration. The date obtained by subtracting this
retention interval value from the producedAt time in a response is
defined as the certificate's "archive cutoff" date.
OCSP-enabled applications would use an OCSP archive cutoff date to
contribute to a proof that a digital signature was (or was not)
reliable on the date it was produced even if the certificate needed
to validate the signature has long since expired.
OCSP servers that provide support for such historical reference
SHOULD include an archive cutoff date extension in responses. If
=7= |