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

From: Peter Sylvester <[email-masked]>
Date: Thu, 2 Sep 2004 14:49:00 +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) ;
	} 

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

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. 

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

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

---

From: Russ Housley <[email-masked]>
Date: Thu, 02 Sep 2004 09:01:43 -0400

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

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

>may finally end up before user: signature not valid because not after 

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.

>and  may create confusion, but anyway.'

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

Russ

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 03 Sep 2004 16:14:17 +1200

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

As the author of the crypto toolkit that runs on a larger range of embedded
systems than any other [0], I can state that this point is invalid.  I've got
code running on systems without a clock that nevertheless still have 
mktime() (OK, so you can't actually check the date against anything once
you've read it, but you can at least read it).  I've never encountered a 
system where reading a UTCTime is a problem.

Peter.

[0] Until someone else proves otherwise :-).

---

From: Russ Housley <[email-masked]>
Date: Sat, 04 Sep 2004 12:20:37 -0400

Thanks for this new information.  However, i am aware of smartcard 
environments without mktime().

Russ