[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: six-page binary format draft (was: Quick Survey: name certificate syntax)
Tatu Ylonen wrote:
> I'll include below a draft that I wrote after the last IETF for a
> simplified binary certificate.
I don't want to comment on the draft in general, but one thing definitely
caught my eye.
> Time values are needed e.g. for expiration dates and timestamps.
> In this proposal, all times are represented as seconds from
> January 1, 1970, 00:00 UTC. The value is represented as uint32.
> This format allows operation until year 2106. Before then, a
> new certificate format version will need to be defined to add
> more space.
Has history taught us nothing? Y2K is bad enough, I'd assume everyone
recognizes the need to avoid similar blunders in the near future. In
addition, this does not allow you to express dates before January 1, 1970,
The ISO date format "yyyy-mm-dd hh:mm:ss" is valid for another 9000 years.
I'd say that is a fairly good minimum age for dates×. It also happens
to be valid for dates several hundreds of years back. And it has the nice
property of sorting correctly under ASCII "<", "=" and ">".
> Rationale: Using 32-bit binary values allows easy processing
> and comparison on existing 32-bit machines. This makes
> implementation easier and reduces errors. Standard functions
> for processing times in this format are available at least in C,
> C++, Java, and Perl.
Y2K was justified similarly - using two digits for years saved valuable
space and was easy to process.
Personally, I see no real value in this requirement. If necessary, a test
suite with SPKI certificates containing critical dates can be constructed.
Or perhaps even a reference library. To be blunt, using a 32-bit integer
for dates would be short-sighted and limit the potential usability of SPKI
Camillo Sdrs <Camillo.Sars@DataFellows.com> Data Fellows Ltd.
http://www.Europe.DataFellows.com/ Aim for the impossible and you
http://www.iki.fi/ged will achieve the improbable