Re: [therightkey] IESG eval of charter
Paul Lambert <paul@marvell.com> Tue, 21 January 2014 23:38 UTC
Return-Path: <paul@marvell.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 95AD41A017A for <therightkey@ietfa.amsl.com>;
Tue, 21 Jan 2014 15:38:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.567
X-Spam-Level:
X-Spam-Status: No,
score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,
IP_NOT_FRIENDLY=0.334, 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 nraFea6L59Ky for
<therightkey@ietfa.amsl.com>; Tue, 21 Jan 2014 15:38:53 -0800 (PST)
Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com
[67.231.156.173]) by ietfa.amsl.com (Postfix) with ESMTP id 666ED1A0233 for
<therightkey@ietf.org>; Tue, 21 Jan 2014 15:38:51 -0800 (PST)
Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by
mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s0LNcckb022030;
Tue, 21 Jan 2014 15:38:38 -0800
Received: from sc-owa01.marvell.com ([199.233.58.136]) by
mx0b-0016f401.pphosted.com with ESMTP id 1hj2bq01y4-15 (version=TLSv1/SSLv3
cipher=RC4-MD5 bits=128 verify=NOT); Tue, 21 Jan 2014 15:38:37 -0800
Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com
([10.93.76.21]) with mapi; Tue, 21 Jan 2014 15:38:35 -0800
From: Paul Lambert <paul@marvell.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>,
"therightkey@ietf.org" <therightkey@ietf.org>
Date: Tue, 21 Jan 2014 15:38:34 -0800
Thread-Topic: [therightkey] IESG eval of charter
Thread-Index: Ac8XAebYHVyoSL//Q6qHqcbc3hVrMw==
Message-ID: <CF044407.2D04E%paul@marvell.com>
References: <52DEF8CB.1040608@cs.tcd.ie>
In-Reply-To: <52DEF8CB.1040608@cs.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.9.131030
acceptlanguage: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14,
0.0.0000 definitions=2014-01-21_08:2014-01-21, 2014-01-21,
1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0
spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0
classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000
definitions=main-1401210189
Subject: Re: [therightkey] IESG eval of charter
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: Tue, 21 Jan 2014 23:38:54 -0000
‹‹‹‹ On 1/21/14, 2:46 PM, "Stephen Farrell" <stephen.farrell@cs.tcd.ie> wrote: > >Hiya, > >Getting a number of comments [1] from IESG folks that >the charter's not so easy to grasp for non CT-aware >folks. > >My current try at fixing that at [2]. Please suggest >any *necessary* changes by tomorrow if you can. (And >in OLD/NEW format please, just to be nice to me:-) NEW is the first three paragraphs Š mostly a restructure for readability. Paul - - - - - Cryptographic logs provide a mechanism to publish a list of events that can be verified for correct ordering and content. The logs are append-only and can be efficiently verified by the world at large for correct log behavior. Certificate Transparency (CT, RFC6962) logs the issuance of X.509 certificates. The CT log enables the detection of mis-issued certificates providing validation of correct CA operation. The working group will produce a standards-track version of the experimental CT RFC 6962 reflecting implementation and deployment experience since that specification was completed. Many other Internet protocols besides X.509 map public keys to some kind of identifier and would benefit from a verifiable log These possible application of a cryptographic log include: SMTPS, IPSec, DNSSEC and OpenPGP. 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 be used to support these and other protocols to maintain consistent and correct mappings. Errors or subversion of the mappings can be detected and corrected to minimize any adverse impact. A cryptographically verifiable log is an append-only log of hashes. The hashes can represent more-or-less anything and serve as a unique identify for any information object. The log is structured to provide efficient access and cryptographic evidence of correct log operation. The individual hashes are linked together using Merkle Trees, which can be used to show that any particular version of the log is a superset of any particular previous version. 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. 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 and 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. > >Bear in mind that we're developing the charter text >that will go to IETF review, so this need not be the >final final thing, e.g. the final wordsmithing polish >can be done later. > >Cheers, >S. > >[1] https://datatracker.ietf.org/doc/charter-ietf-trans/ballot/ >[2] https://datatracker.ietf.org/doc/charter-ietf-trans/ >_______________________________________________ >therightkey mailing list >therightkey@ietf.org >https://www.ietf.org/mailman/listinfo/therightkey
- [therightkey] IESG eval of charter Stephen Farrell
- Re: [therightkey] IESG eval of charter Paul Lambert
- Re: [therightkey] IESG eval of charter Paul Lambert
- Re: [therightkey] IESG eval of charter Stephen Farrell
- Re: [therightkey] IESG eval of charter Ben Laurie