The code to convert the regular integer type into the appropriate format could all just be in-line'd when an integer primitive is used but this approach is easier to read.
RFC 3280 requires in section
- 4.1.2.5 Validity
- 5.1.2.4 This Update
- 5.1.2.5 Next Update
- 5.1.2.6 Revoked Certificates
that dates are to be encoded as utcTime iff they are before 2050 and
as generalTime otherwise.
Currently, phpseclib does not respect this by always choosing generalTime.
Further, the format used interally to represent dates only keeps two digits,
so dates in 2050 and later cannot be represented in this format.
This patch fixes this by
1. changing the interal format to be capable of unambiguously representing
dates in 2050 or later (i.e. use four digits to represent the year),
2. choosing between utcTime and generalTime accordingly.
Without this patch, openssl_x509_parse complains:
Warning: openssl_x509_parse(): illegal ASN1 data type for timestamp
These lines served some purpose on SVN, but are now useless on Git. They
actually do harm as they might make people think their files are older
than they actually are.
To use exceptions do define('PHPSECLIB_USE_EXCEPTIONS', true).
To have the exceptions thrown by phpseclib be of a certain class define PHPSECLIB_EXCEPTION_CLASS.
This change stems from the fact that date('T') on PHP 4 (and possibly 5.0/5.1/etc) returns "Central Daylight Time" vs PHP 5, which returns "CDT". "CDT" is parsable by strtotime - "Central Daylight Time" is not.
There will still be some dates that won't properly decode, however, on PHP 4. Those dates would seem to be due to this (from php.net):
"On systems where time_t is a 32bit signed integer, as most common today, the valid range for year is somewhere between 1901 and 2038. However, before PHP 5.1.0 this range was limited from 1970 to 2038 on some systems (e.g. Windows)."
