[Top] [All Lists]

Re: draft-housley-binarytime-00.txt

2004-09-01 11:08:06


> >The document states the rationale.  No conversion to operating system
> >representation and it is smaller.  In what way do you find it limiting?
> It doesn't go beyond 2038, whereas UTCTime at least goes to 2050.

Some thoughts:

The value is an ASN.1 INTEGER, not a time_t or whatever.

The format IS flexible because it allows any integre size. It may just
happen that implements will wake up 33 years and find out that their
asn1 decoding of this INTEGER cannot convert higher numbers..


There are machines where the internal format of time is not seconds
since 1.1.70, ...

I agree. However, very simple math can be used to make the conversion. However, conversion from UTCTime and GeneralizedTime is a bit more complicated. I do admit that operating systems provide the necessary routines to handle this in a few lines of code.

Showing this time to a user always requires some conversion, while
displaying a generaizedtime does not.

Display to a human is not the biggest concern. Date comparison is a much bigger deal to me. Integer comparison is easy, even when multi-precision integers are involved.

The few octes advantadge over generalizedtime seems small compared to the
size of a signature. And treatment of generalized time is necessary anyway
because of dates in certs.

Yep.  I think that BinaryTime has other uses too.