Re: [Trans] RFC 6962 clarification: entry type vs SCTs origin

Rob Stradling <rob.stradling@comodo.com> Mon, 22 September 2014 10:29 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 AD5D51A1A98 for <trans@ietfa.amsl.com>; Mon, 22 Sep 2014 03:29:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.41
X-Spam-Level: *
X-Spam-Status: No, score=1.41 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 ymLWBLqo_1oS for <trans@ietfa.amsl.com>; Mon, 22 Sep 2014 03:29:47 -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 8CD211A1A97 for <trans@ietf.org>; Mon, 22 Sep 2014 03:29:45 -0700 (PDT)
Received: (qmail 4979 invoked by uid 1000); 22 Sep 2014 10:29:44 -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, 22 Sep 2014 11:29:44 +0100
Message-ID: <541FFA17.2000607@comodo.com>
Date: Mon, 22 Sep 2014 11:29:43 +0100
From: Rob Stradling <rob.stradling@comodo.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.1.0
MIME-Version: 1.0
To: Fabrice Gautier <fabrice.gautier@gmail.com>, "trans@ietf.org" <trans@ietf.org>
References: <CANOyrg9pSx7mNkAUPNhYPiqWqGm9jv7kN4A--BWcDeuiNzZR8w@mail.gmail.com>
In-Reply-To: <CANOyrg9pSx7mNkAUPNhYPiqWqGm9jv7kN4A--BWcDeuiNzZR8w@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/lpVgpWAx-RYtCLAXeW9KWHG9g2g
Subject: Re: [Trans] RFC 6962 clarification: entry type vs SCTs origin
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, 22 Sep 2014 10:29:49 -0000

On 19/09/14 19:50, Fabrice Gautier wrote:
> Hi,
>
> Since in RFC6962, the entry type in an SCTs is not explicit, one has
> to either guess or try both type in order to validate the SCTs.
>
> Does it make sense to infer the entry type from the origin of the SCT?
>
> If the SCT is embedded in a cert, it has to be a precert entry. In
> case of an SCT in the TLS handshake, I would expect in most case it's
> an x509 entry.

For RFC6962, an SCT sent via the CT TLS extension or OCSP Stapling MUST 
have an entry_type of x509_entry.

> But are there any situations where having a SCT with precert entry in
> the TLS extension or OCSP response would make sense ?

For 6962-bis, yes.

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

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