Rich Salz wrote:
>
> > time_t TSPX_GENERALIZEDTIME_print(BIO *bp, ASN1_GENERALIZEDTIME *tm,int gmt) {
> ...
> > if (strncmp(tm->data,strtime,15) < 0)
> > test -= (time_t)(1 << i) ;
>
> This is curious code. It is trying to treat the TIME datatype as
> opaque, but then it looks directly at the data field. :) Why not just
> look at the data field, understand the decoding, and crack it open
> directly? I.e., look at ASN1_GENERALIZEDTIME_set() and
> ASN1_UTCTIME_set().
>
> it would be nicer if Dr. Henson wrote ASN1_TIME_to_time_t, tho. :)
> But see below.
>
> > long ASN1_INTEGER_get(ASN1_INTEGER *a)
>
> The problem is that this fails if the number can't fit into a long. (For
> example, a CA which puts a 128bit UUID/GUID as the certificate serial
> number.) And there's no clean way to tell (a bit ugly, indeed:). The
> ASN_TIME_get function could have the same problem, since a four-digit
> year could easily exceed the common 32bit implementation of time_t ...
I'm getting confused here. The original query was to convert
ASN1_UTCTIME to time_t, so what's wrong with ASN1_UTCTIME_get()? Well
other than the timezone issue mentioned in the source.
Steve.
--
Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED]
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
