Re: [Trans] OCSP and SCTs
Brian Smith <brian@briansmith.org> Sat, 30 August 2014 22:43 UTC
Return-Path: <brian@briansmith.org>
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 209ED1A212D for <trans@ietfa.amsl.com>; Sat, 30 Aug 2014 15:43:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level:
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 kYG5Nmuegewf for <trans@ietfa.amsl.com>; Sat, 30 Aug 2014 15:43:18 -0700 (PDT)
Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DE381A212A for <trans@ietf.org>; Sat, 30 Aug 2014 15:43:17 -0700 (PDT)
Received: by mail-qa0-f53.google.com with SMTP id w8so3570658qac.26 for <trans@ietf.org>; Sat, 30 Aug 2014 15:43:17 -0700 (PDT)
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 :content-transfer-encoding; bh=iF2W63lXwC5yXd+yKe2MT9yvgkDw4Jz0uqEL6nDsH+w=; b=SLgsihQ3ChaA5r6BJQZ3NJJOrGXtKwN5JWqwBQeI4/QZP1IwNuoDr9ZzSug/lwdDLR AQnqBWdJTTFEM1McfdO8qYZp7jYnUSxnwAgLXhkaHeaulIk6ExiS8v9F1beOvHruNjly IApMQOHc7MssU9N9vHWbbYaJVhH+TgERyypglFhVXjTHleVmdzh16VViM2UvdSOXFQl8 a+sXb1oEn88ICisN2x7oSkarxAI2kv2QIL8tYOrAlvFGms4/CxJnFThgdzb3i+Sm/YOC QWDCaRiCEL+CN0TsStIjt37/OToqUINt2bdCyxCRv0CIRilPXiPhtt2yonh1VQe7z+iy 3rZg==
X-Gm-Message-State: ALoCoQl1ucKMx+WAUet6AJd8RbTXjuWvSYb1OnE3P63RzTmwcNzEVSZbUif0gKCag0Q2n7gVrP2D
MIME-Version: 1.0
X-Received: by 10.140.81.134 with SMTP id f6mr22501978qgd.60.1409438597273; Sat, 30 Aug 2014 15:43:17 -0700 (PDT)
Received: by 10.224.67.133 with HTTP; Sat, 30 Aug 2014 15:43:17 -0700 (PDT)
In-Reply-To: <239CAEF3-C77D-4E0B-B64D-D715D71AD1A8@gmail.com>
References: <DCB45BF3-C979-4025-A532-0349D971E95D@gmail.com> <CAFewVt4iX=ActoRLgHTMG=Rua-wZoT8owGLDHt3s=z4vreHQeQ@mail.gmail.com> <239CAEF3-C77D-4E0B-B64D-D715D71AD1A8@gmail.com>
Date: Sat, 30 Aug 2014 15:43:17 -0700
Message-ID: <CAFewVt6me=PE5NYVD3JDokrv8JV-ZJXYgdL0dVOf-4K1bFvLSQ@mail.gmail.com>
From: Brian Smith <brian@briansmith.org>
To: Fabrice <fabrice.gautier@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/DtFIMwivaVWEk2tl6FG0QqBHFsM
Cc: "trans@ietf.org" <trans@ietf.org>
Subject: Re: [Trans] OCSP and SCTs
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: Sat, 30 Aug 2014 22:43:19 -0000
On Sat, Aug 30, 2014 at 3:22 PM, Fabrice <fabrice.gautier@gmail.com> wrote: >> On Aug 30, 2014, at 14:16, Brian Smith <brian@briansmith.org> wrote: > I understand the issue you describe and how stapling has less opportunities for failures and is a MUST for TLS clients, but my question was really about what should a TLS client do when it does not get an OCSP response through stapling (RFC6066) but get one directly from the OCSP responder or potentially other means. > > To me, it seems logical for the TLS clients to process SCTs found in those responses, no matter how it got them. When the client is enforcing CT, it should reject the certificate due to the missing SCT before it even attempts revocation checking. Thus, it would never fetch the OCSP response and so it would never learn the SCT from a fetched response. Cheers, Brian
- [Trans] OCSP and SCTs Fabrice
- Re: [Trans] OCSP and SCTs Brian Smith
- Re: [Trans] OCSP and SCTs Fabrice
- Re: [Trans] OCSP and SCTs Brian Smith
- Re: [Trans] OCSP and SCTs Fabrice
- Re: [Trans] OCSP and SCTs Brian Smith
- Re: [Trans] OCSP and SCTs Fabrice Gautier
- Re: [Trans] OCSP and SCTs Kyle Hamilton
- Re: [Trans] OCSP and SCTs Rob Stradling
- Re: [Trans] OCSP and SCTs Rob Stradling
- Re: [Trans] OCSP and SCTs Stephen Kent