[therightkey] Draft charter for a Transparency Working Group

Ben Laurie <benl@google.com> Wed, 11 December 2013 16:55 UTC

Return-Path: <benl@google.com>
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 37E271ADF2F for <therightkey@ietfa.amsl.com>; Wed, 11 Dec 2013 08:55:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.38
X-Spam-Level:
X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
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 lPQeASWHyjV6 for <therightkey@ietfa.amsl.com>; Wed, 11 Dec 2013 08:55:13 -0800 (PST)
Received: from mail-vb0-x22c.google.com (mail-vb0-x22c.google.com [IPv6:2607:f8b0:400c:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 198501AD694 for <therightkey@ietf.org>; Wed, 11 Dec 2013 08:55:12 -0800 (PST)
Received: by mail-vb0-f44.google.com with SMTP id x8so1810820vbf.17 for <therightkey@ietf.org>; Wed, 11 Dec 2013 08:55:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=YdyeZDLWkLYKP2KO7sHTIZHbbxUvFTASp0978i0DxhE=; b=I8ayDPnFq5S9N+8QXqGzQXeLkFg1dF03joN0V3FXzIp983mrhMqlpoQk5O90m2w4aW W83fz0u5Zg28hQk7xCU8Ery0CML8LEen0EqPCYyLphbGKDywgE3r4Nm0NOzin0IbMRud ux9+yMzZ8ae972PlqpqZRGT3WlFYw4v9MVws4MWZAoQYX9gUxUyUu/0LMkBvU/aR5V7E XKRN51DwvevX/qFLkm6nnGOy2viEwtBhxafQAMztEThYp1ov17bIn+frJn9KHQV5pRXE K/s+suzsJqbrkDYltrvU6FerBSh7fFOrIf563YAUzQLyJX03GkgYDPgv7OCjAtMWPZLt 859g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=YdyeZDLWkLYKP2KO7sHTIZHbbxUvFTASp0978i0DxhE=; b=lZLSeeDzC8pzzDdSN2nwnJorRz4wuWBRdexH8rMTgJOlsd03+cpKVlJC8kj6QiM7QV 40aIBlE0Xbgi1xW0n4/aDnIXGBHu4Xd2UuUDnM7gG4I5BqAAb+m6/lK2C5KNk/+GzYRO CFVXz/YuOy03k2gg6YrR3PEnsMd/v8lLQh6jp6+Dj+d8HGW51oe+d6qHYzOyFi9ct+qv HX7RkZIaUAUkvvduvXV0IsxyAy24BUi8gVSD4r2s0UUFps/PVDOAiuboGU1t5XLgJruE 7FP2M/d5EkB2F2usrWtFU5s1ERm7K7W1KCW1kVZMXv/zVLvvixQ72Y/ZnAnDUNuVAWR/ Frjg==
X-Gm-Message-State: ALoCoQl9GHF67SH84QMwvyBKYWEvanCKca+YvS/OIY+E/HsQUvyUMTtBAgVyPfFc7tS2WRpUM6hMD/DjhwxKEQD3hw9W9ogH//aE1TS57yxvhCmUGZg/OpsvBVO1ROdFYd1UxtX8aEcwX49JxpffEVMpTJuXyiG66bLWNKw/BFXrBXxRBsMr2DCyQMv0eMaiMtqEEQl++bB7
MIME-Version: 1.0
X-Received: by 10.58.241.212 with SMTP id wk20mr51814vec.79.1386780907262; Wed, 11 Dec 2013 08:55:07 -0800 (PST)
Received: by 10.52.183.65 with HTTP; Wed, 11 Dec 2013 08:55:07 -0800 (PST)
Date: Wed, 11 Dec 2013 16:55:07 +0000
Message-ID: <CABrd9SSzGJy18tf_iR5jFNk-sJyX66OPhmM4H23K5X2ZpWniyQ@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: "therightkey@ietf.org" <therightkey@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Subject: [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 16:55:14 -0000

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."