Daniel Kahn Gillmor <d...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
