[9] Request for Review: 8021804: Certpath validation fails if validity period of root cert does not include validity period of intermediate cert
Jason Uh
jason.uh at oracle.com
Tue Mar 11 22:30:49 UTC 2014
Thanks, Sean. I'll push with a set date.
On 3/11/14 2:59 PM, Sean Mullan wrote:
> In the test, you should probably call PKIXParameters.setValidity with a
> fixed date so that the test won't start failing in 2024. Yes, I know
> that's a long time away! Check out other tests to see examples.
>
> Otherwise, fix looks good and you can push without a re-review.
>
> --Sean
>
> On 03/10/2014 08:00 PM, Jason Uh wrote:
>> Thanks, Sean. I've simplified my changes to only removing the call to
>> setValidityPeriod.
>>
>> http://cr.openjdk.java.net/~juh/8021804/webrev.01
>>
>> Jason
>>
>> On 3/10/14 12:00 PM, Sean Mullan wrote:
>>> Hi Jason,
>>>
>>> Sorry for the delay in reviewing this.
>>>
>>> On 02/28/2014 02:54 PM, Jason Uh wrote:
>>>> Hi Sean,
>>>>
>>>> Could I please get a review of this change? This fix allows a certpath
>>>> to be validated when a certificate issued by a version 1 trusted cert
>>>> has a validity period that doesn't fall within the validity of the
>>>> issuer. Trust anchors whose validity do contain the issued cert's
>>>> validity period will be prioritized above those that do not.
>>>>
>>>> webrev: http://cr.openjdk.java.net/~juh/8021804/webrev.00/
>>>> bug: http://bugs.openjdk.java.net/browse/JDK-8021804
>>>
>>> In PKIXCertPathValidator, I would remove the call to
>>> X509CertSelector.setValidityPeriod on line 98 and just match on the
>>> subject and SKID when trying to find a matching trust anchor. Most of
>>> the other changes are not necessary I think. At this point you are just
>>> trying to find a matching root. In most cases there will only be one
>>> possible choice, so unless there are 2 V1 roots with the same subject
>>> name and a different public key (ex: due to key rollover). Maybe trying
>>> to match on the validity period would help select the right root in the
>>> key rollover case, but I'm not sure the extra code is worth it for this
>>> rare case (and V1 roots are becoming much less common). And even if it
>>> does select the wrong root the first time, the code should fail quickly
>>> (when the signature on the cert issued by the root fails), and then
>>> proceed to try the next one (and then succeed).
>>>
>>> --Sean
>>>
>>>
>>>
>>>
>>>
>>
>
More information about the security-dev
mailing list