Re: [RFC PATCH 3/4] X.509: Support leap seconds

[Rudolf Polzer]

On Mon, Jan 4, 2016 at 5:17 PM, David Howells <dhowells@xxxxxxxxxx> wrote:
> 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.
>
> This results in us passing a time with sec as 60 to mktime64(), which
> handles it as being a duplicate of the 0th second of the next minute.
>
> We can't really do otherwise without giving the kernel much greater
> knowledge of where all the leap seconds are.  Unfortunately, this would
> require change the mapping of the kernel's current-time-in-seconds.
>
> UTCTime, however, only supports a seconds value in the range 00-59, but for
> the sake of simplicity allow this with UTCTime also.
>
> Without this patch, certain X.509 certificates will be rejected,
> potentially making a kernel unbootable.
>
> Reported-by: Rudolf Polzer <rpolzer@xxxxxxxxxx>
> Signed-off-by: David Howells <dhowells@xxxxxxxxxx>
> cc: Arnd Bergmann <arnd@xxxxxxxx>
> cc: David Woodhouse <David.Woodhouse@xxxxxxxxx>
> cc: John Stultz <john.stultz@xxxxxxxxxx>
> ---
>
>  crypto/asymmetric_keys/x509_cert_parser.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/crypto/asymmetric_keys/x509_cert_parser.c b/crypto/asymmetric_keys/x509_cert_parser.c
> index 13c4e5a5fe8c..3379c0ba3988 100644
> --- a/crypto/asymmetric_keys/x509_cert_parser.c
> +++ b/crypto/asymmetric_keys/x509_cert_parser.c
> @@ -550,7 +550,7 @@ int x509_decode_time(time64_t *_t,  size_t hdrlen,
>         if (day < 1 || day > mon_len ||
>             hour > 23 ||
>             min > 59 ||
> -           sec > 59)
> +           sec > 60) /* ISO 8601 permits leap seconds [X.680 46.3] */
>                 goto invalid_time;
>
>         *_t = mktime64(year, mon, day, hour, min, sec);
>

All good. I find it a bit odd that it only allows for _one_ leap
second, although there can be technically two in a single minute - but
this is the problem of the standard, not of this code.

Best regards,

Rudolf Polzer