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

Xuelei Fan xuelei.fan at oracle.com
Mon Oct 21 21:41:30 PDT 2013

line 79-80, Note that Debug.getInstance("certpath") may return null.
Looks like don't need dump variable any more.

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

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.


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.

More information about the security-dev mailing list