Thanks for your review. On 29 May 2013, at 14:27, Xuelei Fan wrote:
> It's OK to me. > > At present. there is no risk I can see to loosen the check. I just > worried that if we want to tighten the check again in the future, we may > run into compatibility issues. But for now, it is fine to me. > > Thanks, > Xuelei > > On 5/29/2013 8:59 PM, Vincent Ryan wrote: >> The Comodo cert has the 'keyCertSign' and 'cRLSign' keyUsage bits set. >> That's unusual but permitted by RFC 5280. >> >> I could have changed the Signature.initVerify method to also accept that >> combination of >> keyUsage bits but that would affect all signatures. Sean suggested the >> approach where >> the OCSP client supplies the signer's public key rather than the signer's >> cert. >> >> It does mean that the signer's 'digitalSignature' keyUsage bit is no longer >> checked but >> since the RFC allows other bit combinations to be set then I think that >> skipping that >> check is acceptable. >> >> >> >> On 29 May 2013, at 13:42, Xuelei Fan wrote: >> >>> What's the key usage of the OCSP responder? I think it is more like a >>> problem of Comodo CA. This fix may loosen the checking of the validity >>> of the OCSP responder's certificate. >>> >>> Xuelei >>> >>> On 5/28/2013 7:30 PM, Vincent Ryan wrote: >>>> Please review the fix for: http://bugs.sun.com/view_bug.do?bug_id=7174966 >>>> >>>> The problem occurs when validating the signature of an OCSP response from >>>> the Comodo CA. >>>> The Signature class tests for the presence of the digitalSignature >>>> keyUsage setting when examining >>>> a signer's certificate. One solution is for the >>>> sun.security.provider.certpath.OCSPResponse class to >>>> pass the signer's public key rather than the signer's certificate. >>>> >>>> Webrev: http://cr.openjdk.java.net/~vinnie/7174966/webrev.00/ >>>> >>>> Thanks. >>>> >>> >> >
