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

[Vincent Ryan]

That behaviour hasn't changed. The certs returned in the OCSP Response 
are still checked for trust: now they must satisfy the Authorized Responder tests.

Previously, the cert returned in the OCSP Response was first matched against
the trusted responder. That's no longer needed as all the trusted responders
are examined (separately) in a previous step.


On 23 Oct 2013, at 03:16, Xuelei Fan wrote:

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