|
I am not saying that if the key usage
extension is present, key cert sign bit need not be set. What I am saying is that key usage can be
absent altogether as long as basic constraints is set. If key usage is present, key cert sign bit
must be set in order to use the associated public key to verify signature on a
certificate. As far as your wariness is concerned, if a
CA omitted key usage extension in a CA certificate, the CA will not comply with
RFC 3280. Client need not ensure the presence of the
extension. If you are really wary, 3280 permits you
to have your own additional checks. From: owner-ietf-pkix@xxxxxxxxxxxx
[mailto:owner-ietf-pkix@xxxxxxxxxxxx] On
Behalf Of Jean-Marc Desperrier Santosh Chokhani wrote: RFC 3280 is pretty clear on what determines a CA. It is based on basic constraints for version 3 certificates and out of band means for version 1 and 2. See section 4.2.1.10 (Basic Constraints) and step k in Section 6.1.4.Now we're getting to something interesting.So for retro-compatibility reasons, a proper implementation of RFC3280 should accept a certification path where one of the CA certificate has Basic Contraint CA=True but has no Key Usage extension.I don't feel really at ease with that. I'd be really wary when encoutering such a case and I'm not sure it corresponds to a very useful need.But so be it, and does give weight to Peter's argument that any cert with BC including CA=True should be handled as a CA cert in all cases.
It would be extremely dangerous to allow a certificate
to act as a certificate issuer if it has a key usage extension without the key
cert Sign bit set and fortunately step n does not do that, it only allows
through certificates with a *missing* key usage extension. |