Michael Sierchio: > If it's your policy not to reuse keys, or allow their use beyond > the lifespan of the certificate, then the enforcement mechanism > for this MUST be in the CA.
I completely disagree. If this were true, CA's would generate the private key as part of the certificate issuing process. However, in the typical case, it is the certificates subject who generates the private key, passes the corresponding public key to the CA, and takes responsibility for ensuring the safety of the private key. It is certainly true that the CA could enforce certain security rules with respect to the key. But this would be somewhat unusual (beyond perhaps just not reusing the same key) and would not relieve the subject of any of his responsibility. > I don't understand your "hit-or-miss aspect" - a CA must keep track > of all the issued certificates back to the beginning of time. It is > trivial to know whether a key has been used before. Whether it's been used for another certificate from that same CA, sure. But in what context does another certificate from the same CA with the same key present a problem while certificates from other CAs with the same key does not? > And my objection remains to your notion that the private key format > should be extended to include generation date. Even if you are > to reissue/resign a cert with the same subject pubkey, you still > have a record of when the key was first placed into use. I'm not sure who the "you" is here. In practice, nobody has any record of when a key was first placed into use. If you think anyone does, please tell me where you think that record is. The CA has no way to know they are the first to see a key. So no CA can know this. Whoever or whatever generated the key knows this, but they currently have no place to store it. They could store it separately, but then it's quite likely to become separated from the key. (And, in practice, that it's not embedded in the private key has meant that it's almost never stored and it certainly doesn't travel with the private key in a portable format.) > I also don't understand why you think it would be appropriate to > use the same key in different certs. It is much more common to > have different certs with different keys for different purposes. > For example, if you wish to claim non-repudiation, then the CA > may require that the private key is embedded in a token device > where the keypair was generated, and is not otherwise accessible. > Such a key would be used for signing only, presumably, for a > number of very good reasons. The same entity may have an SSL > client cert, an encryption cert, etc. PKI is not TLS. Consider a case where a third party needs to vouch that a particular identity is entitled to a particular resource. It can only use a key it already has for that third party. For example, suppose I have a public key for a particular warm body. I want to grant him access to eight different things by certificate, each of those eight things are managed by different systems. Each of those eight systems is part of its own zone with its own master key, and I have all eight master keys. So I generate eight certificates and pass each one to each of those eight different things. It is not unusual (especially in military systems) for one certificate to bind a keypair to a particular person, unit, system, or basically 'thing'. Then other systems can grant the entity bound to the keypair access to a resource by generating a certificate binding that things keypair to that resource. If I know Jack's keypair (by certificate) and I control access to a particular system, I can grant Jack access to that system by creating a certificate associating Jack's keypair with that access. I can do this even without communicating with Jack directly, without Jack having to request it, and I can pass that certificate either to Jack or to the system that will use it. > The OP was asking about the mechanics of signature verification > beyond the expiration date of the signing cert. I think we've > answered that. Yes, but there is an important tie-in between that question and the one I'm discussing above. How can you know you can trust a timestamp if you don't know whether or not today's date is inside the validity interval for the key that signs the timestamp? Obviously, you can check if the timestamp is inside the validity interval for the certificate that signed the object, solving the OP's question. But what if today's date is outside the validity interval for the *key* that was used to timestamp? (In which case, the timestamp could have been forged yesterday to make the signature seem like it was within the validity interval of the certificate.) Suppose I have a key that I trust for 50 years, and therefore will allow to be used to make timestamps for 20 years (and they can still be securely verified up to 30 years after the last one is made). Where do I put the 20 years and the 50 years? DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
