This is a discussion on Re: Accessing encrypted messages after cert expires - Openssl ; David Schwartz wrote: > 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 ...
David Schwartz wrote:
> 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.
I'm saying that matters of policy are within the purview of the
Registration Authority and/or Certificate Authority. The relying
party agreement associated with the CA, and perhaps baked into
the certificate via reference, can spell this out.
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 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.
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 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.
The OP was asking about the mechanics of signature verification
beyond the expiration date of the signing cert. I think we've
OpenSSL Project http://www.openssl.org
User Support Mailing List email@example.com
Automated List Manager firstname.lastname@example.org