[Trans] Clarification regarding SCTs and intermediates.

Fabrice Gautier <fabrice.gautier@gmail.com> Thu, 28 August 2014 16:14 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 BDBD31A875F for <trans@ietfa.amsl.com>; Thu, 28 Aug 2014 09:14:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Level:
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 s-42fGRkgrlJ for <trans@ietfa.amsl.com>; Thu, 28 Aug 2014 09:14:17 -0700 (PDT)
Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 720BB1A875C for <trans@ietf.org>; Thu, 28 Aug 2014 09:14:15 -0700 (PDT)
Received: by mail-we0-f177.google.com with SMTP id u56so1001837wes.22 for <trans@ietf.org>; Thu, 28 Aug 2014 09:14:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=qQbr/Gllp+gsrpQxz0cW9pkDy8CpgJnc9r6c9RJWJx0=; b=ZULXJyFcXbDcVd7QWxk/Cd+/7JLL83ymd/z8dQJWJ8Qfdw7uIUD94qZC04w4UC48q1 RwfC0KvzLs2OmK+ECG1CA1gxfAq5pe6N851Ph2aZ46Y5VCT7A4Sna92WqfbDbTAVsyc8 /mDj9juFAoALrH1mQeaqKen20FZlqvJw11oo1RpWFB+nY2R0W240wtx6yvQQQGa2ju9v 7KoEzQ4FeXhU90cqk0EOpkYdHvOUftA1O8vrtanlxZXchkDKqF3akFghfoRYqAeFcG2R hns6HWE/EDR1+OOfX6WuREwctKqZcvlYrMmBKWDnImw/j9xNYVzhFLbam31+X8bMLBz/ GCHQ==
X-Received: by 10.180.208.111 with SMTP id md15mr7262980wic.3.1409242454136; Thu, 28 Aug 2014 09:14:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.253.200 with HTTP; Thu, 28 Aug 2014 09:13:54 -0700 (PDT)
From: Fabrice Gautier <fabrice.gautier@gmail.com>
Date: Thu, 28 Aug 2014 09:13:54 -0700
Message-ID: <CANOyrg9z5w_ZmCv0X_BU0eCnRRj+DH-XEWcZ2uJ_notxxMmGkg@mail.gmail.com>
To: "trans@ietf.org" <trans@ietf.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/duinxMYKQe77qX9k4NhsoHE6XF4
Subject: [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: Thu, 28 Aug 2014 16:14:18 -0000

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.

- If I, a TLS client, have SCTs for both leafs and certs, assuming I
figure out which one is for which, what kind of policies are we
expecting the TLS client to apply. I realize this is probably out of
scope for the RFC, but I'm curious what the expectation are here.


In both 6962, and 6962-bis, the TLS client behavior is very shortly
described in section 5.2. TLS Clients. It basically boils down to one
sentence "they (TLS clients) should validate the SCT by computing the
signature input from the SCT data as well as the certificate and
verifying the signature,"

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.

Thanks

-- Fabrice