Online Certificate Status Protocol Algorithm Agility
obsoleted by
- rfc-6960 — X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
updates
- rfc-2560 — X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
Extracted elements (17)
A responder may intentionally employ a different signature algorithm than the CA uses for certificates and CRLs: a less computationally expensive algorithm may suffice for status responses, and using two independent algorithms guards against a single algorithm compromise affecting both certificate issuance and status.
The MITM downgrade risk on the preferred-algorithms extension is accepted as not significant because the protocol's security does not depend on the extension being integrity-protected: the responder's own policy and the client's independent verification both serve as backstops.
The pubKeyAlgIdentifier field in PreferredSignatureAlgorithm is made OPTIONAL and uses SMIMECapability syntax specifically to allow clients to distinguish among different parameterizations of an algorithm, such as specifying which elliptic curve they support for a given EC algorithm.
Heuristics such as matching the algorithm used by the CA to sign CRLs may fail when the OCSP responder's key pair is incompatible with that algorithm, or when the request is for an unknown certificate that provides no basis for algorithm selection.
RFC 2560 specifies how a responder indicates the algorithms used in a response but provides no mechanism for clients to signal which algorithms they support, creating a risk that a responder choosing a non-mandatory algorithm will produce a response the client cannot verify.
A client MUST accept any signing algorithm in a response that it specified as a preferred signing algorithm in the request. Therefore, a client MUST NOT specify a preferred signing algorithm that is not supported or not considered acceptably secure.
A dynamic OCSP responder SHOULD always apply the lowest-numbered selection mechanism from the defined precedence list that results in a known, supported algorithm meeting the responder's cryptographic strength criteria.
Clients requesting OCSP services SHALL be capable of processing responses signed using RSA with SHA-1 (sha1WithRSAEncryption) and RSA with SHA-256 (sha256WithRSAEncryption). Clients SHOULD also be capable of processing responses signed using DSA keys (id-dsa-with-sha1). Clients MAY support other algorithms.
For static (pre-generated) responses, the responder SHOULD still use the client request data during selection of the pre-generated response to be returned, even though the response itself was generated in advance.
The client MUST support each of the specified preferred signature algorithms listed in the extension, and MUST specify the algorithms in order of preference from most preferred to least preferred.
The mechanism used to choose the response signing algorithm MUST be considered sufficiently secure against cryptanalytic attack for the intended application.
A PreferredSignatureAlgorithms extension (OID id-pkix-ocsp-pref-sig-algs, arc id-pkix-ocsp 8) may be included in the requestExtensions of an OCSPRequest to advertise the client's ordered list of preferred signature algorithms.
For dynamic responses, the responder MAY select its signing algorithm using a five-level precedence: (1) client's preferred algorithm, (2) algorithm used to sign the issuer's CRL, (3) algorithm used to sign the OCSPRequest, (4) out-of-band advertised default, (5) mandatory/recommended algorithm for the OCSP protocol version.
Algorithm agility introduces a slightly increased denial-of-service attack surface because a client request may be altered to require algorithms not supported by the server. RFC 4732 denial-of-service considerations apply.
In archival applications querying certificate status for dates in the distant past, a responder MUST NOT generate a signature using a signing mechanism that is no longer considered acceptably secure, even if the certificate itself used that mechanism.
The preferred signature algorithms extension is not protected against a man-in-the-middle downgrade attack. This is mitigated because the responder MUST NOT sign using weak algorithms even if requested, and the client can independently reject responses not meeting its cryptographic security criteria.
PreferredSignatureAlgorithms is a SEQUENCE OF PreferredSignatureAlgorithm. Each PreferredSignatureAlgorithm is a SEQUENCE containing sigIdentifier (AlgorithmIdentifier, required) and pubKeyAlgIdentifier (SMIMECapability, OPTIONAL) to distinguish public key algorithm parameters such as elliptic curve selection.