You are welcome. BTW, would you like to add a comment in the update so that we won't tighten the check in the future unintentionally?
Xuelei On 5/29/2013 9:52 PM, Vincent Ryan wrote: > 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. >>>>> >>>> >>> >> >