All the fields in version 3 and PKIX use the variable GeneralizedTime, which has a four-digit year. But the certificate validity dates, used for the NotBefore and NotAfter fields, use the variable UTCTime, which has a two-digit year. RFC 2459 adds the four-digit format as a choice, but it clearly states: "CAs conforming to this profile [the RFC 2459 profile] must always encode certificate validity dates through the year 2049 as UTCTime; certificate validity dates in 2050 or later must be encoded as GeneralizedTime." Given that old certificates using UTCTime and new certificates using GeneralizedTime will have to co-exist, why are we delaying such an important change?
Any certificate that will expire or become effective before 2050 will have two-digit years, and only certificates that expire after or become effective after 2050 will have four-digit years. Those will appear around 2040. I'll be 90 by then, so perhaps I shouldn't worry about this. Let the next generation fix any bad code that shows up when the first certificate hits the Internet using GeneralizedTime for a validity date. OK, I'm better than that, and this date debacle should be dealt with now.
A real concern about living in a mixed-date environment, and thus delaying the inevitable until other systems are all corrected, comes from the way that digital certificates are formatted. Digital certificates use two ISO standards: DER (Distinguished Encoding Rules, see X.690), which is normally used for storage, and BER (Basic Encoding Rules, also in X.690), which eases the programmatic processing. Digital certificates must be in DER to be signed and for those signatures to be validated. However, most programs convert to BER to process the certificate content. This in itself is not the problem. Unfortunately, some directory services store certificates in BER to simplify the certificate programming. The result is a situation in which the original DER format, which is needed to validate the certificate, cannot be re-created. So, some directory and certificate specialists push for an indefinite delay until no system stores BER format.
Interestingly enough, the PKIX community set another flag date of Jan. 1, 2004, for requiring exclusive use of the international character representation, UTF8String, for encoding certificate distinguished names (as in certificate subject, issuer and certain extensions). Tim Polk of NIST, editor of RFC 2459, has observed that this date will have a similar DER-BER-DER deployment problem, so why not make the Y2K resolution at the same time as the international character conversion? As sensible as this seems, there will be no change in this Y2K bug's resolution date because RFC 2459 progresses from a draft standard to a proposed standard in the first quarter of next year, unless there is an expected and loud consensus to make the change.
2004 is a much more appropriate date to address this problem. Talk to your PKI vendors about this dangling two-digit year in your certificates and get your concerns into the IETF PKIX process. Join the workgroup list (ietf-pkix@imc.org) and send comments to the workgroup chairs and area directors. Meanwhile, I'm putting language into my PKI purchasing requirements to let me create and process certificates with GeneralizedTime for validity date by Jan. 1, 2004. This one the IETF got wrong.
Robert Moskowitz is a senior technical director at ICSA. Send your comments on this column to him at rgm@htt-consult.com.
You'd think that a new Internet standard would be free of Y2K problems. But if it has a legacy component, think again. Digital certificates have been around for a dozen years and in that time they've gone through three versions. We finally have an Internet Standard Profile (RFC 2459, Internet X.509 PKI Certificate, and Certificate Revocation List, collectively known as PKIX). But this new standard has a Y2K bomb that could go off 40 years from now--when it is well entrenched in our businesses.
REPORTS
ANALYTICS
Follow 
