Subject: Re: draft-housley-binarytime-00.txt

From: Peter Sylvester <[email-masked]>
Date: Thu, 2 Sep 2004 16:08:36 +0200 (MEST)

> > > >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.
gmtime is not rich, just look at the implementations. you can easily replace
the formatting by another equivalent implementation which is less than 50
lines of C that directly converts to a string.  

And what would emebedded system do with such a time? They would compare it against
which value? If anything like certificate validation is involved,
string processing etc is necessary anyway, and if you consider the size
of an asn1 decoder, sorry, telling that gmtime or strftime are 'rich'
is a somewhet weak argument. 
 
> 
> 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.

id-signingTime only has UTC:

   UTCTime values must be expressed in Greenwich Mean Time (Zulu) and
   must include seconds (i.e., times are YYMMDDHHMMSSZ), even where the
   number of seconds is zero.  Midnight (GMT) must be represented as
   "YYMMDD000000Z".  Century information is implicit, and the century
   must be determined as follows:

      Where YY is greater than or equal to 50, the year shall be
      interpreted as 19YY; and

      Where YY is less than 50, the year shall be interpreted as 20YY.

   GeneralizedTime values shall be expressed in Greenwich Mean Time
   (Zulu) and must include seconds (i.e., times are YYYYMMDDHHMMSSZ),
   even where the number of seconds is zero.  GeneralizedTime values
   must not include fractional seconds.

You might propose 

      SigningTime ::= Time

      Time ::= CHOICE {
        utcTime          UTCTime,
        generalizedTime  GeneralizedTime,
	epochSeconds     INTEGER}

in CMS to avoid all complications about multiple values, ie. when
having id-SigningTime and id-BinarySigningTime together, well, this
creates compartibility problems. 

> 
> > > >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.
All id-SigningTime values are in Zulu, the necessary adjustment to convert a
UTC to a Generalized time is exteremely simple. 

> 
> >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...
Well, look into the free sources. Adding 50 lines of code is less than
adding whatever logic would be necessary to check inconsistent combinations
of id-SigningTime and id-BinarySigningTime.   

> 
> >'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.
No, one should reference some appropriate texts. Similar, I
don't think that it is necessary to teach people about the variable
length nature of an ASN1 INTEGER. 

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

Does silence to this question mean that you don't see any use in the intended
scenario? If so, where is the beef? 

> >
> >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.
I think, there are at least two Peter who don't see a need for this spec.