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

[Daniel Kahn Gillmor]

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.

What do you think?  Maybe we should ask the folks at the EFF's SSL
Observatory [0] how many real-world certs they've found that represent
their validities this way.

	--dkg

[0] https://www.eff.org/observatory

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnutls-maint/attachments/20110122/f90fffc7/attachment.pgp>