[secdir] [new-work] WG Review: Public Notary Transparency (trans)
The IESG <iesg@ietf.org> Fri, 24 January 2014 17:53 UTC
Return-Path: <new-work-bounces@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 588071A00CE; Fri, 24 Jan 2014 09:53:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1390586018; bh=ioLhgUbflx3p7VO0QkUzyrMxMoxzyc9xJ4ku5I3KTJQ=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=G4PseJN7exB7zYWemVIdNqAwBBQi1TqY72e4mJLVaWjt+bmU269FCJDO/7Z0F95+u Tw7fkNcoTkXvn/trj0YJWsfBVsJgT9MPU+NyzIwS8zj69ZqYazApP8Wkd9dBBvjUZ0 P/3pkQFdvlDRbUIhK43dAqoTXTzeY6EDKBvQihG8=
X-Original-To: new-work@ietfa.amsl.com
Delivered-To: new-work@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF7381A00BB; Fri, 24 Jan 2014 09:53:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 iVjyocoGvwDz; Fri, 24 Jan 2014 09:53:35 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EB05C1A00B7; Fri, 24 Jan 2014 09:53:34 -0800 (PST)
MIME-Version: 1.0
From: The IESG <iesg@ietf.org>
To: new-work@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.90.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140124175334.27816.88603.idtracker@ietfa.amsl.com>
Date: Fri, 24 Jan 2014 09:53:34 -0800
X-BeenThere: new-work@ietf.org
X-Mailman-Version: 2.1.15
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: new-work-bounces@ietf.org
Sender: new-work <new-work-bounces@ietf.org>
X-Mailman-Approved-At: Sat, 25 Jan 2014 12:03:08 -0800
Subject: [secdir] [new-work] WG Review: Public Notary Transparency (trans)
X-BeenThere: secdir@ietf.org
Reply-To: iesg@ietf.org
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Jan 2014 17:53:38 -0000
A new IETF working group has been proposed in the Security Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2014-02-03. Public Notary Transparency (trans) ------------------------------------------------ Current Status: Proposed WG 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/ Charter: 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. Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work