IETF Logo Mail Archive

Re: [Trans] OCSP and SCTs

Fabrice <fabrice.gautier@gmail.com> Sun, 31 August 2014 04:06 UTC

Return-Path: <fabrice.gautier@gmail.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 22A531A6F7E for <trans@ietfa.amsl.com>; Sat, 30 Aug 2014 21:06:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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 lBAxI0k3lrH9 for <trans@ietfa.amsl.com>; Sat, 30 Aug 2014 21:05:57 -0700 (PDT)
Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A94C1A6F7F for <trans@ietf.org>; Sat, 30 Aug 2014 21:05:56 -0700 (PDT)
Received: by mail-pa0-f54.google.com with SMTP id fb1so9455107pad.27 for <trans@ietf.org>; Sat, 30 Aug 2014 21:05:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=unDZ9awBFUzfIpWwiTimMQqZj0Qz48tlNzVrmDWrKec=; b=DIBAQRdZqAMOb6ciKpDYExFlsHBTqgctwBVVUYlycTvR7ei3n1ocrRO/ihvlj1qJ4C bnwc/R3GR4cnsgfBpdw3RxMgtjggqrAQiBGbakfys6q5lkdCJ0g9VV1YI6cjQkhoNjIy Gic8t/C8nQTwh657WzAWUsoykog9XlPpOWthFe6kAIDmjTCSDEweE6dl03uexxDIrIl7 xhOYLXDP/OnJde57IeyYfgp2AyXI1N82hI1DIgWGKKfIGhvyb/SrpSdBFzNsl9R2WY9y VtVQirRhXWXNkGCNpUMr5Cnf+6+LlkWQaybAre38wu6qc6N00z5hJI/IJ+CMnigarxeg aQkg==
X-Received: by 10.66.65.130 with SMTP id x2mr28014030pas.79.1409457955623; Sat, 30 Aug 2014 21:05:55 -0700 (PDT)
Received: from [10.0.1.4] (c-67-188-142-21.hsd1.ca.comcast.net. [67.188.142.21]) by mx.google.com with ESMTPSA id ry9sm4117182pbc.94.2014.08.30.21.05.53 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 30 Aug 2014 21:05:53 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-9E9D4C9F-7002-4BBF-AF1C-9825D01DFC06"
Mime-Version: 1.0 (1.0)
From: Fabrice <fabrice.gautier@gmail.com>
X-Mailer: iPhone Mail (11D257)
In-Reply-To: <CAFewVt6me=PE5NYVD3JDokrv8JV-ZJXYgdL0dVOf-4K1bFvLSQ@mail.gmail.com>
Date: Sat, 30 Aug 2014 21:05:51 -0700
Content-Transfer-Encoding: 7bit
Message-Id: <1929A47D-06A5-4550-A26E-902DE964F980@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> <CAFewVt6me=PE5NYVD3JDokrv8JV-ZJXYgdL0dVOf-4K1bFvLSQ@mail.gmail.com>
To: Brian Smith <brian@briansmith.org>
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/_HCeTjLXVPnoTaGelylTzXOi83U
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: Sun, 31 Aug 2014 04:06:03 -0000

> On Aug 30, 2014, at 15:43, Brian Smith <brian@briansmith.org> wrote:
> 
> 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.


I don't see any language in the RFC or draft that suggest there is an ordering between revocation checking and CT validation, or any other parts of the certificate validation. The only related language I found is rather succinct:
In addition to normal validation of the certificate and its chain, they should validate the SCT (...) 

If there are good reasons to ignore SCTs in non-stapled OCSP responses, I'd like to know about them, and it probably should be mentioned in the RFC.

> 
> Cheers,
> Brian

v2.23.0 | Report a Bug | By Email