WG Action: Formed Public Notary Transparency (trans)

The IESG <iesg-secretary@ietf.org> Fri, 14 February 2014 22:06 UTC

Return-Path: <iesg-secretary@ietf.org>
X-Original-To: ietf-announce@ietfa.amsl.com
Delivered-To: ietf-announce@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 014E81A004A; Fri, 14 Feb 2014 14:06:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id IqfWPR78MXLt; Fri, 14 Feb 2014 14:06:32 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 57EA01A0166; Fri, 14 Feb 2014 14:06:26 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Subject: WG Action: Formed Public Notary Transparency (trans)
X-Test-IDTracker: no
X-IETF-IDTracker: 5.0.0.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140214220626.12566.95239.idtracker@ietfa.amsl.com>
Date: Fri, 14 Feb 2014 14:06:26 -0800
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf-announce/YmD6FYKtfKSyeg0_O1cV2k2Gso4
Cc: trans WG <therightkey@ietf.org>
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: ietf@ietf.org
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-announce/>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Feb 2014 22:06:37 -0000

A new IETF working group has been formed in the Security Area. For
additional information please contact the Area Directors or the WG Chair.

Public Notary Transparency  (trans)
Current Status: Proposed WG

  Melinda Shore <melinda.shore@gmail.com>

Assigned Area Director:
  Stephen Farrell <stephen.farrell@cs.tcd.ie>

Mailing list
  Address: therightkey@ietf.org
  To Subscribe: https://www.ietf.org/mailman/listinfo/therightkey
  Archive: http://www.ietf.org/mail-archive/web/therightkey/


Mitigating web site certificate mis-issuance is the initial problem of
interest for this working group. Certificate Transparency (CT,
RFC6962) allows such mis-issuance to be detected in interesting and
useful cases, for example by an auditor acting for the web site, or
one acting to check general CA behaviour. The working group will
produce a standards-track version of the experimental RFC 6962
for HTTP over TLS, reflecting implementation and deployment 
experience since that specification was completed.

Many Internet protocols for example, SMTPS, IPsec, DNSSEC, 
OpenPGP and HTTPS, require  a mapping between some kind of 
identifier and some kind of public key. These protocols rely
on either ad-hoc mappings, (as in a web of trust), or on authorities
(such as CAs) that 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 these
problems by making it possible to discover errors quickly, so that 
other mechanisms can be applied to rectify them. A cryptographically 
verifiable log is an append-only log of hashes of more-or-less anything 
that  is structured in such a way as to provide efficiently-accessible,
cryptographically-supported evidence of correct log behaviour. For
example, RFC 6962 says: "The append-only property of each log is
technically achieved using Merkle Trees, which can be used to show
that any particular version of the log is a superset of any particular
previous version. Likewise, Merkle Trees avoid the need to blindly
trust logs: if a log attempts to show different things to different
people, this can be efficiently detected by comparing tree roots and
consistency proofs. Similarly, other misbehaviors of any log (e.g.,
issuing signed timestamps for certificates they then don't log) can be
efficiently detected and proved to the world at large."

These logs can potentially 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.

While the privacy issues related to use of RFC6962 for public
web sites are minimal, the working group will consider privacy
as it might impact on uses of CT e.g. within enterprises or
for other uses of logs.

Work items:

- Publish an update to RFC 6962 as a standards-track mechanism to
apply verifiable logs to HTTP over TLS.  As DANE (RFC6698) provides an
alternative keying infrastructure to that used in the current web PKI,
the working group should consider appropriate client behavior in the
presence of both DANE-based keying and current web PKI when
standardising CT.

- Discuss mechanisms and techniques that allow cryptographically
verifiable logs to be deployed to improve the security of protocols
other than HTTP over TLS, for example SMTP/TLS or software 
distribution. Where such mechanisms appear sufficiently useful, 
the WG will re-charter to add relevant new work items.  Should
no such items be chartered the WG will close when documents 
associated with the first work item are complete.