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.
