Bug#610806: libgnutls26 appears to mis-parse GeneralizedTime objects that use a non-UTC time

[Simon Josefsson]

Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:

> On 01/22/2011 05:06 PM, Simon Josefsson wrote:
>> RFC 5280 says:
>> 
>> 4.1.2.5.2.  GeneralizedTime
>> 
>>    The generalized time type, GeneralizedTime, is a standard ASN.1 type
>>    for variable precision representation of time.  Optionally, the
>>    GeneralizedTime field can include a representation of the time
>>    differential between local and Greenwich Mean Time.
>> 
>>    For the purposes of this profile, GeneralizedTime values MUST 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.
>> 
>> It is not clear to me whether your timestamps that fails with GnuTLS
>> conforms to this requirement or not?
>
> Thanks for the reference, Simon!  I'd say you are correct that the
> timestamps in America.New_York.pem do not conform to this specification.
>
> However, section 4.1.2.5 also says:
>
>   Conforming applications MUST be able to process validity dates that
>   are encoded in either UTCTime or GeneralizedTime.
>
> This seems like a bit of a contradiction to me, and i don't really know
> how to resolve it cleanly.  On the one hand, i'll make sure that any
> tools i write will encode data according to the spec.  On the other
> hand, it seems like GnuTLS is not in conformance with the clause above.

I don't see the contradiction?  The spec also says:

   For the purposes of this profile, 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.  Conforming
   systems MUST interpret the year field (YY) as follows:

Did you find any timestamp that conforms to this format that GnuTLS
cannot parse?

GnuTLS should be able to parse both UTCTime and GeneralizedTime
following the allowed formats, see lib/x509/common.c.

Possibly there should be more of an error message in this situation
though.  Unless these invalid certificates are common, I'd prefer to
just discard them as bogus.

/Simon