Jean-Marc Desperrier wrote:
Indeed. But we are hear in a different case as I initially described. Since RFC 3280 makes restrictions, and the tool in question is determining whether the CA creates good certficats, a V3 cert with BCSantosh 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.
and no Keyusage is an error.I agree with Santosh that if one allows such a cert to participate in the path validation game (i.e. one with CA=true and no keyusage) it would be accepted as signing certficat. The question
is whether it should be allowed to play. That's a different problem.At least one can appreciate that the path validation algorithm is a concrete thing. This
would be different for example if two rules would be replaced by 'If the certficat can sign certificats ...'
It is non conformant, but at least we know what the path validation algorithm is doing.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.
In fact I said the contrary, Santosh and Steve did say that. I don't care as long as the definition can be understood by a tester and as long asthe tool does not reject valid certificats and puts them into an understandable
category.I have no idea what a user expects "Can this cert be used to sign other certs"
or "Does this cert belong to some (certification) authority"? Of what type is a cert of a TSAuthority? Assume CA=true or CA=false?
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.RFC 3280 is also clear that CA certificate need not contain key usage extension, let alone have key cert Sign bit. See step n in Section 6.1.4.
Yes,Wasn't there a famous bug several years ago in some widely deployed software
that allowed an end-entity to become CA? :-) --To verify the signature, see http://edelpki.edelweb.fr/ Cela vous permet de charger le certificat de l'autorité; die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature