Overview#

Certificate Validity Period indicates the Certificate's carries a pair of date and time indications, indicating the start and end of the time period over which a certificate is intended to be used.

X.509 Style Guide#

Validity ::= SEQUENCE {
    notBefore               UTCTIME,
    notAfter                UTCTIME
}

This field denotes the time at which you have to pay your CA a renewal fee to get the certificate reissued. The IETF originally recommended that all times be expressed in GMT and seconds not be encoded, giving:

YYMMDDHHMMZ
as the time encoding. This provided an unambiguous encoding because a value of 00 seconds was never encoded, which meant that if you read a UTC Time value generated by an implementation which didn't use seconds and wrote it out again with an implementation which did, it would have the same encoding because the 00 wouldn't be encoded.

However newer standards (starting with the Defence Messaging System (DMS), SDN.706), require the format to be:

YYMMDDHHMMSSZ
even if the seconds are 00. The ASN.1 encoding rules were in late 1996 amended so that seconds are always encoded, with a special note that midnight is encoded as ...000000Z and not ...240000Z. You should therefore be prepared to encounter UTCTimes with and without the final 00 seconds field, however all newer certificates encode 00 seconds. If you read and then write out an existing object you may need to remember whether the seconds were encoded or not in the original because adding the 00 will invalidate the signature (this problem is slowly disappearing as pre-00 certificates expire).

A good workaround for this problem when generating certificates is to ensure that you never generate a certificate with the seconds set to 00, which means that even if other software re-encodes your certificate, it can't get the encoding wrong.

At least one widely-used product generated incorrect non-GMT encodings so you may want to consider handling the "+/-xxxx" time offset format, but you should flag it as a decoding error nonetheless.

In coming up with the worlds least efficient machine-readable time encoding format, the ISO nevertheless decided to forgo the encoding of centuries, a problem which has been kludged around by redefining the time as UTCTime if the date is 2049 or ealier, and GeneralizedTime if the date is 2050 or later (the original plan was to cut over in 2015, but it was felt that moving it back to 2050 would ensure that the designers were either retired or dead by the time the issue became a serious problem, leaving someone else to take the blame).

To decode a date, if it's UTCTime and the year is less than or equal to 49 it's 20xx, if it's UTC Time and the year is equal to or greater than 50 it's 19xx, and if it's GeneralizedTime it's encoded properly (but shouldn't really be used for dates before 2050 because you could run into interoperability problems with existing software). Yuck.

To make this even more fun, another spec at one time gave the cutover date as 2050/2051 rather than 2049/2050, and allowed GeneralizedTime to be used before 2050 if you felt you could get away with it. It's likely that a lot of conforming systems will briefly become nonconforming systems in about half a centuries time, in a kind of security-standards equivalent of the age-old paradox in which Christians and Moslems will end up in the other side's version of hell.

Confusion now hath made his masterpiece. -- Macduff, "Macbeth", II.i.

Another issue to be aware of is the problem of issuer certificates which have a different validity time than the subject certificates they are used to sign.

Although this isn't specified in any standard, some software requires validity period nesting, in which the subject validity period lies inside the issuer validity period. Most software however performs simple pointwise checking in which it checks whether a cert chain is valid at a certain point in time (typically the current time). Maintaining the validity nesting requires that a certain amount of care be used in designing overlapping validity periods between successive generations of certificates in a hierarchy. Further complications arise when an existing CA is re-rooted or re-parented (for example a divisional CA is subordinated to a corporate CA). Australian and New Zealand readers will appreciate the significance of using the term "re-rooted" to describe this operation.

Finally, CAs are handling the problem of expiring certificates by reissuing current ones with the same name and key but different validity periods. In some cases even CA roots have been reissued with the only different being extended validity periods. This can result in multiple identical-seeming certificates being valid at one time (in one case three certificates with the same DN and key were valid at once). The semantics of these certificates/keys are unknown. Perhaps Validity could simply be renamed to RenewalFeeDueDate to reflect its actual usage.

An alternative way to avoid expiry problems is to give the certificate an expiry date several decades in the future. This is popular for CA certs which don't require an annual renewal fee.

More Information#

There might be more information for this subject on one of the following:

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-2) was last changed on 12-May-2017 14:09 by jim