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

[Xuelei Fan]

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.