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?


__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majordomo@openssl.org