Linux cryptographic layer development
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: rusty@rustcorp.com.au
Cc: dhowells@redhat.com, herbert@gondor.hengli.com.au,
	pjones@redhat.com, jwboyer@redhat.com,
	linux-crypto@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org, keyrings@linux-nfs.org
Subject: Wrong system clock vs X.509 date specifiers
Date: Tue, 25 Sep 2012 16:09:54 +0100	[thread overview]
Message-ID: <21845.1348585794@warthog.procyon.org.uk> (raw)
In-Reply-To: <5555.1348531649@warthog.procyon.org.uk>


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

  parent reply	other threads:[~2012-09-25 15:10 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-25  0:07 [GIT PULL] Asymmetric keys and module signing David Howells
2012-09-25  0:11 ` David Howells
2012-09-25 15:09 ` David Howells [this message]
2012-09-25 15:30   ` Wrong system clock vs X.509 date specifiers Alan Cox
2012-09-25 15:35     ` David Howells
2012-09-25 15:43       ` Paolo Bonzini
2012-09-25 16:00       ` Alan Cox
2012-09-25 21:57         ` David Howells
2012-09-25 16:02       ` Tomas Mraz
2012-09-25 17:31         ` David Howells
2012-09-25 18:39           ` Tomas Mraz
2013-03-14 10:48     ` David Woodhouse
2013-03-14 12:24       ` [PATCH] Fix x509_key_preparse() not to reject keys outside their validity time range David Woodhouse
2013-03-19 21:06         ` Alexander Holler
2012-09-25 15:44 ` [GIT PULL] Asymmetric keys and module signing Kasatkin, Dmitry
2012-09-25 16:15   ` David Howells
2012-09-26  3:46 ` Rusty Russell
2012-09-26  9:09   ` David Howells
2012-09-27  0:12     ` Rusty Russell
2012-09-27  9:08       ` David Howells
2012-09-28  5:55         ` Rusty Russell
2012-09-28  8:13           ` David Howells
2012-09-28  5:58         ` [PATCH 1/2] modsign: don't use bashism in sh scripts Rusty Russell
2012-09-28  8:10           ` David Howells
2012-10-02  2:24             ` Rusty Russell
2012-09-28  5:59         ` [PATCH 2/2] modules: don't call eu-strip if it doesn't exist Rusty Russell
2012-09-28  8:11           ` David Howells
2012-09-28  6:05         ` [GIT PULL] Asymmetric keys and module signing Rusty Russell
2012-09-28  8:09           ` David Howells
2012-09-29  6:53             ` Rusty Russell
2012-09-29  7:13               ` David Howells
2012-10-01 20:41                 ` Josh Boyer
2012-10-02  3:28                   ` Rusty Russell
2012-10-02 12:17                     ` Josh Boyer
2012-09-29  7:16               ` David Howells
2012-10-02  6:12                 ` Rusty Russell
2012-10-02 14:07                   ` David Howells
2012-10-03 23:22                     ` Rusty Russell
2012-10-09 10:55                       ` Kasatkin, Dmitry
2012-10-10  9:37                         ` Rusty Russell
2012-09-28  9:23           ` David Howells
2012-09-28 10:31           ` David Howells
2012-10-03 17:50         ` [patch] MODSIGN: Fix build error with strict typechecking David Rientjes
2012-09-27  2:04   ` [GIT PULL] Asymmetric keys and module signing Mimi Zohar
2012-09-28  6:54     ` Rusty Russell
2012-09-28  6:27   ` Geert Uytterhoeven
2012-09-28  8:00     ` David Howells

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=21845.1348585794@warthog.procyon.org.uk \
    --to=dhowells@redhat.com \
    --cc=herbert@gondor.hengli.com.au \
    --cc=jwboyer@redhat.com \
    --cc=keyrings@linux-nfs.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=pjones@redhat.com \
    --cc=rusty@rustcorp.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox