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

From: Peter Sylvester <[email-masked]>
Date: Wed, 1 Sep 2004 19:59:22 +0200 (MEST)

I have forgotten: 

The proposed format and SMIME attributes serves the same purpose as
an existing one, i.e. id-signingTime 

Nothing is said about what to do when both attributes are present,
how they should be treated when available together. 

One probably wants to set both, so instead of saving data and cpu,
one will add.  

> 
> > >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, ...
> 
> Showing this time to a user always requires some conversion, while 
> displaying a generaizedtime does not. 
> 
> 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. 
>