7168191: Signature validation can fail under certain circumstances

Michael StJohns mstjohns at comcast.net
Wed Jun 20 14:40:10 UTC 2012


At 09:49 AM 6/20/2012, Vincent Ryan wrote:
>Hello Michael,
>
>Thanks for your review comments.
>
>The cert path implementation in JDK currently doesn't support that AKID
>variant. I don't think that it is commonly used. Especially since RFC 5280 requires the SKID extension to be present in all CA certs.
>
>Would you like me to file an RFE to add support for it?


OK - that's a fair statement.  Part of the issue is that not all CAs are 5280 compliant (see for example the recent discussion on setting the critical bit of the NameConstraints extension on the IETF PKIX mailing list).

I'm wondering if perhaps your path code should throw an error if either the parent certificate does not have an SKID or if the child certificate does not have an AKID with a keyIdentifier?  (Or at least an option to trigger that "strict" behavior to identify non-compliant certs).

Upon reflection, I don't think an RFE is necessary.  The only applicable case is where the CA cert was issued without an SKID and needed to create AKIDs in child certs which mostly shouldn't happen.  And that leaves us with the problem where the root key may not be bound into a certificate at all.


Thanks! Mike




>On 06/19/12 09:48 PM, Michael StJohns wrote:
>>Hi - there's two different varieties of authorityKeyIdentifier - you only fixed one.
>>
>>If the child cert has an akid consisting of the value of the parent skid, then you're good to go.  But there's also the akid variant which contains issuerName/serialNumber of its parent where the parent has no skid.
>>
>>Mike
>>
>>Sent from my iPad
>>
>>On Jun 19, 2012, at 15:52, Vincent Ryan<vincent.x.ryan at oracle.com>  wrote:
>>
>>>Hello,
>>>
>>>Please review the following changeset for JDK 7u6:
>>>   http://cr.openjdk.java.net/~vinnie/7168191/webrev.01
>>>
>>>The bug report is at:
>>>   http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7168191
>>>
>>>This fix addresses a bug in the OCSP client when processing key-rollover
>>>certs. Typically such certs have the same subject name but different
>>>keys. Now the OCSP code examines all the matching candidates (not just
>>>the first one) both when preparing the request and when validating the
>>>response.
>>>
>>>Thanks.





More information about the security-dev mailing list