Re: [Trans] [trans] #74 (rfc6962-bis): normative statement of TLS client behavior in Section 3
Stephen Kent <kent@bbn.com> Tue, 07 July 2015 15:38 UTC
Return-Path: <kent@bbn.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 6834D1A8932 for <trans@ietfa.amsl.com>; Tue, 7 Jul 2015 08:38:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Buqa8Z3waFrk for <trans@ietfa.amsl.com>; Tue, 7 Jul 2015 08:38:24 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC08C1A88FD for <trans@ietf.org>; Tue, 7 Jul 2015 08:38:24 -0700 (PDT)
Received: from ssh.bbn.com ([192.1.122.15]:36019 helo=COMSEC-2.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1ZCUwx-000C5H-Ht for trans@ietf.org; Tue, 07 Jul 2015 11:38:23 -0400
From: Stephen Kent <kent@bbn.com>
To: trans@ietf.org
References: <052.329e3339e14184dcd891ce5116d624c8@tools.ietf.org> <067.3ff0deebd05d8bff20fd4c0512edb4c3@tools.ietf.org> <559A95C7.3010107@bbn.com> <CABrd9SS1nVbYZm0L4BhtnvuWH-usU-_vHCT8EPKsvGCLovQ5AQ@mail.gmail.com> <559ACA98.2040509@bbn.com> <CABrd9STispeyFh+-bYJE7OSZ5qyWtuEraO9KM8FfF2p2jSk47Q@mail.gmail.com>
Message-ID: <559BF26F.4010407@bbn.com>
Date: Tue, 07 Jul 2015 11:38:23 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1
MIME-Version: 1.0
In-Reply-To: <CABrd9STispeyFh+-bYJE7OSZ5qyWtuEraO9KM8FfF2p2jSk47Q@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/V1p_3vLj5sP-6dZq2P_xZ1n80ik>
Subject: Re: [Trans] [trans] #74 (rfc6962-bis): normative statement of TLS client behavior in Section 3
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: Tue, 07 Jul 2015 15:38:26 -0000
Ben, > A certificate not accompanied by an SCT is not CT compliant. > This seems redundant: I would've thought that in general everything in > an RFC only applies to things that are compliant with that RFC. But if > the WG wants I don't really mind either way. I prefer the wording I suggested because it emphasizes the status of the cert relative to this spec, rather than intimating any TLS client behavior. > > OK, I get your point here, and I am happy to go either way: > > a) Update TLS to require CT, or that's not what I meant to suggest. I don't think CT is destined to become a mandatory aspect of TLS; it's an optional feature. > b) Update the I-D to say something like "CT compliant TLS clients" or > as you use below "TLS clients claiming conformance with CT", which > presumably does not update TLS? TLS is the definitive spec for the messages exchanged during its handshake. So the specs in Section 3.4 represent an update to TLS (1.2). That does not make support for CT mandatory, but it informs implementers of the new TLS extensions defined here and the processing they imply. Steve
- [Trans] [trans] #74 (client-behavior): normative … trans issue tracker
- Re: [Trans] [trans] #74 (rfc6962-bis): normative … trans issue tracker
- Re: [Trans] [trans] #74 (rfc6962-bis): normative … trans issue tracker
- Re: [Trans] [trans] #74 (rfc6962-bis): normative … trans issue tracker
- Re: [Trans] [trans] #74 (rfc6962-bis): normative … Stephen Kent
- Re: [Trans] [trans] #74 (rfc6962-bis): normative … Stephen Kent
- Re: [Trans] [trans] #74 (rfc6962-bis): normative … Ben Laurie
- Re: [Trans] [trans] #74 (rfc6962-bis): normative … Stephen Kent
- Re: [Trans] [trans] #74 (rfc6962-bis): normative … trans issue tracker
- Re: [Trans] [trans] #74 (rfc6962-bis): normative … Ben Laurie
- Re: [Trans] [trans] #74 (rfc6962-bis): normative … Stephen Farrell
- Re: [Trans] [trans] #74 (rfc6962-bis): normative … Stephen Kent
- Re: [Trans] [trans] #74 (rfc6962-bis): normative … Ben Laurie