Re: [Trans] Precertificate format

Stephen Kent <> Wed, 10 September 2014 16:07 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1803F1A8766 for <>; Wed, 10 Sep 2014 09:07:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.853
X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QhAJK0GIvW1F for <>; Wed, 10 Sep 2014 09:07:22 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C508E1A8764 for <>; Wed, 10 Sep 2014 09:07:21 -0700 (PDT)
Received: from ([]:52081 helo=comsec.home) by with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <>) id 1XRkQh-000JOD-2h for; Wed, 10 Sep 2014 12:07:35 -0400
Message-ID: <>
Date: Wed, 10 Sep 2014 12:07:19 -0400
From: Stephen Kent <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
References: <> <><><544B0DD62A64C1448B2DA253C011414607D07DC251@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM><><> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Trans] Precertificate format
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 10 Sep 2014 16:07:27 -0000


> ...
> 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!
You noted this rationale previously, when I asked whether we really need 
pre-certs, and
I failed to reply to your message. (lost in the inbox clutter)

I understand the desire to reduced the delay in deployment.

However, the specific mechanism you mentioned, a TLS client aborting a 
handshake because
of a lack of an SCT (embedded or passed explicitly in the handshake) is 
still being debated.
Specifically, I noted that this hard fail approach, does not seem 
compatible with an
incremental deployment model, absent a lot of details. During the IETF 
meeting in Toronto,
Ben stated that he agreed that an incremental deployment model was 
desirable, and thus
requirements for TLS client behavior need to be revisited.