[Trans] trans doc issues

Stephen Kent <kent@bbn.com> Fri, 20 June 2014 18:29 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 9BEAF1B28AF for <trans@ietfa.amsl.com>; Fri, 20 Jun 2014 11:29:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.852
X-Spam-Level:
X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 QplOD56-4FAR for <trans@ietfa.amsl.com>; Fri, 20 Jun 2014 11:29:05 -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 5C54C1B28CC for <trans@ietf.org>; Fri, 20 Jun 2014 11:28:17 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:55768 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1Wy3Xr-0009Ex-Oc; Fri, 20 Jun 2014 14:28:15 -0400
Message-ID: <53A47D3F.7090301@bbn.com>
Date: Fri, 20 Jun 2014 14:28:15 -0400
From: Stephen Kent <kent@bbn.com>
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
To: Ben Laurie <benl@google.com>
References: <CAK3OfOjiL2DTJPH3CaAjg8YGrrwN56SgQ+DnqPXx4MLbgXQN+A@mail.gmail.com> <CAHw9_iKpN7AXfrH6SzroMukrKTPR5z24U9KfWpVW-F2R_wX3ag@mail.gmail.com> <alpine.LFD.2.10.1405101722240.897@bofh.nohats.ca> <CABrd9ST7K-7RGwGD2G+kDcVSceC2ZJ-5Tz2tdp5NWa3cqBK+-w@mail.gmail.com> <CAOe4Ui=nqmCfjBYNE2CJtEs1jnbavpY4Dv-T3FRDdAwAA2dScg@mail.gmail.com> <CAK3OfOiYMJkXVR+QsCzEV0ir6u53coJz0b-JdGGD5bTTz5YcMg@mail.gmail.com> <CAOe4Ui=u0fkm9_nuXx_6gpH6jHM5pBvzjzru9O8y3bpLkA0qmw@mail.gmail.com> <CAK3OfOi6y=QAMXe_2axiavxwR5nS2Uv8SM4JxQHsvEKbUyNGCA@mail.gmail.com> <CAOe4Uimvc6e6u=fJjM1-iaOTepA33Sx5CBjMV9dB8sSLqtZoWA@mail.gmail.com> <CAK3OfOhdhWdGvvhuaGyE_p5kLy0ZX-V5sAXfoLGP_8d8vPJDgg@mail.gmail.com> <5371ACFB.5020604@gmail.com> <CADqLbzLJWSfOOqZaieBijtX7dDR0BaW5doTZtgi=72-VjOUVMg@mail.gmail.com> <537E3E13.30709@bbn.com> <CADqLbzJdCoULnaaa_LLois49yxFTqtmMgo7TUabCN6UEXbN7kg@mail.gmail.com> <539F408B.5050600@bbn.com> <CABrd9SS51Sh93rvgdYaCpidYs1U7hpQofGmp0oJX9f2x5TXqNw@mail.gmail.com>
In-Reply-To: <CABrd9SS51Sh93rvgdYaCpidYs1U7hpQofGmp0oJX9f2x5TXqNw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/Ixwq0JIu9wvnXWf6W0vnw0X1C6c
Cc: "trans@ietf.org" <trans@ietf.org>
Subject: [Trans] trans doc issues
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: <http://www.ietf.org/mail-archive/web/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: Fri, 20 Jun 2014 18:29:07 -0000

Ben,

I agree that some aspects of CT operation are procedural matters that fall
outside the scope of what the IETF usually specifies when defining a 
protocol.
But, readers cannot evaluate the effectiveness of a proposed system (CT is
a system, not just a protocol) without a clear picture of what the system
designers envision wrt to operational issues. You might want to look at 
the suite
of RFCs published by the SIDR WG, defining the RPKI, as an example of 
how to address
the full range of issues associated with a big, complex system. Most of 
the RFCs are
standards track, but a few are informational; together they provide a 
fairly clear
picture of what is expected of each element of the system, and how the 
elements
are intended to work together. Topics such as key rollover were party of 
the initial
set of RFCs, as well as discussion of the expected frequency with which 
relying
parties would query repositories, etc.

I don't agree that specifying behavior for browsers is out of scope for this
WG. (Pardon me if I misunderstood part of your response.) To define the 
CT system
one needs to specify behavior for TLS servers, TLS clients,  Web PKI 
CAs, log operators,
monitors, and Auditors. The current doc does some of this, but there are 
a number of gaps.
If browser vendors are to play a major role in managing config info in 
support info
for CT, e.g, providing pointers to log and public key for logs, then 
this should be
stated explicitly.

I've just completed a detailed analysis of the CT I-D and will begin 
posting my comments,
questions, and suggested edits on Monday. No need to dump this on the 
list on a Friday :-).
The analysis is about 18 pages, so I'll break it into separate messages, 
each dealing with
a section of the I-D, plus a message offering overall comments.

Steve