[8] 8012636: OCSP validation fails even when public key is trusted

[Xuelei Fan]

OCSPResponse.java
================
line 442-445:
-------------
I like the old style that once the certs in response is not empty, we
should check that the cert are trusted.  This update may ignore the
certs in response.

Xuelei


On 10/22/2013 12:41 PM, Xuelei Fan wrote:
> OCSPRequest.java
> ================
> line 79-80, Note that Debug.getInstance("certpath") may return null.
> Looks like don't need dump variable any more.
> 
> OCSPResponse.java
> ================
> line 134-135.
> -------------
> Debug.getInstance("certpath") may return null. May not need dump variable.
> 
> line 299:
> ---------
>    byte[] responderKey = seq.getData().getOctetString();
> 
> I was wondering the variable may be responderKeyId:
>    responderKeyId = seq.getData().getOctetString();
> 
> line 380-381:
> -------------
> Per RFC 2560, responderKeyId is a SHA-1 hash of responder's public key.
>  The value may be not the SubjectKeyIdentifier in a certificate per RFC
> 5280.
> 
> line 373-384:
> -------------
> Why only include certs that match the responderID?  I was wondering that
> these certs is used to build a full certification path.  The cert does
> not match the responderID may be used as intermediate cert of a path.
> 
> line 442-445:
> -------------
> Need more time to parse the following update.
> 
> Xuelei
> 
> On 10/22/2013 5:36 AM, Vincent Ryan wrote:
>> Please review this fix to support key-rollover certs
>> (same name, different keys):
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8012636
>> Webrev: http://cr.openjdk.java.net/~vinnie/8012636/webrev.00/
>>
>> This issue arises when an OCSP responder replaces its public key
>> but retains its subject name. The OCSP client must be able to
>> validate responses signed by both keys.
>>
>> Thanks.
>