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

[Vincent Ryan]

Thanks for your review. Some comments below.

On 22/10/2013 05:41, 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.

Although null is returned it is not a problem since the isOn method
is a static.

>
> OCSPResponse.java
> ================
> line 134-135.
> -------------
> Debug.getInstance("certpath") may return null. May not need dump variable.

As above.


>
> line 299:
> ---------
>     byte[] responderKey = seq.getData().getOctetString();
>
> I was wondering the variable may be responderKeyId:
>     responderKeyId = seq.getData().getOctetString();

That's an error. I've corrected that.

>
> 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.

True. But if the formats don't match then that's a configuration
problem that will affect other OCSP clients too. I could generate a
new hash for the comparison but that seemed expensive.


>
> 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.

Currently, certpath validation is not performed for the responder cert.


>
> 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.
>