[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <21845.1348585794@warthog.procyon.org.uk>
Date: Tue, 25 Sep 2012 16:09:54 +0100
From: David Howells <dhowells@...hat.com>
To: rusty@...tcorp.com.au
Cc: dhowells@...hat.com, herbert@...dor.hengli.com.au,
pjones@...hat.com, jwboyer@...hat.com,
linux-crypto@...r.kernel.org,
linux-security-module@...r.kernel.org,
linux-kernel@...r.kernel.org, keyrings@...ux-nfs.org
Subject: Wrong system clock vs X.509 date specifiers
The X.509 certificate has a pair of times in it that delineate the valid
period of the cert, and I'm checking that the system clock is within the
bounds they define before permitting you to use the cert. I've been setting
the expiry date to be 100 years in the future - by which time hopefully I
won't have to worry about it - but occasionally clock skew means a freshly
built kernel won't boot because the machine trying to boot doesn't think that
the start time has been reached yet.
Do we actually want to do this, however? Or should we just ignore the times?
Or just the start time?
Unfortunately, the ASN.1 says the field are mandatory, and openssl doesn't
seem to give you a way to backdate the start time.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists