Re: [Trans] Precertificate format

Rob Stradling <rob.stradling@comodo.com> Wed, 10 September 2014 09:03 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 8AFB01A06B8 for <trans@ietfa.amsl.com>; Wed, 10 Sep 2014 02:03:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.29
X-Spam-Level:
X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 EeVHp-6hHWSJ for <trans@ietfa.amsl.com>; Wed, 10 Sep 2014 02:03:17 -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 AADDF1A06C2 for <trans@ietf.org>; Wed, 10 Sep 2014 02:03:16 -0700 (PDT)
Received: (qmail 11678 invoked by uid 1000); 10 Sep 2014 09:03:13 -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; Wed, 10 Sep 2014 10:03:13 +0100
Message-ID: <541013D1.8020006@comodo.com>
Date: Wed, 10 Sep 2014 10:03:13 +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: Watson Ladd <watsonbladd@gmail.com>
References: <540DFA75.2040000@gmail.com> <540E0E90.1070208@bbn.com><CAFewVt5kZqw0-W7PqtFHe7yJUsR9PqVJ6C74ZShgo0qs19wLjA@mail.gmail.com><544B0DD62A64C1448B2DA253C011414607D07DC251@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM><CAFewVt4FpwpXhcrW0mM6atASBh6k9jDb3DCCsDBNppJBrkjwXQ@mail.gmail.com><4c67a3bd-ff97-43d3-8e1f-449954b59f02@email.android.com> <CACsn0ckPm2k9q-aFZJPJLBNVXSwa_KS-pjdXDj6UU4VRGttsSw@mail.gmail.com>
In-Reply-To: <CACsn0ckPm2k9q-aFZJPJLBNVXSwa_KS-pjdXDj6UU4VRGttsSw@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/GHF9YNVHPIb2r3ivlQUoJ8eMSNI
Cc: Rick Andrews <Rick_Andrews@symantec.com>, "trans@ietf.org" <trans@ietf.org>, Brian Smith <brian@briansmith.org>, Kyle Hamilton <aerowolf@gmail.com>, Stephen Kent <kent@bbn.com>
Subject: Re: [Trans] Precertificate format
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: Wed, 10 Sep 2014 09:03:20 -0000

On 10/09/14 02:25, Watson Ladd wrote:
> On Tue, Sep 9, 2014 at 4:40 PM, Kyle Hamilton <aerowolf@gmail.com> wrote:
>> I think the best way to change a Certificate into a Precertificate would be
>> to alter the first field of the tbsCertificate to be non-optional and
>> explicitly tagged as something other than tag [0]. Then, reconstruct the
>> actual tbsCertificate by changing the first field to tag [0], perform any
>> other necessary edits (like, for name redaction), re-encode the
>> validly-tagged tbsCertificate to DER, and digest the encoded data.
>
> Let's back up a bit: we want to ensure that the certificate chains
> browsers use are a matter of public record. To do this we need to
> record the chain in a log, and give the server back a way to prove
> "yes, we've seen this chain" from the log. What I don't understand
> here is the role of the CA and the Precertificate in this process.

Hi Watson.

Without Precertificates, we would have to wait for all of the world's 
TLS Servers to be updated to support the RFC6962 TLS extension and/or 
OCSP Stapling before TLS Clients would then be able/willing to abort TLS 
handshakes when an SCT is not provided.  We don't want to have to wait 
that long!

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