PATCH: possible bug in OCSP check

[Ricardo Martin Camarero]

Hi Xuelei,

I suppose my company had, cos I also work for Oracle. :-)

But I'm not related with openjdk and this issue was discovered outside
my work (I was asked by an ex-colleague about the ocsp responder I
commented previously).

Regards!


On 05/29/2013 03:16 AM, Xuelei Fan wrote:
> Hi Ricardo,
>
> Have you or your organization signed the signed the Oracle Contributor
> Agreement (OCA) per the request of OpenJDK bylaws?
>
> http://openjdk.java.net/bylaws#_2
>
> Thanks,
> Xuelei
>
> On 5/24/2013 5:31 PM, Ricardo Martin Camarero wrote:
>> 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!
>>