Hi David, On Tue, Dec 1, 2015 at 12:08 PM, David Howells <[email protected]> wrote: > There are still a couple of minor issues in the X.509 leap year handling: [...] > In addition: > > (3) The format of ASN.1 GeneralizedTime seems to be specified by ISO 8601 > [X.680 46.3] and this apparently supports leap seconds (ie. the > seconds field is 60). It's not entirely clear that ASN.1 expects it, > but we can relax the seconds check slightly for GeneralizedTime. > > UTCTime, however, only supports a seconds value in the range 00-59.
the leap second support still looks a bit suspect, as mktime64 will convert mm/dd/YYYY HH/MM/60 and mm/dd/YYYY HH/MM+1/00 to the same time64_t, essentially meaning that two different inputs can yield the same output, possibly violating ASN.1 CER and DER rules. Are you sure this is safe in this case? A typical case where this would be a bad idea is when other code serializes a message again and expects it to match the original input bytes. If this isn't done, then this leap second support should be safe. Also, while at it - apparently hour 24 is allowed by ISO 8601 too as long as minutes and seconds are zero, leading to even more non-canonicality... can you check whether this is also valid ASN.1 then? Best regards, Rudolf Polzer -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
