Re: [Trans] Clarification regarding SCTs and intermediates.

Rob Stradling <rob.stradling@comodo.com> Mon, 01 September 2014 10:15 UTC

Return-Path: <rob.stradling@comodo.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 D62971A031D for <trans@ietfa.amsl.com>; Mon, 1 Sep 2014 03:15:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.609
X-Spam-Level:
X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_NET=0.611, 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 PMV002785NOq for <trans@ietfa.amsl.com>; Mon, 1 Sep 2014 03:15:01 -0700 (PDT)
Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91E411A0282 for <trans@ietf.org>; Mon, 1 Sep 2014 03:15:00 -0700 (PDT)
Received: (qmail 5692 invoked by uid 1000); 1 Sep 2014 10:14:58 -0000
Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Mon, 01 Sep 2014 11:14:58 +0100
Message-ID: <54044722.60205@comodo.com>
Date: Mon, 01 Sep 2014 11:14:58 +0100
From: Rob Stradling <rob.stradling@comodo.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Fabrice Gautier <fabrice.gautier@gmail.com>, "trans@ietf.org" <trans@ietf.org>
References: <CANOyrg9z5w_ZmCv0X_BU0eCnRRj+DH-XEWcZ2uJ_notxxMmGkg@mail.gmail.com>
In-Reply-To: <CANOyrg9z5w_ZmCv0X_BU0eCnRRj+DH-XEWcZ2uJ_notxxMmGkg@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/xYIhAGKunkQrLHek9PB4xS7PoFM
Subject: Re: [Trans] Clarification regarding SCTs and intermediates.
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: Mon, 01 Sep 2014 10:15:04 -0000

Hi Fabrice.  Some comments inline...

On 28/08/14 17:13, Fabrice Gautier wrote:
> Hi all,
>
> Per my reading of rfc 6962, it seems that SCT (in that RFC) are only
> produced for Leaf certificates. 6962-bis introduce a possibility that
> intermediates certs are also logged and SCT produced for them.
> (Section 3.2.3. Using a Name-Constrained Intermediate CA)
>
> This raised a couple questions:
>
> - How are SCTs for intermediates provided to TLS clients ? Can they be
> provided through the TLS extension? Through the OCSP response?
> Embedded in the leaf cert ? Or only embedded in the intermediate cert
> ?
>
> - If intermediates SCTs can be provided by the same channel as SCTs
> for leaf certs, how is the TLS client supposed to know which cert
> correspond to a given SCT? Should the TLS client just try all the
> certs in the chain until the signature match ? - afaict, there is no
> data in the SCT that bind it to the cert, beside the signature.

http://trac.tools.ietf.org/wg/trans/trac/ticket/10
http://trac.tools.ietf.org/wg/trans/trac/ticket/23

<snip>
> In 6962-bis, section 3.2.3, there is some language about what kind of
> intermediate CA are acceptable to log. It seems that at least some
> logs clients should also check that intermediates CA with SCTs do obey
> those rules. I'm not sure if it's the role of TLS clients, Auditors,
> Monitors or all of them to do so.

Good point.  I've just created 
http://trac.tools.ietf.org/wg/trans/trac/ticket/48

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online