[pkix] Proposal for OCSP vulnerability

[Koichi Sugimoto <[e-mail]>]

Hello.

I am considering about vulnerability of OCSP.
Do you have any ideas for the following?


Introduction:

OCSP is a vulnerable protocol because client can send OCSP request WITHOUT
digital signature, on the other hand, server has to send back the
corresponding response WITH digital signature.
OCSP server has to generate digital signature every time creating OCSP
response if OCSP caching scheme cannot be applicable.
This kind of biased processing between client and server would make server
load becomes high, it makes easy for attacker to force OCSP server down as
DOS.
Indeed OCSP caching described in RFC 5019 can reduce the load of OCSP
server, but, OCSP responses for non-issued certificates cannot be cached,
if the attacker generates random serial number and put it in the OCSP
request, such caching logic will be collapsed.
This proposal is one of the solutions to cope with this kind of attack.


Overview of idea:

If client (relying party) sends actual certificate to be validated, then,
it has signature created by the CA.
By validating the signature, OCSP responder knows whether the certificate
was acutally issued by the CA or not.
The number of certificates is limited, the OCSP responder can cache the all
ocsp responses (if no nonce).
If the OCSP responder does not know the status of the certificate, the OCSP
responder can conclude such certificate was unreasonably issued or missed
from CA.
On the other hand, the client only needs to know the status of certificate
that owned by the client.
In this way, if OCSP is defined by existing of actual certificate, DOS
attack like above can be avoidable.
Validating certificate signature also need public key operation, we can
introduce more light operation like cryptographic hash algorithm.


Detailed example for proposal:

[X.509 V3 extension]
strictCollationExtension = any collation value generated by CA.
ex) strictCollationExtension = HASH( certificateSerialNumber || secretValue
owned by CA)
, where || means concatenation operation.

[Precondition]
Client to send OCSP request has EE certificate to be validated.

[Client responsibility]
Client has to send OCSP request with strictCollationExtension value if it
needs OCSP response even for unreasonable certificate.
Such extension value should be embedded into OCSP request extension.

[OCSP server responsibility]
OCSP server has to send back the corresponding OCSP response by collating
the extension value.
If the extension value matches the calculated value, OCSP server has to
send strict status value good/revoked/unknown.
If the extension value does not match to calculated value, OCSP server can
send error such as malformedRequest / unauthorized.


Consideration on server side:

OCSP server can cache (even pre-generate) OCSP responses for known
certificates.
Even if the target certificate information was not in the database, the
number of such certificates seems to small, the operation load must not
high. After creating OCSP response(s), such information can be cached.

Matching operation for the strictCollationExtension is very light, the load
of OCSP server is low.

If the extension value does not match to the calculated value, the OCSP
server does not need to sign the response, the load is also low.


Consideration on client side:

If client received signed response, by validating the signature, client
knows whether the response is reliable or not.
If the response is reliable, the client can judge the actual certificate
staus including unreasonable certificate.
If the client received unsigned response such as malformedRequest /
unauthorized, the response was either from unauthorized OCSP responder
or the strictCollationExtension value was invalid (may be hacked by some
attacker).


Regards,
Koichi Sugimoto.