PATCH: possible bug in OCSP check

[Ricardo Martin Camarero]

Hi everybody,

I have been struggling for some months with a weird issue about how Java
validates OCSP responses. Following the RFC2560 standard the responses
sent by the responder should be signed following one of these three
possibilities:

> All definitive response messages SHALL be digitally signed. The key
>    used to sign the response MUST belong to one of the following:
>
>    -- the CA who issued the certificate in question
>    -- a Trusted Responder whose public key is trusted by the requester
>    -- a CA Designated Responder (Authorized Responder) who holds a
>       specially marked certificate issued directly by the CA, indicating
>       that the responder may issue OCSP responses for that CA

In current java implementation (openjdk 6, 7 and 8) the case (1) and (3)
are considered by default and case (2) can be configured using some
properties ("ocsp.responderCertSubjectName" for example). But the
problem is that both configurations are exclusive, if your application
accepts responses for the cases (1) and (3) it fails with the case (2)
and vice-versa.

I faced an OCSP responder that in some cases it answered using the case
(1) and in others using the case (2). The case (1) was used to sign
responses for their own certificates and the case (2) was used to sign
responses for foreign certificates (spanish national id certificates
specifically). I'm not completely sure if the standard admits this
situation but I haven't read anything against that. Besides why not to
take the configured certificate ("ocsp.responderCertSubjectName" or any
of the other properties) as a failback and not as the unique valid signer.

Looking at the code the problem is that only one certificate is passed
as the valid signer for responses (the one configured via properties or
the issuer cert). Following Andrew advise I have made a little patch
against current openjdk-8 that just considers both of them (OCSPResponse
class receives both certs and this way can check the three cases).

Thanks in advance!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ocsp-jdk8.patch
Type: text/x-patch
Size: 7223 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20130524/c0286f7d/ocsp-jdk8.patch>