Re: [Trans] [trans] #77 (rfc6962-bis): normative client behavior specified in Section 5

Stephen Kent <kent@bbn.com> Mon, 06 July 2015 18:33 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 525B51B2F5C for <trans@ietfa.amsl.com>; Mon, 6 Jul 2015 11:33:47 -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 7Xq-XesHOI1v for <trans@ietfa.amsl.com>; Mon, 6 Jul 2015 11:33:46 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C7CB1B2F69 for <trans@ietf.org>; Mon, 6 Jul 2015 11:33:46 -0700 (PDT)
Received: from ssh.bbn.com ([192.1.122.15]:50733 helo=COMSEC-2.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1ZCBD6-000B2W-Oy for trans@ietf.org; Mon, 06 Jul 2015 14:33:44 -0400
Message-ID: <559ACA08.1090609@bbn.com>
Date: Mon, 06 Jul 2015 14:33:44 -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.9d9fc2bb25108f9681efa566967a94e3@tools.ietf.org> <067.905aedf191f612b7a69c90d6d2c8ea46@tools.ietf.org>
In-Reply-To: <067.905aedf191f612b7a69c90d6d2c8ea46@tools.ietf.org>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/trans/SVCxj-afmMWMpdw4BMlOp-y0oho>
Subject: Re: [Trans] [trans] #77 (rfc6962-bis): normative client behavior specified in Section 5
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 18:33:47 -0000

I see your point. 6269-bis is mostly a document specifying the
operation and interface to the log. Other parts of the document attempt to
describe how clients interact with the log, but they do so only 
superficially.
That's why I believe we need additional document specifying the behavior
of the other elements of the CT system.

You refer to "the protocol" but don't indicate which protocol you have 
in mind.
I might agree that specs for TLS client behavior in the context of TLS 
exchanges
are in scope. If so, 6269-bis needs to state that it updates TLS.

Your interpretation of the WG's agreement to expunge client behavior 
from 6269-bis
seems to encompass only the issue of whether a client rejects or accept 
a cert
accompanied by a (valid) SCT. That strikes me as rather narrow.

If a client that claims CT compliance MUST perform a series of checks to 
verify
CT compliance of a cert, what does the client do if any of these tests 
fail? It's
not useful to require a set of checks to be performed and yet not 
indicate what
happens if they fail. If no action is required, then why bother 
performing the checks?
If some action is required, or even recommended, then a spec needs to 
state what that
behavior is.

Steve

> #77: normative client behavior specified in Section 5
>
> Changes (bybenl@google.com):
>
>   * milestone:   => review
>
>
> Comment:
>
>   What has been ruled out of scope is what action clients take, not how they
>   conform to the protocol.
>
>   Suggest close wontfix.
>