Bug#610806: libgnutls26 appears to mis-parse GeneralizedTime objects that use a non-UTC time
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Sat Jan 22 22:25:21 UTC 2011
On 01/22/2011 05:06 PM, Simon Josefsson wrote:
> RFC 5280 says:
> 22.214.171.124.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 126.96.36.199 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.
What do you think? Maybe we should ask the folks at the EFF's SSL
Observatory  how many real-world certs they've found that represent
their validities this way.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1030 bytes
Desc: OpenPGP digital signature
More information about the Pkg-gnutls-maint