PATCH: possible bug in OCSP check

[Christophe Ravel]

Is there a bug open for this issue ?

Regards,
Christophe.

> Ricardo Martin Camarero <mailto:ricardo_martin_camarero at yahoo.es>
> May 24, 2013 2:31 AM
> 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
>
> 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!

-- 
Christophe Ravel | Principal Member of Technical Staff | +1.650.506.2162
OracleJava SQE - Security
4220 Network Circle, Office 2140, Santa Clara, CA 95054

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20130528/8336dd68/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compose-unknown-contact.jpg
Type: image/jpeg
Size: 770 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20130528/8336dd68/compose-unknown-contact.jpg>