[security-dev 00878]: Re: CR 6847459 Created, P3 java/classes_secu Allow trust anchor self-issued intermediate version 1 and version 2 certificate (original) (raw)

Weijun Wang Weijun.Wang at Sun.COM
Wed Jun 3 08:23:58 UTC 2009

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

More information about the security-dev mailing list