Steffen Dettmer wrote: > > > You may argue, and get me to agree, that cert > > > reissue/resigning with the same SubjectPubkeyData is a bad > > > idea. Make 'em generate keypairs. Keep a list forever of > > > pubkeys seen in certs and reject any that appear in CSRs.
> (CSR? Is this like a CRL or something logically equivalent meant?) > > > Your storage requirements won't rival that of Youporn, or > > > Wikipedia. > I think this is wrong. A CRL entry revokes a certificate, not the > key. Maybe the certificate was revoked because of formal reasons > (forgotten critical extension CA:FALSE or omitted key usage > information or whatever). Maybe other valid certificates exist > for this valid key. A certificate may be revoked because the key was compromised. But it could also be revoked simply because the identity is no longer associated with the key. In this case, the key is still perfectly good. It would create a *massive* security loophole for a CA to be able to revoke a *key* just by revoking a certificate that certified that key. What I think Michael Sierchio was saying, though, was something different. He's not saying to treat a certificate as revoked, he's saying not to issue a certificate. Basically, he's saying a CA could refuse to issue a certificate for any key that it had ever seen before in any other context. I think this would be a mistake for a lot of reasons, not the least being the hit-or-miss aspect of having previously seen the key. The only scenario I can imagine where this might help is a case where a person accidentally generates the CSR with the wrong key, and by luck the CA happens to have seen this key before. And, of course, there are so many other ways to screw up generating a CSR that this seems like a pretty small help. (Failing to secure the private key, for example.) I also think there are perfectly legitimate reasons for using the same key in many certificates. An obvious one is if you have a large number of certificates that establish different external identities for the same logical entity. This isn't a common way to use a PKI, but X.509 and PKI exist for much more than just TLS and the Internet. (Although presumably Michael wasn't suggesting you should impose this rule where it was obviously inappropriate.) DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
