Network Computingwww.networkcomputing.com

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.