Maybe you can be even more strict: If the trust anchor (cert[0]) is
already v3, cert[1] must also be v3. Is this reasonable?
Max
Xuelei Fan wrote:
>
>
> Weijun Wang wrote:
>> Xuelei Fan wrote:
>>
>>> Weijun Wang wrote:
>>>
>>>> + // We choose to reject all version 1 and version 2 intermediate
>>>> + // certificates except that it is self issued by the trust
>>>> + // anchor in order to support key rollover or changes in
>>>> + // certificate policies.
>>>> + int pathLenConstraint = -1;
>>>> + if (currCert.getVersion() < 3) { // version 1 or version 2
>>>> + if (i == 1) { // issued by a trust anchor
>>>>
>>>> So, self-issued cert can be only issued by trust anchor, but not an
>>>> intermediate CA?
>>>>
>>> No, self-issued cert can be issued by any entity, but I choose to reject
>>> those self-issued version 1 and version 2 certificates here, because I
>>> have no way to understand whether it is a CA or not.
>>>
>>
>> One question: what's the version of the trust anchor in the failed test?
>> Is it v1?
>>
>>
> It is V1, and issue a self-issued V1 certificate for renew the private
> key, so there is a intermediate V1 CA cert.
>> If so, I think the reason the test fails is because it's written in the
>> v1 age. So my suggestion is that if the trust anchor is v1, then we
>> wouldn't expect the other certs to obey any new rules. Otherwise, if the
>> trust anchor is already v3, the validation should be conformed to the
>> latest RFC.
>>
> RFC5280 allows V1/V2 certificates, and specified how to handle version 1
> and version 2 intermediate CA cert. We can just reject them simply as
> the spec required. I just think we need to support the special case: key
> rollover.
>> In practical cases, is there a CA whose self-signed cert is v3, but it
>> issues a self-issued cert of v1?
>>
>>
> Many, many Verisign root certs are V1, and the intermediate cert are V3.
>
> Thanks,
> Andrew
>> Thanks
>> Max
>>
>>
