[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: draft-housley-binarytime-00.txt


Peter:

> >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.

If you assume a systrem that uses time_t and the availablity of a gmtime
function, something like the following should work to convert a
generalizedtime in Zulu to a time_t.

        time_t test = (time_t) 0;  int i ;
        for (i = ( sizeof(time_t)*8-2) ; i>=0; i--) {
                test += (time_t)(1 << i) ;
                strftime(strtime, 16, "%Y%m%d%H%M%SZ",gmtime(&test));
                if (strncmp(tm->data,strtime,15) < 0)
                        test -= (time_t)(1 << i) ;
        }

Two thoughts:

1. Embedded systems may not have the rich set of functions that you are using here.

2. This only works when the time zone is UTC. This is one of the reasons that RFC 3280 and RFC 3852 require the time values to make use of UTC. The UTCTime and GeneralizedTime types do support other time zones.

> >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.

Comparison of ordered text strings is also simple.
Dates in certificates are in generalizedtime.

Yes, if all times are represented in UTC, and the times are in the same format. Another complexity can arise when one date is in UTCTime and the other is in GeneralizedTime.

In any case, on failure, some information must bepresented, and it
may finally end up before user: signature not valid because not after 1000000000

of course, if you don't assume the availability of a gmtime function...
... but then you probably already have other problems.

I already said that above...

'Midnight' 1.1.70 is 00h00 or 24h00 btw.

We should probably add that to the list of things to clarify if the specification is ever updated again.

> >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.

In the intended scenario?

I am not sure but I have the feeling that the current justification
can be resumed as 'There may be some usages of this feature somewhere, it
is admitted that in the described scenario it is not usefule, even superfluous,
and may create confusion, but anyway.'

I amy be wrong.

You may be right. That is why we ask for review.

Russ