I don't think so: This is just text to introduce the extension. The definition later is quite clear: If you want a cert to be usable for certsigning then CA must be true. but this condition is may not be sufficiant because one must check all oher extensionsWe threfore have a very clear contradiction between x509 and the following in RFC3280This extension MAY appear as a critical or non-critical extension in CA certificates that contain public keys used exclusively for purposes other than validating digital signatures on certificates.
according the rules, in particular keyusage. I If you make keyusage critical, or if you are a 3280 conforming system that MUST support keyusage, then a cert that does not have keysuage cert sign will not be mistaken as something that can sign a anothre cert. This is also the case in X509 at least if the extension is critical.
After rereading X509, I do not thinh that there is a problem with X509, at least not more thanAbout x509, Peter thinks, and I agree with him, that it would be best to issue a Technical Corrigendum to align it with RFC3280 and require the checking of KeyUsage in path validation.
with the SHOULD of making keyusage critical in PKIX.
But still, that leaves potentially many implementations that use the current path validation and will consider any cA=true cert as valid to issue other cert.My point of view on this subject (I know Peter strongly disagrees) is that setting ca=True on CA certificates that contain public keys not intended to validate other certs is not terribly useful.
I have no opinion about whether this is terribly useful or not.
AFAIK existing usage is not to set it to true.
Well, at least the text in RFC 3280 seem to indicate that there are certficates whether the contrary is true.
Verisign does not set it to true on it's OCSP responders. The Microsoft CAdoes not set it to true on key recovery certificates.I've never seen until any vendor setting it to true on their non-cert signing, non-crl signing certs.I'd strongly be in favor of simply removing that text, and recommend instead to set cA to be set to TRUE only for public keys that can sign other certs.
This is not in X509 and is not in RFC 3280.
I don't see the gain of allowing it to be set for other key pairs that justifies the potential risk it gives for any existing application that would do path validation according to x509 instead of according to RFC3280.As long as you set keyusgae critical, there should not be any risk. And even if keysuage is not critical, I doubt that there are many implementations that do not understand keyusage.
In the particular profils that we are talking about keyusage MUST be present and critical, so there is no danger
Also, about my point that the current text should understood as meaning that only certs that have the same DN as the CA can have cA set to true, I was beginning to think that maybe it was far fetched and I was overinterpreting the meaning of 'subject', but there's another part of the text that leads to the same conclusion :4.1.2.6 Subject [...] If the subject is a CA (e.g., the basic constraints extension, as discussed in 4.2.1.10, is present and the value of cA is TRUE), then the subject field MUST be populated with a non-empty distinguished name matching the contents of the issuer field (section 4.1.2.4) in all certificates issued by the subject CA. [...]So if the cert has cA set to TRUE, the subject is a CA. And if the subject is a CA, the subject field MUST be populated with the DN the CA uses when signing certificates.
Nobody requires that this CA will ever issue certs under that name. --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