[8] 7174966: With OCSP enabled on Java 7 get error 'Wrong key usage' with Comodo certificate

Vincent Ryan vincent.x.ryan at oracle.com
Wed May 29 13:52:28 UTC 2013


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




More information about the security-dev mailing list