Re: [Trans] [ct-policy] Re: Certificate Transparency Newsletter - August 2015
Rob Stradling <rob.stradling@comodo.com> Mon, 19 October 2015 14:06 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 1E0791A6FCB for <trans@ietfa.amsl.com>; Mon, 19 Oct 2015 07:06:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.279
X-Spam-Level:
X-Spam-Status: No, score=-5.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, 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 NihEYtlzN7NX for <trans@ietfa.amsl.com>; Mon, 19 Oct 2015 07:05:59 -0700 (PDT)
Received: from mmextmx2.mcr.colo.comodoca.net (mail1.comodoca.com [91.209.196.72]) (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 26AA11A6FA3 for <trans@ietf.org>; Mon, 19 Oct 2015 07:05:58 -0700 (PDT)
Received: (qmail 28598 invoked by uid 1004); 19 Oct 2015 14:05:55 -0000
Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Mon, 19 Oct 2015 15:05:55 +0100
Received: (qmail 18273 invoked by uid 1000); 19 Oct 2015 14:05:55 -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, 19 Oct 2015 15:05:55 +0100
To: Tom Ritter <tom@ritter.vg>
References: <CAP9QY5YXp2x5PGwfAQQJy2wRz4N9TFWh4X2M3rRrHzF4B+0S+g@mail.gmail.com> <5624D492.8040400@comodo.com> <CA+cU71k073s2EL2bW72DkmjipKF8wsYH-=RrZa_xmVQcvTPt_g@mail.gmail.com>
From: Rob Stradling <rob.stradling@comodo.com>
Message-ID: <5624F8C3.8020301@comodo.com>
Date: Mon, 19 Oct 2015 15:05:55 +0100
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <CA+cU71k073s2EL2bW72DkmjipKF8wsYH-=RrZa_xmVQcvTPt_g@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/trans/kE4wuZseCK-ydHeuueOOo_Vr_xs>
Cc: "ct-policy@chromium.org" <ct-policy@chromium.org>, "trans@ietf.org" <trans@ietf.org>, certificate-transparency <certificate-transparency@googlegroups.com>
Subject: Re: [Trans] [ct-policy] Re: Certificate Transparency Newsletter - August 2015
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: <https://mailarchive.ietf.org/arch/browse/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, 19 Oct 2015 14:06:02 -0000
On 19/10/15 14:29, Tom Ritter wrote: > On 19 October 2015 at 06:31, Rob Stradling wrote: >> On 17/08/15 18:24, 'Adam Eijdenberg' via certificate-transparency wrote: >>> >>> (posted to certificate-transparency@googlegroups.com, trans@ietf.org >>> and ct-policy@chromium.org) >> >> <snip> >>> >>> Lookahead: >>> - We're very interested in exploring how we make it viable for a >>> site-owner to be able to opt-in to requiring CT, ahead of any general >>> browser-enforced deadlines. We would welcome participation in helping >>> define what this might look like in a manner that would work well for >>> both browsers and site-owners. >> >> >> Adam, >> >> RFC 7633: "X.509v3 Transport Layer Security (TLS) Feature Extension" >> >> This newly standardized certificate extension could be used to signal that >> the TLS server MUST send the CT TLS extension. >> >> I realize that this may not suit many early adopters, since few deployed >> servers support the CT TLS extension yet. But I figured it was worth >> mentioning. > > It could... but that seems awfully limited. Requiring CT is a lot > easier than requiring one of the specific forms. If you change > infrastructure, and lose the ability to include a TLS Extension, you > can at least staple OCSP or get them embedded in a cert. That's true. Perhaps 6962-bis should prohibit or recommend against using TLS Feature for the CT TLS extension then. Or... Actually, I can't find any explicit requirement in RFC7633 that says words to the effect of "The TLS server MUST send TLS extension X". The actual requirements are expressed more vaguely than that. e.g. "A server offering an end-entity certificate with a TLS feature extension MUST satisfy a client request for the specified feature" "If these features are requested by the client in its ClientHello message, then the server MUST return a ServerHello message that satisfies this request." So, perhaps 6962-bis could specify that, if a TLS client sends the CT TLS extension and the TLS server's cert contains the TLS Feature cert extension with the CT TLS extension identifier, then the TLS server MUST "satisfy the request" by sending SCTs via any of the three supported mechanisms (CT TLS extension, cert extension, stapled OCSP response extension). -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online
- [Trans] Certificate Transparency Newsletter - Aug… Adam Eijdenberg
- Re: [Trans] Certificate Transparency Newsletter -… Rob Stradling
- Re: [Trans] Certificate Transparency Newsletter -… Rob Stradling
- Re: [Trans] Certificate Transparency Newsletter -… Tom Ritter
- Re: [Trans] [ct-policy] Re: Certificate Transpare… Rob Stradling
- Re: [Trans] [ct-policy] Re: Certificate Transpare… Tom Ritter
- Re: [Trans] [ct-policy] Re: Certificate Transpare… Rob Stradling
- Re: [Trans] [ct-policy] Re: Certificate Transpare… Jeremy Rowley
- Re: [Trans] [ct-policy] Re: Certificate Transpare… Jeremy Rowley
- Re: [Trans] [ct-policy] Re: Certificate Transpare… Tom Ritter
- Re: [Trans] [ct-policy] Re: Certificate Transpare… Melinda Shore