Re: [Trans] [trans] #74 (rfc6962-bis): normative statement of TLS client behavior in Section 3
Stephen Kent <kent@bbn.com> Mon, 06 July 2015 14:58 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 8C8CE1A88DB for <trans@ietfa.amsl.com>; Mon, 6 Jul 2015 07:58:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 zyM2s1QPoT4t for <trans@ietfa.amsl.com>; Mon, 6 Jul 2015 07:58:54 -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 04D2A1A8934 for <trans@ietf.org>; Mon, 6 Jul 2015 07:58:54 -0700 (PDT)
Received: from ssh.bbn.com ([192.1.122.15]:58540 helo=COMSEC-2.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1ZC7rB-000DG7-11 for trans@ietf.org; Mon, 06 Jul 2015 10:58:53 -0400
Message-ID: <559A97AC.6040305@bbn.com>
Date: Mon, 06 Jul 2015 10:58:52 -0400
From: Stephen Kent <kent@bbn.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: trans@ietf.org
References: <052.329e3339e14184dcd891ce5116d624c8@tools.ietf.org> <067.3ff0deebd05d8bff20fd4c0512edb4c3@tools.ietf.org>
In-Reply-To: <067.3ff0deebd05d8bff20fd4c0512edb4c3@tools.ietf.org>
Content-Type: multipart/alternative; boundary="------------060803070404080406050904"
Archived-At: <http://mailarchive.ietf.org/arch/msg/trans/zF1PWwInUQ-CU1Nk4yAVggN83h8>
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: Mon, 06 Jul 2015 14:58:55 -0000
I note the following text from the -07 i-D that seems to specify TLS client behavior: Section 1 TLS clients can thus require that all certificates they accept as valid have been logged. (doe not use 2918 reserved words, but ...) Section 3 A certificate not accompanied by an SCT (either for the end-entity certificate or for a name-constrained intermediate the end-entity certificate chains to) *MUST NOT be considered compliant by TLS clients*. Section 3.4 *TLS clients MUST implement all three mechanisms*. Section 3.4.1 *TLS clients that support the extension SHOULD *send a ClientHello extension with the appropriate type and empty "extension_data". *TLS clients SHOULD include *the extension type in the ClientHello, Section 5.3 in addition to normal validation of the certificate and its chain, *TLS** ** clients SHOULD validate the SCT *by computing the signature input from the SCT data as well as the certificate and verifying the signature, using the corresponding log's public key. *A TLS client MAY audit the corresponding log *by requesting, and verifying, a Merkle audit proof for said certificate.* If the TLS** ** client holds an STH that predates the SCT, it MAY, *in the process of auditing, request a new STH from the log (Section 4.3), then verify it by requesting a consistency proof (Section 4.4). *TLS clients MUST reject SCTs whose timestamp* is in the future. Section 8.1 *Misissued certificates that have not been publicly logged, and thus** ** do not have a valid SCT, will be rejected by TLS clients.* > #74: normative statement of TLS client behavior in Section 3 > > > Comment (by benl@google.com): > > Describing how the protocol works from the client's POV is _not_ about > client behaviour, it is about the client's understanding of the situation. > How it behaves as a result of that understanding is behaviour. > > I propose this should be closed "wontfix". >
- [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