Re: [therightkey] Draft charter for a Transparency Working Group

Warren Kumari <warren@kumari.net> Wed, 11 December 2013 22:10 UTC

Return-Path: <warren@kumari.net>
X-Original-To: therightkey@ietfa.amsl.com
Delivered-To: therightkey@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B131ADF58 for <therightkey@ietfa.amsl.com>; Wed, 11 Dec 2013 14:10:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 uzanfi2wfF3v for <therightkey@ietfa.amsl.com>; Wed, 11 Dec 2013 14:09:59 -0800 (PST)
Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9B601ADDBD for <therightkey@ietf.org>; Wed, 11 Dec 2013 14:09:58 -0800 (PST)
Received: from [192.168.1.153] (unknown [66.84.81.105]) by vimes.kumari.net (Postfix) with ESMTPSA id 5B9931B401C6; Wed, 11 Dec 2013 17:09:52 -0500 (EST)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Warren Kumari <warren@kumari.net>
In-Reply-To: <CABrd9SRhqCfH8GNu7Z-+_6ZSkRSyj7v+=qM+orYZLmJpsqq5OQ@mail.gmail.com>
Date: Wed, 11 Dec 2013 17:09:51 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <937401BC-9270-45D9-AD3E-FC7656439C14@kumari.net>
References: <52A89F9F.70604@cs.tcd.ie> <10229F86C86EB444898E629583FD4171EDEAB12A@PACDCEXMB06.cable.comcast.com> <CABrd9SRhqCfH8GNu7Z-+_6ZSkRSyj7v+=qM+orYZLmJpsqq5OQ@mail.gmail.com>
To: Ben Laurie <benl@google.com>
X-Mailer: Apple Mail (2.1822)
Cc: Jason Livingood <Jason_Livingood@cable.comcast.com>, "therightkey@ietf.org" <therightkey@ietf.org>, Warren Kumari <warren@kumari.net>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Subject: Re: [therightkey] Draft charter for a Transparency Working Group
X-BeenThere: therightkey@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <therightkey.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/therightkey>, <mailto:therightkey-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/therightkey/>
List-Post: <mailto:therightkey@ietf.org>
List-Help: <mailto:therightkey-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/therightkey>, <mailto:therightkey-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 22:10:01 -0000

On Dec 11, 2013, at 1:29 PM, Ben Laurie <benl@google.com> wrote:

> On 11 December 2013 17:44, Livingood, Jason
> <Jason_Livingood@cable.comcast.com> wrote:
>> I totally understand the problem statement. But what concrete things can
>> you enumerate as goals/output of the WG?
> 
> I already did enumerate the one current output: RFC 6962-bis.
> 
> Other interesting targets include DNSSEC transparency, email-to-key
> mappings and binary transparency. All implicitly already in the
> charter.
> 

I’m in — I think that there is still much work / firming up the “charter” needed, but the effort seems useful and needed.
W

>> 
>> 
>> Jason
>> 
>> On 12/11/13, 12:23 PM, "Stephen Farrell" <stephen.farrell@cs.tcd.ie> wrote:
>> 
>>> 
>>> Thanks Ben,
>>> 
>>> So folks know what we're thinking and in case all the
>>> process gibberish isn't clear to you all...
>>> 
>>> Sean and I like the idea of doing this, and the more that
>>> it seems to get broader support, the more we'll like it.
>>> 
>>> Since there was already a BoF on this back at IETF-85 [1]
>>> that concluded this was work that's relevant to do in
>>> the IETF, we're thinking that if a crisp enough charter
>>> can be crafted on this list then this wouldn't need another
>>> BoF but would be ok to just be pushed into the IESG/IETF
>>> approval process.
>>> 
>>> What that means is that when Sean and I think we have a
>>> good enough charter draft, then we'll put that into the
>>> datatracker and the IESG will do an IESG-internal review
>>> to decide if its ready to be sent out for IETF review.
>>> If/when the IESG are ok with that going for IETF-wide
>>> review then a mail will go to the IETF discuss list so's
>>> anyone can comment on the proposed new WG. Then the IESG
>>> get to look at it again, and any comments we've gotten,
>>> and approve the new WG or not. Charter text tweaks can
>>> be expected at each stage.
>>> 
>>> All going well, that could result in a new WG for this
>>> being formed early in the new year, before IETF-89
>>> with the WG having a first f2f meeting there presumably.
>>> 
>>> So please comment on Ben's text and the above with that
>>> in mind. I assume Ben will hold the pen on draft charter
>>> text and update that as comments are received.
>>> 
>>> And please use this list for now, since this is the
>>> one we used for RFC 6962 so probably has the right
>>> people. When/if we form a WG we can make a new list
>>> or use this one if folks prefer that.
>>> 
>>> Thanks,
>>> S.
>>> 
>>> [1] http://www.ietf.org/proceedings/85/certrans.html
>>> 
>>> On 12/11/2013 04:55 PM, Ben Laurie wrote:
>>>> Who's in?
>>>> 
>>>> "Problem statement: many Internet protocols require a mapping between
>>>> some kind of identifier and some kind of key, for example, HTTPS,
>>>> SMTPS, IPSec, DNSSEC and OpenPGP.
>>>> 
>>>> These protocols rely on either ad-hoc mappings, or on authorities
>>>> which attest to the mappings.
>>>> 
>>>> 
>>>> History shows that neither of these mechanisms is entirely
>>>> satisfactory. Ad-hoc mappings are difficult to discover and maintain,
>>>> and authorities make mistakes or are subverted.
>>>> 
>>>> 
>>>> Cryptographically verifiable logs can help to ameliorate the problems
>>>> by making it possible to discover and rectify errors before they can
>>>> cause harm.
>>>> 
>>>> 
>>>> These logs can also assist with other interesting problems, such as
>>>> how to assure end users that software they are running is, indeed, the
>>>> software they intend to run.
>>>> 
>>>> 
>>>> Work items: Specify a standards-track mechanism to apply verifiable
>>>> logs to HTTP/TLS (i.e. RFC 6962-bis).
>>>> 
>>>> 
>>>> Discuss mechanisms and techniques that allow cryptographically
>>>> verifiable logs to be deployed to improve the security of protocols
>>>> and software distribution. Where such mechanisms appear sufficiently
>>>> useful, the WG will re-charter to add relevant new work items."
>>>> _______________________________________________
>>>> therightkey mailing list
>>>> therightkey@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/therightkey
>>>> 
>>>> 
>>> _______________________________________________
>>> therightkey mailing list
>>> therightkey@ietf.org
>>> https://www.ietf.org/mailman/listinfo/therightkey
>> 
> _______________________________________________
> therightkey mailing list
> therightkey@ietf.org
> https://www.ietf.org/mailman/listinfo/therightkey
> 

-- 
Do not meddle in the affairs of wizards, for they are subtle and quick to anger.  
    -- J.R.R. Tolkien