Expiry of digital certificates (x509.3)
Peter Scott
x509v3 certificates of a system that is offline for more than the duration
of the certificate (i.e. 1 year) ?.
Is it normal for CA's to issue certificates that have an expiry date of more
than 1 year.? What are the risks involved in obtaining a certificate with a
longer expiry date (5 or 10 years) ?
Does the expiry of the certificate invalidate it totally (the public key
stays the same and the private key is still valid) ?.
Any advice would be welcome,
Peter
Michael Ströder
>
> Has anybody dealt with the problem (... has some advice) of the expiry of
> x509v3 certificates of a system that is offline for more than the
> duration of the certificate (i.e. 1 year) ?.
Which system? Which application? What do you mean with offline? Are you
asking about obtaining certificate revocation lists / online cert
checking?
> Is it normal for CA's to issue certificates that have an expiry date of
> more than 1 year.?
Well, it's not usual to issue certs which lasts longer than one year.
Well, in the case of commercial CA's this might also have marketing
reasons, but...
> What are the risks involved in obtaining a certificate with a
> longer expiry date (5 or 10 years) ?
Private keys could have been compromised (without the owner noticing
it).
The key length could be considered being unsecure after several years.
> Does the expiry of the certificate invalidate it totally (the public key
> stays the same and the private key is still valid) ?.
The certificate is a strong binding between a public key and an identity
information. If the certificate expires this binding (kind of a
statement by the CA) expires.
An application MUST not use the public key after the expiry date for
encrypting and MUST not use the corresponding private key for signing.
The private key can still be used after the expiry date to decrypt data
(e.g. display old e-mails) and the public key should still be used to
verify the signatures which were created before the expiry date.
Normally a new certificate requires generating a new key pair. A CA
might decide to re-new a certificate. In this case a new certificate for
the same key pair is issued containing the old public key and identity
information.
Ciao, Michael.
Bruce
> Has anybody dealt with the problem (... has some advice) of the expiry of
> x509v3 certificates of a system that is offline for more than the duration
> of the certificate (i.e. 1 year) ?.
If you use the certificate after a year has passed, whether you are on or
off-line, then the receiving computer will recognize that the certificate has
expired. i.e.. The certificate carries a tag which stipulates it's life span
(decided on by the certificate issuer / CA), and when I receive a mail signed by
you, my computer will say that the signature is invalid because the cert. has
expired.
>
> Is it normal for CA's to issue certificates that have an expiry date of more
> than 1 year.? What are the risks involved in obtaining a certificate with a
> longer expiry date (5 or 10 years) ?
The standard is 1 year, although there are companies that are beginning to offer
2 years. It would be unwise to have a certificate which is valid for longer than
a year (i.m.h.o.) for security reasons as well as possible advances and
compromises in the key length and encryption strength.
>
>
> Does the expiry of the certificate invalidate it totally (the public key
> stays the same and the private key is still valid) ?.
If the cert expires the keys can still be used. The public key (with the
signature) will cause the signature to become invalid, but otherwise the keys
can still be used for encryption etc. The private and public keys are still
'valid' and the expired public key can be resigned by the CA for a renewal of
the same certificate.
I hope that helped.
--
Bruce Watermeyer
As of January 2000 the most trusted CA worldwide. To find out why, go to
http://www.thawte.com/year2000.html
"It's better to regret something you did,
Than something you didn't do!"
Olaf Schlüter
Am 01.12.99, 16:10:46, schrieb "Peter Scott"
<Peter...@ecc.statkart.no> zum Thema Expiry of digital certificates
(x509.3):
> Has anybody dealt with the problem (... has some advice) of the expiry
of
> x509v3 certificates of a system that is offline for more than the
duration
> of the certificate (i.e. 1 year) ?.
> Is it normal for CA's to issue certificates that have an expiry date
of more
> than 1 year.? What are the risks involved in obtaining a certificate
with a
> longer expiry date (5 or 10 years) ?
> Does the expiry of the certificate invalidate it totally (the public
key
> stays the same and the private key is still valid) ?.
> Any advice would be welcome,
> Peter
According to the common validity model expired certificates are
invalid and can no longer be safely used for anything. Expiry does not
necessarily mean that the keys involved are compromised, not even that
the probability that there has been a undetected key compromise has
considerably raised. The validity of a certificate is the assurance of
the certifying authority to manage it for the indicated lifetime.
Management of a certificate means at least offering a revocation
service for it. Expired certificates are no longer maintained in
certificate revocation list. The CA simply forgets about them. Without
the assurance of the CA to give you status information about the
certificate you cannot use it for obtaining encryption or
authentication keys in a safe way.
The risks for a certified key during its lifetime are: the key gets
compromised (and that is not noticed), and/or the algorithm used to
generate the key or to sign the certificate gets broken over time. The
fact that an undetected key compromise cannot cause harm any longer
then the validity of the certificate indicates is a second, but not
the main benefit. How likely a undetected key compromise is depends on
the storage media of the private key and the way it is processed. With
a key stored password-protected in a file easily and unnoticeably
copied away, the risk of an undetected key compromise may be high
enough to limit the validity of the key through the certificate and
not recertifying it again. With keys created and/or safely stored and
processed on smartcards the chance of an undetected key compromise is
considerably lower, as an attacker has to get hold of the card for
some time at least, which may be detected, and has to exploit a
security flaw of the card, the probability for that to exist is again
low. Note that the validity limitation is only a poor method to
restrict the damage caused by a compromised key. The private key
should be protected and there should be measurements that give a high
probability for detecting a key compromise. Smartcards are one good
solution for that.
That is the common (PEM and PKIX) model. There is at least one other
important model, that aims at digital signature applications. In this
model an expired certificate can still be used to obtain an
authenticated copy of the signers public signature verification key.
Documents successfully verified with that key are considered as
non-repudiable if it can be assured (for example by using time stamps)
that the document has been signed before the signers certificate
expired. Following these rules documents signed during the validity
period of the signer certificate remain valid after expiry of the
signers certificate. Even revocation prior to normal expiry does not
invalidate documents signed before the revocation date and time.
Nothing else makes sense for digital signatures. For that to work, the
certifiying authority has to maintain status information about the
certificate even after its expiry, at least the revocation date, if
any.
In Germany that scheme is applied for signatures in certificates too.
That is a signer certficate remains valid (for verifying and signing)
even after expiry or revocation of the certificate of the certifiying
authority. This is achieved by following the rules above using the
notBefore field in the certificate to obtain the time the CA signed
the user certificate. To protect against backdated signer certificates
signed by a compromised CA key OCSP is used to verify the status of a
signer certificate (that is an online request is made to the CA to
obtain a signed response indicating the fact that the certificate has
been properly issued and not revoked before the signature in question
has been made). Since you need the revocation date of the signers
certificate for verifying the signed document in any case the OCSP
request is unavoidable, and you can store the response away together
with the signed document and use it later on. If the key used to sign
the OCSP status information gets compromised later on you can obtain a
new response signed with a new key.
That way you get a rather robust PKI infrastructure suitable for
maintaining trust over years which is the main challenge with digital
signature applications. With the assurance of the involved CAs to
maintain status information about every certificate ever issued such a
structure even survives a trusted root key compromise. The described
scheme could be easily applied to other applications (encryption and
authentication) too as the business of certifying authorities is
signing only and verifying certificates means verifying signatures.
However current PKI implementations in popular software like Internet
Explorer, Netscape, Outlook Express and so on follow the PKIX model
with all its drawbacks. You cannot store a signed email away and
verify it again after expiry of the signers certificate. You cannot
store a signed applet on a web server and forget about that. Microsoft
had to learn that the hard way and introduced time stamps for that in
Authenticode 2. You cannot revoke a certifying authority without
reissuing certificates to all your users. Certificates are signed
documents and should be treated as such. Like a handwritten signature
a digital signature, once made, should never expire. With the scheme
above that can be achieved. (For the paranoic reader: yes, it has been
neglected in this discussion that algorithms can be weakened over time
- the probability for that to happen is low enough to give safety over
a considerable long time frame. And paper does not live forever
either).
Using that scheme the normal duration of the validity period of a
certificate depends more on economic and practical issues then on
safety issues. The German Telekom for example issues signer
certificates valid for three years (but still charge you every year
for that). That is probably because three years are yet common in
germany for smartcard lifecycles. As the scheme is flexible enough,
certifying authorities can choose whatever they think is suitable for
their and their users purpose. (For the peculiar reader: the maximum
validity period mandated by law is currently five years due to the
weakening algorithm problem - IMHO it is a rather conservative limit).
Olaf Schlüter
Follow-Up set to comp.security.misc.