Re: [Trans] Proving certificate freshness

Ben Laurie <benl@google.com> Wed, 01 October 2014 13:59 UTC

Return-Path: <benl@google.com>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1758C1A19EE for <trans@ietfa.amsl.com>; Wed, 1 Oct 2014 06:59:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.565
X-Spam-Level:
X-Spam-Status: No, score=-1.565 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=0.6, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvPl4KqK90B0 for <trans@ietfa.amsl.com>; Wed, 1 Oct 2014 06:59:42 -0700 (PDT)
Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F7431A87E2 for <trans@ietf.org>; Wed, 1 Oct 2014 06:59:42 -0700 (PDT)
Received: by mail-qc0-f179.google.com with SMTP id x3so322996qcv.24 for <trans@ietf.org>; Wed, 01 Oct 2014 06:59:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zn0opS7mGrqSQi87bDQ4qcz3ymBu0qKHfD8TjgPIeRk=; b=Ht4ZtgurIPHpyWfdFLH/LP5yoF3LBvL1ZpTnh2G6hp6gDK1V2DxSFnx3BoFNrgluX6 osc+TFrd1CtweX3K5s38NjXHhi5oGL/LZ0+yRPyDskvWG5f/3Dp4ghn5hsf5+6EoVuOd BE/voZuqxOBYfHoBcBkOVOrwOVnRJwZjuZqiVVOH4OkW7Qg24G6yPIb8ZBGPzZOLFA3U /2/KkeH1MzgCyrHpLN0gUMoL9ag6GzWUCRDMjefa/79KTMfJ7UkKN8QU/d8ADqGL17JZ u1/IFGBfPpAk+PPyqSvd+aBUC41n+Pjk2c98DJxye6MKbmOiobYvyM1b825RchEI6pv5 0s3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zn0opS7mGrqSQi87bDQ4qcz3ymBu0qKHfD8TjgPIeRk=; b=L/lhQILjOfTstEhnramNp7ZATSkiLe9Z5SPNuUyvq2qL/7VLnYv4/pEqM5BUlMTUrM ysF1cDhK/Dhnog4iIqFmZD7DavLI5HMIb46LmikWemcHxoQpM9rgwHxJQnmeqMbWc8EV uA5VdgFD6W1WPVsBrFRumv8cvbyR1ftWk3GvlOr1cKQ186D1KgPhJO3NabL6/V6PtdVA akC2R9oAXFO75gkJs55jduhKjpEEAPEeisbTQch1jVZcezkUOF7kzf+bYdFVcqa/axeF ErXiEPicDeRukS6ohqt714bwMwd8d61e0w7BUpFHXMTLWYa2n8h+Qq8xrr6BzdJiWcMK OEPw==
X-Gm-Message-State: ALoCoQlyJ6IQOEiKYX5Mrp6U5flLIXavOhjOvRfDZ0uoyd28PRjQvjSIsyhz56D1ZuwM6sslIHQd
MIME-Version: 1.0
X-Received: by 10.224.69.195 with SMTP id a3mr74800589qaj.59.1412171981271; Wed, 01 Oct 2014 06:59:41 -0700 (PDT)
Received: by 10.229.247.198 with HTTP; Wed, 1 Oct 2014 06:59:41 -0700 (PDT)
In-Reply-To: <CAA7UWsXpTzMgrDNo73cB5U_Q3wS2xDsGpws-4njXqEDJm-TG3A@mail.gmail.com>
References: <CAA7UWsXpTzMgrDNo73cB5U_Q3wS2xDsGpws-4njXqEDJm-TG3A@mail.gmail.com>
Date: Wed, 01 Oct 2014 14:59:41 +0100
Message-ID: <CABrd9SR4s217w56vSMj6vqDJ07v_h_gMh0XbGkVz6KPqDn7R4g@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: David Leon Gil <coruus@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/IHD7tWMFNVvVKWgSCcpgip3Ie_Q
Cc: "trans@ietf.org" <trans@ietf.org>
Subject: Re: [Trans] Proving certificate freshness
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Oct 2014 13:59:43 -0000

On 1 October 2014 04:56, David Leon Gil <coruus@gmail.com> wrote:
> Something that is rather difficult to prove, at present, is that a
> certificate has been used after it has expired or been revoked.
>
> If servers were required to include a signature over a recent STH (or
> STH+OCSP staple) along with their SCT, this would provide an easy way
> of showing that a *server* was behaving incorrectly. E.g., as a TLS
> extension:
>
> struct {
>   STH;
>   sign(SignedCertificateTimestamp || OCSP || STH);
> } FreshnessProof;
>
> This seems rather better than signing a timestamp; the STH isn't
> predictable without a colluding log, so it isn't possible to
> "accidentally" sign a future time.
>
> Any thoughts?

Interesting idea. Note that even with a colluding log, predicting a
future STH is tricky, since the log has to include any certs it's
signed SCTs for within the MMD...